Continuous Deployment (CD)

Triển khai liên tục

Đã nói đến tích hợp liên tục thì giờ là lúc để nói đến triển khai liên tục mọi người nhỉ. Khác với tích hợp liên tục (CI) chỉ phù hợp với các loại dự án không gấp gáp thì ngược lại triển khai liên tục (CD) lại phù hợp với tất cả các loại hình dự án phần mềm, càng gấp thì lại càng phải dùng, nó sẽ giúp chúng ta thoát khỏi những công việc kéo thả chân tay, giải quyết triệt để những thiếu sót hay nhầm lẫn file này file kia và quan trọng nhất là giải quyết được xung đột phiên bản giữa các thành viên trong nhóm thông qua cơ chế hàng đợi.

Cùng hồi tưởng lại

Trước khi có DI cùng với các công cụ tự động deploy thì mình và các tiền bối đa phần sử dụng các công cụ như Filezilla hay Transmit để copy các file triển khai (artifact) lên server. Ban đầu khi dự bé, với 1 2 người thì mọi chuyện khá đơn giản, nhưng khi dự án bắt đầu phức tạp và nhiều người hơn, các vấ đề bắt đầu này sinh:

Mỗi người phát triển một tính năng nên khi deploy thường bị thiếu các tính năng của người này người kia, dẫn đến những tranh luận và tốn thời gian merge code và deploy lại
Các file cấu hình nằm hết trên server nên việc sửa file cấu hình diễn ra bừa bãi và dễ mất kiếm soát, khi có lỗi do file cấu hình thì phải mò mẫn rất mất thời gian
Khi deploy thì thường quên không backup lại các cái file cũ thành ra khi muốn rollback thì không được
Chung quy lại là tốn thời gian, mỗi lần deploy phải thực hiện rất nhiều thao tác dẫn đến mệt mỏi và stress

Không có gì ghê gớm

Với những vấn đề kể trên thì việc ra đời của CD là điều tất yếu. Nhưng nó cũng không phải cái gì đó quá ghê gớm, nó chỉ đơn giản tự động hoá các thao tác mà bình thường chúng ta vẫn phải thực hiện bằng tay. Một số người hiểu nhầm CD (hay CI) là gắn liền với docker, kubernetes, k8s hay các hệ thống lớn, có lẽ chính vì những hiểu nhầm này mà CI/CD có phần bị thần thánh hoá. Về cơ bản CD cũng gồm các bước (mình sẽ gọi tắt các công cụ CD là CD cho nhanh):

Khi có một sự kiện được kích hoạt từ các git server (như github, gitlab), hoặc do vòng lặp từ chính các công cụ CD như Jenkin, CircleCI, DroneCI thông báo rằng cần phải build và deploy, như các dự án của mình là cứ một phút là mình lại dùng lệnh git pull origin develop để kiểm tra xe có commit nào mới không, nếu có thì mình sẽ kích hoạt việc build và deploy
CD sẽ pull source code từ git server
CD tiến hành build, ở bước này thì việc build nên diễn ra đơn giản, không cần thiết phải test lại nữa nếu như chúng ta đã làm ở bước CI rồi
Sau khi build xong CD gọi đến script backup trên các server để backup lại các trạng thái cần thiết
Tiếp theo CD sẽ sử dụng các công cụ như Ansible hay câu lệnh scp để copy các artifact lên server
Sau khi các artifact đã deploy lên server, CD sẽ kích hoạt restart script trên server
Kết thúc và thông báo trạng thái.

Lưu ý: Ở tất cả các bược chúng ta nên cho phép CD thông báo trạng thái hoặc kết quả qua email, các công cụ chat như slack, hoặc đơn giản là hiện thị trạng thái trên chính giao diện của các git server

Hiện đại hơn một chút

CD mà chúng ta vừa nói ở trên liên quan nhiều đến cách deploy truyền thống (sử dụng các artifact thuần tuý được build ra). Nhưng ngày nay cùng với sự phát triển của Docker, Kubernetes hay các nền tảng ảo hoá khác nói chung, thì CD cũng có sự thay đổi theo.

Việc build cũng sẽ diễn ra tương đối phức tạp, nếu dùng k8s thì còn cần phải pull helm config từ git về để build helm và gán giá trị cho các biến
Sau khi build xong thì CD sẽ đóng các artifact vào image và push các image này lên các hub như docker hub hay harbor.
Ở bước trigger restart sẽ phụ thuộc nhiều vào hệ thống chúng ta dùng là gì, ví dụ như với k8s đó là việc gọi API do nó cung cấp, quá trình này diễn ra thế nào mình sẽ nói ở các bài liên quan đến k8s nhé
Các server (nếu dùng k8s thì là các pod) sẽ không có luôn artifact mà nó phải pull image từ hub để chạy.

Những lưu ý

Thường thì các DevOps sẽ không hiểu thế nào là deploy thành công hay không, nên DevOps hay chủ động liên lạc với Dev và nói ra mong muốn của mình, có thể là in ra một dòng là "Deploy successfully" khi chương trình khởi động xong để DevOps biết được
Mặc dù là deploy tự động nhưng không có nghĩa là chúng ta không cần theo dõi log và test lại, các Dev hãy chủ động làm việc này
Khi deploy các phiên bản quan trọng trên các môi trường quan trọng, đặc biệt là môi trường thật vẫn luôn cần có sự tham gia của cả Dev và DevOps, với các hệ thống k8s sử dụng rolling update thì buộc phải theo dõi tình trạng các pod cho đến khi nào, các pod Running hết thì thôi, mà lỗi hay gặp nhất có lẽ là ImagePullBackOff do các image hub có vấn đề hoặc tài khoản có vấn đề. Chúng ta có thể theo dõi các pods thông qua câu lệnh:

kubectl -n [namespace] get pods

Việc deploy tự động chỉ nên dành cho môi trường alpha, còn các môi trường liên quan đến nhiều bộ phận hay người dùng như BETA hay REAL thì cần phải có sự thông báo và trigger bằng tay, các dự án mình hiện tại đang trigger từ Jenkin hoặc CircleCI.

Tổng kết

Continuous deployment là một thành phần không thể thiếu trong quy trình phát triển phần mềm hiện nay, nó giúp chúng ta tiết kiệm được rất nhiều thời gian và công sức, thông qua việc giải phóng sức lao động, và nhường việc đó cho máy tính, vậy còn chần chừ gì nữa nhỉ, các bạn hãy sử dụng CD cho các dự án của mình nhé.