Đường ống tích hợp CI/CD pipeline là gì?

Có lẽ bạn đã từng nghe ở đâu đó về continuous integration (CI - tích hợp liên tục) và continuous deployment (CD - triển khai liên tục). Trong bài viết này sẽ cố gắng giải thích và hướng dẫn các bạn cài đặt sử dụng Gitlab CI, CD một cách dễ hiểu nhất.

CI - Tích hợp liên tục là gì?

Nghe tên thôi là cũng gần gần hiểu rồi, nôm na nó là phương pháp phát triển phần mềm yêu cầu dev nộp code thường xuyên, nộp code hàng ngày. Code được “tích hợp” liên tục lên test server, khi một đoạn code bị lỗi, cả team có thể sớm phát hiện và sửa chữa ngay lập tức.

CD - Triển khai liên tục là gì?

Đồng hành cùng tích hợp liên tục, triển khai liên tục là thường xuyên release phiên bản mới lên môi trường test, việc này được diễn ra tự động, giảm gánh nặng cho lập trình viên để lập trình viên tập trung vào việc code mà thôi.

Ví dụ bình thường, để xuất bản website, bạn phải làm rất nhiều thứ, từ upload code lên server, chạy migrate dữ liệu, cấu hình file config các kiểu, rất tốn thời gian và dễ sai sót. Thì với triển khai liên tục, bạn chỉ cần push code lên git là mọi thứ được tự động deploy lên server test mà bạn không cần phải đụng chân đụng tay gì.

Quy trình CI/CD

Có rất nhiều quy trình, công cụ khác nhau để ứng dụng CI/CD vào dự án. Nội dung của bài viết này dựa trên kinh nghiệm cho các dự án từng triển khai cũng như đặc thù là các hệ thống Web.

Ngày nay, với xu hướng agile/lean dẫn đến việc phát triển tính năng là điều bình thường, quan trọng phải là phải nhanh và chính xác, và cũng "thoái" (rollback) nếu có rủi ro xảy ra với phiên bản mới. Nếu một tính năng mà mất 2, 3 tháng mới release thì dẫn đến nhiều hệ lụy như làm không phù hợp nhu cầu khách hàng, hoặc đối thủ đã ra mắt trước đó, mất đi cái lợi thế dẫn đầu. Do đó, việc làm ra một sản phẩm, tính năng đòi hỏi thần tốc là ưu tiên số một hiện nay.

Bên cạnh đó, để nhanh chóng ra mắt một tính năng, phiên bản mới nếu theo cách cổ điển sẽ mất nhiều thời gian bởi công việc chân tay khá nhiều và mỗi lần release cũng huy động một cơ số người không nhỏ để cập nhật một thay đổi dù là nhỏ nhất. Bởi vậy, xu hướng CI/CD giúp cung cấp các framework, workflow giúp tiết kiệm thời gian, nguồn lực của quá trình release (delivery).

Continuous Deployment với Gitlab CI - CD

Hiện nay có rất nhiều hệ thống như Travis, Jenkin, Circle, Gitlab có thể giúp bạn triển khai CI/CD. Trong khuôn khổ bài viết này, chúng tôi sẽ giới thiệu tổng quan về CI/CD trên môi trường Gitlab.

Gitlab là mã nguồn mở để tạo git server, nôm na là để tạo hệ thống giống github. Gitlab CI - CD là một tool tự động deploy ứng dụng.

Runner là gì?

Một Runner có thể là một máy ảo (VM), một VPS, một bare-metal, một docker container hay thậm chí là một cluster container. Gitlab và Runners giao tiếp với nhau thông qua API, vì vậy yêu cầu duy nhất là máy chạy Runner có quyền truy cập Gitlab server.

Developer hoàn thành một task nào đó và push commit lên Gitlab để mọi người review.

Trong gitlab, các Runner thực thi các jobs được định nghĩa trong file .gitlab-ci.yml.

Một Runner có thể xác định cụ thể cho một dự án nhất định hoặc phục vụ cho nhiều dự án trong Gitlab. Nếu nó phục vụ cho tất cả project thì được gọi là Shared Runner.

Pipelines là gì?

Là đường ống lớn nhất của quy trình tích hợp được chạy dài từ đầu tới cuối, phân phối và triển khai liên tục (Pipelines are the top-level component of continuous integration, delivery, and deployment).

Pipeline bao gồm :

Jobs : Các công việc được giao thực thi (Ví dụ: biên dịch mã hoặc chạy test)
Stage : Xác định các thời điểm và cách thực hiện. (Ví dụ: test chỉ chạy sau khi biên dịch thành công)

Pipeline hoạt động theo nguyên tắc sau :

Tất cả các công việc trong cùng một stage được Runner thực hiện song song, nếu có đủ số lượng Runner đồng thời.
Nếu Success, pipeline chuyển sang stage tiếp theo.
Nếu Failed, pipeline sẽ dừng lại. Có một ngoại lệ là nếu job được đánh dấu làm thủ công, thì dù bị fail thì pipeline vẫn tiếp tục.

Thực hành (Best Practices)

Dưới đây là các bước thông thường của quá trình release tính năng trong một dự án thuộc hệ thống Teamcrop.
Bước 1: [Manual] Khởi tạo repository và có branch default là master và dev. Cài đặt trên Gitlab 9.
Bước 2: [Manual] Trừ owner ra, thì các coder sẽ push code tính năng lên branch dev
Bước 3: [Auto] Hệ thống tự động thực hiện test source code, nếu PASS thì sẽ deploy tự động (rsync) code lên server beta.
Bước 4: [Manual] Tester/QA sẽ vào hệ thống beta để làm UAT (User Acceptance Testing) và confirm là mọi thứ OK.
Bước 5: [Manual] Coder hoặc owner sẽ vào tạo Merge Request, và merge từ branch dev sang branch master.
Bước 6: [Manual] Owner sẽ accept merge request.
Bước 7: [Auto] Hệ thống sẽ tự động thực hiện test source code, nếu PASS sẽ enable tính năng cho phép deploy lên production server.
Bước 8: [Manual] Owner review là merge request OK, test OK. Tiến hành nhấn nút để deploy các thay đổi lên môi trường production.
Bước 9: [Manual] Tester/QA sẽ vào hệ thống production để làm UAT và confirm mọi thứ OK. Nếu không OK, Owner có thể nhấn nút Deploy phiên bản master trước đó để rollback hệ thống về trạng thái stable trước đó.
Bước 10: [Manual] Chờ biên bản nghiệm thu cho giai đoạn triển khai mới, hãy kiên trì lắng nghe khách hàng và chủ động "phòng thủ" từ xa (preventive actions).