Tuần vừa rồi, mình tham gia hỗ trợ một team bên ngoài trong một dự án WordPress khá lớn, ít nhất là lớn theo tiêu chuẩn những dự án mình từng làm. Chỉ riêng database sau khi nén đã lên tới khoảng 20 GB, chưa kể hệ thống còn có rất nhiều custom plugin, code tùy chỉnh và các thành phần được cập nhật thường xuyên.

Trước đây, dự án chỉ có một developer chính quản lý nên việc deploy thủ công vẫn có thể chấp nhận được. Mỗi khi có thay đổi, developer đó sẽ tự upload từng file hoặc cập nhật từng plugin lên server. Quy trình này có thể hoạt động khi chỉ có một người làm việc với source code, nhưng bắt đầu trở thành vấn đề ngay khi có thêm thành viên mới tham gia.

Ở thời điểm mình mới join team, mình chưa được cấp quyền SSH nên không thể tự deploy code. Sau khi hoàn thành một task, mình phải gửi để chờ approve, rồi tiếp tục chờ developer cũ đưa code lên staging. Chỉ sau khi code được deploy, mình mới có thể kiểm tra xem thay đổi có thực sự hoạt động trong môi trường của dự án hay không.

Việc chờ đợi này không chỉ làm chậm tiến độ mà còn khiến một task nhỏ có thể kéo dài hơn nhiều so với thời gian thực tế cần để hoàn thành nó.

Local, Staging Và Production không hoàn toàn giống nhau

Một vấn đề khác là môi trường local không hoàn toàn giống staging và production. Dự án WordPress này được cập nhật thường xuyên, đồng thời có một phần CSS và JavaScript được chỉnh trực tiếp trong khu vực quản trị. Vì vậy, source code trên máy local đôi khi không hoàn toàn đồng bộ với những thay đổi đang tồn tại trên server.

Có những trường hợp một đoạn CSS hoạt động bình thường ở local nhưng khi đưa lên staging lại bị ghi đè bởi code được thêm trong admin. Đôi khi mình phải thêm !important thì thuộc tính mới có hiệu lực. Đây không phải là cách xử lý lý tưởng, nhưng nó cho thấy một vấn đề lớn hơn: nếu không thể deploy và kiểm tra nhanh trên đúng môi trường, việc debug sẽ trở nên chậm và khó đoán hơn rất nhiều.

Mỗi lần thay đổi code, quy trình lại lặp lại. Hoàn thành task, gửi approve, chờ deploy, kiểm tra staging, phát hiện khác biệt, sửa lại và tiếp tục chờ deploy lần nữa.

Sau một thời gian làm quen với dự án, cuối cùng mình cũng được cấp tài khoản server. Việc đầu tiên mình ưu tiên không phải là tiếp tục deploy thủ công, mà là thiết lập GitHub Actions để tự động hóa quy trình deploy.

Mình luôn ưu tiên CI khi có nhiều developer

Sau nhiều năm làm việc trong các team và trải qua nhiều dự án có nhiều developer cùng tham gia, mình nhận ra rằng CI không chỉ là một tính năng kỹ thuật hay một thứ để làm cho quy trình trông chuyên nghiệp hơn. Nó giải quyết một vấn đề rất thực tế: loại bỏ những công việc lặp lại và giảm sự phụ thuộc vào một cá nhân, và nhất là khi bạn làm việc với nhiều múi giờ khác nhau nữa.

Khi chưa có CI, việc deploy bị phụ thuộc hoàn toàn vào developer có quyền truy cập server. Nếu người đó bận, đang nghỉ hoặc chưa kịp kiểm tra tin nhắn, tất cả những người còn lại đều phải chờ. Khi có GitHub Actions, việc merge code vào một branch cụ thể có thể tự động kích hoạt quá trình deploy lên staging. Quy trình trở nên nhất quán, dễ theo dõi và không còn phụ thuộc vào việc một ai đó nhớ upload đúng file.

Ở thời điểm hiện tại, việc thiết lập GitHub Actions cũng không còn quá khó như trước. Mình đã làm việc này ở nhiều dự án nên quá trình setup khá quen thuộc, nhưng ngay cả với những người chưa có nhiều kinh nghiệm, AI cũng có thể hỗ trợ rất nhiều.

