Get in touch
or send us a question?
CONTACT

Đôi điều về CI và CD

Continuous integration (CI) là gì

Tích hợp liên tục (CI) là một cách thức phát triển phần mềm nhằm tăng tốc độ phát triển trong khi vẫn đảm bảo chất lượng code của team. Các dev liên tục commit code theo từng increment nhỏ (ít nhất hàng ngày hoặc thậm chí vài lần một ngày), sau đó được tự động build và test trước khi nó được merged vào repository.

Tích hợp liên tục hoạt động song song với các phương pháp Agile. Các member trong team làm việc trên các “stories” và code cho các thay đổi này được merged dần dần vào repository nhiều lần trong ngày.

CI có thể được áp dụng cho nhiều kiểu dự án phần mềm khác nhau. Ví dụ dưới đây là các step để update 1 website content:

  1. Dev tạo một branch code mới trên GitHub, thay đổi HTML của page, và commit code.
  2. Khi dev hoàn thành tất cả các thay đổi ở một branch, dev tạo một pull request (PR) trên Github.
  3. GitHub được tích hợp CircleCI. CircleCI thực hiện build code và chạy test tự động.
  4. Nếu CircleCI phát hiện bất kỳ lỗi nào (trạng thái build chuyển thành Đỏ), dev sẽ được thông báo qua email.
  5. Ngược lại, dev sẽ được thông báo đã build thành công (trạng thái build chuyển thành Xanh), code được push sang staging server. Điều này cho phép dev preview được phần thay đổi đã thực hiện.
  6. Sau khi verified, dev có thể merge branch code mới này vào production.

Sự khác nhau giữa continuous integration, continuous delivery, and continuous deployment?


Continuous integration (CI)
Tiến hành build và test tự động cho mỗi commit mới.

Continuous delivery
Trạng thái mà ứng dụng luôn sẵn sàng được deploy. Tuy nhiên, có bước thủ công là bắt buộc để triển khai ứng dụng.

Continuous deployment (CD)
Tự động hóa toàn bộ việc build, test, deploy. Nếu tất cả test đều pass, tất cả các commit mới sẽ đẩy code mới thông qua pipeline lên production mà không cần can thiệp thủ công.

Lợi ích của continuous integration


Nguyên lý cơ bản của tích hợp liên tục khá đơn giản: commit và tích hợp code thường xuyên — tối thiểu là hàng ngày. Một thay đổi nhỏ như vậy trong quy trình phát triển phần mềm có thể mang lại kết quả to lớn

Sử dụng cách thức này đem lại các lợi ích sau đây:

  • Nâng cao năng suất và hiệu quả của team
  • Đẩy nhanh tốc độ ra ngoài thị trường
  • Xác định sản phẩm/thị trường phù hợp
  • Release sản phẩm với chất lượng tốt hơn, ổn định hơn
  • Nâng cao sự hài lòng của khách hàng
  • Dev luôn vui vẻ và đẩy code thường xuyên hơn

Làm cách nào để có được lợi ích này từ sự thay đổi đơn giản như vậy trong workflow?
Khi bạn commit thường xuyên, bạn có thể xác định và giải quyết các conflict sớm hơn hoặc loại bỏ chúng hoàn toàn. Vì vậy, thay vì viết hàng nghìn dòng code và tìm ra lỗi, bạn chỉ viết một vài trăm. Tìm bug trong code sẽ trở nên đơn giản trong vài phút thay vì vài giờ. Điều này dẫn đến cải thiện năng suất của nhóm và giúp các nhà phát triển gửi code nhanh hơn.

Delivery các tính năng mới nhanh chóng đồng nghĩa với việc tăng tốc độ tiếp cận thị trường. Điều này mang lại cho team lợi thế cạnh tranh:

  1. Khách hàng có thể xác nhận các tính năng mới nhanh hơn, dẫn đến sự hài lòng của khách hàng cao hơn
  2. Công ty nhận được lợi tức đầu tư nhanh hơn từ các tính năng mới. Thay vì đợi milestone tiếp theo để release code, bạn có thể mang lại giá trị ngay khi tính năng mới sẵn sàng ra thị trường.

Làm thế nào để bắt đầu với CI/CD


Điều quan trọng là phải thiết lập CI pipeline càng sớm càng tốt trong quy trình phát triển. Một khi các tests được thêm vào CI pipeline, bạn có thể tiếp tục đổi mới và xây dựng với tự tin rằng bạn không thể merge code chưa pass test. Ngoài ra, việc phát triển CD vào CI pipeline cung cấp khả năng tự động hóa trong việc triển khai.

Các bước

  1. Chắc chắn rằng mọi thành viên trong team đang có cùng nhận thức về những gì bạn đang cố gắng hướng đến với CI/CD tool.
  2. Luôn bắt đầu từ những dự án nhỏ. Đừng cố gắng thay đổi cả tổ chức của bạn thành một nhóm DevOps kiểu mẫu trong một sớm một chiều. Thay vào đó, hãy thực hiện các thay đổi về quy trình trên một nhóm để xem chúng có hoạt động tốt trong tổ chức của bạn hay không. Nếu bạn thấy những thay đổi, hãy tiếp tục phát triển.
  3. Thực hiện những gì đem lại hiệu quả. Cần biết rằng DevOps có thể không phải là giải pháp phù hợp cho tổ chức của bạn. Một số công ty đã thành công trong một thời gian dài mà không có DevOps và nó có thể không phù hợp với bạn, tùy theo văn hóa hoặc nhu cầu sản phẩm của công ty. Ví dụ: nếu tính bảo mật cực kỳ quan trọng trong chiến lược sản phẩm của công ty, thì increment từng phần để nhận phản hồi sẽ không hiệu quả với bạn. Trong trường hợp đó, sẽ rất khó để xây dựng Văn hóa DevOps.
  4. Luôn đo lường sự thay đổi. Trước khi bạn bắt đầu bất kỳ kế hoạch cải tiến nào, hãy lấy các số liệu chính xác về vị trí hiện tại của bạn (ví dụ chu trình phát triển mất X thời gian). Sau đó, sau một khoảng thời gian phù hợp, bạn sẽ có thể xem liệu nó có hiệu quả hay không. Ví dụ: Khi có rất nhiều chuyển đổi Agile đang diễn ra, nhiều công ty đã áp dụng các phương án mà không thực sự hiểu tại sao hoặc không đo lường liệu nó có ảnh hưởng tích cực đến nhóm của họ hay không. Điều này có thể gây lãng phí nhiều thời gian
  5. Đừng cố gắng để tự động hóa mọi thứ. Ít nhất không phải tất cả cùng một lúc. Một quan niệm sai lầm về DevOps là tất cả việc cung cấp cơ sở hạ tầng và quản lý cấu hình phải được thực hiện tự động. Điều này được gọi là “infra as code.” Nhưng một số thứ hoạt động tốt hơn khi chúng được làm thủ công; tự động hóa không phải là giải pháp cho mọi thứ. Đôi khi, bạn phải bắt đầu theo cách thủ công để tìm ra giải pháp tốt nhất cho tự động hóa thực sự là gì.

CI không chỉ là triển khai một công cụ mới. Đó là về việc thay đổi cách thức hoạt động của team. Đó là một tư duy mới. Và, việc thay đổi văn hóa trong một tổ chức không phải là điều dễ dàng. Cách tốt nhất để bắt đầu với tích hợp liên tục là bắt đầu từ quy mô nhỏ.

Tài liệu tham khảo

https://circleci.com/continuous-integration/#continuous-integration-ci-vs-continuous-deployment-cd