Khi gặp lỗi về SSH key, permission, path, workflow syntax hoặc cách tổ chức secret, bạn có thể tìm trên Google hoặc hỏi trực tiếp AI. Không nhất thiết phải hiểu toàn bộ hệ thống ngay từ đầu. Chỉ cần xử lý từng vấn đề một, từng bước một, cuối cùng workflow cũng sẽ hoạt động.

Tuy nhiên, tự động hóa kỹ thuật không có nghĩa là mọi vấn đề đều tự động biến mất.

Sự cố khi code trên staging bị ghi đè

Một ngày, một thành viên khác trong team tạo một thread để thông báo rằng phần code anh này vừa làm trên staging đã biến mất. Anh ấy không hẳn là developer chuyên nghiệp, nhưng có kiến thức kỹ thuật và sử dụng Claude Code để xây dựng thêm tính năng cũng như sửa bug trực tiếp trên staging, anh báo hiện trạng, và anh cũng bảo là không có một ai login server cả, git không track vân vân.

Trong lúc đó, mình merge một branch mới vào branch staging. GitHub Actions chạy như đã được cấu hình và deploy source code từ repository lên server. Kết quả là những thay đổi được sửa trực tiếp trên staging nhưng chưa được commit vào GitHub đã bị ghi đè.

Về mặt kỹ thuật, workflow hoạt động chính xác. Server được đồng bộ với trạng thái của branch staging, đúng như mục tiêu ban đầu. Nhưng về mặt quy trình làm việc, team lại chưa thống nhất cách sử dụng môi trường staging sau khi CI được triển khai.

Vấn đề của mình là mình đã thông báo cho developer chính về hệ thống deploy mới, nhưng không thông báo rộng rãi tới toàn bộ team. Vì vậy, thành viên kia không biết rằng staging từ thời điểm đó đã được quản lý tự động thông qua GitHub. Anh ấy vẫn coi staging là nơi có thể chỉnh sửa code trực tiếp giống như trước đây.

Khi code bị mất, phản ứng đầu tiên của anh ấy là lo lắng và hỏi xem chuyện gì đã xảy ra. Sau khi mình giải thích rằng staging giờ sẽ được đồng bộ từ repository mỗi khi có code mới được merge, anh ấy đã hiểu vấn đề.

Sự cố này cũng nhắc mình rằng triển khai CI không chỉ là viết một file workflow. Nó còn là thay đổi cách cả team làm việc.

CI chỉ hiệu quả khi cả team hiểu quy trình

GitHub Actions một lần nữa chứng minh được giá trị của nó đối với mình. Nó giúp giảm thời gian chờ đợi, loại bỏ việc deploy từng file thủ công và cho phép các thay đổi được đưa lên staging một cách nhanh chóng, nhất quán hơn.

Nhưng lần này mình cũng học thêm một điều: khi thay đổi quy trình deploy, việc giao tiếp với team quan trọng không kém phần cấu hình kỹ thuật.

Nếu staging được quản lý bởi CI, mọi người cần hiểu rằng source of truth phải là repository. Không nên chỉnh sửa trực tiếp trên server, hoặc nếu bắt buộc phải sửa khẩn cấp thì thay đổi đó cần được đưa ngược lại vào Git càng sớm càng tốt. Nếu không, lần deploy tiếp theo sẽ ghi đè toàn bộ phần code chưa được lưu trong repository.

Một workflow tốt cần đi cùng với một quy ước rõ ràng: branch nào deploy lên staging, branch nào deploy production, ai có quyền merge, cách xử lý hotfix ra sao và những thay đổi nào không được phép thực hiện trực tiếp trên server.

Tự động hóa giúp giải quyết vấn đề lặp lại, nhưng nó cũng buộc cả team phải làm việc có kỷ luật hơn.

Với mình, đó không phải là nhược điểm. Đó chính là giá trị lớn nhất của CI.

Nó không chỉ giúp code được deploy nhanh hơn. Nó còn giúp quy trình trở nên minh bạch hơn, giảm phụ thuộc vào từng cá nhân và khiến mọi người phải coi repository là nguồn dữ liệu chính của dự án.

Và sau sự cố nhỏ lần này, mình nghĩ workflow của team sẽ tốt hơn trước rất nhiều.