DevOps từ con số 0 (phần 1)
CI/CD
Quy trình phát triển phần mềm truyền thống thường theo mô hình “thác nước” (Waterfall). Các giai đoạn như lập trình, tích hợp, kiểm thử, và triển khai diễn ra tuần tự. Dẫn đến phát hiện lỗi muộn và khó khăn trong việc duy trì tính ổn định khi tích hợp nhiều thay đổi cùng lúc. CI/CD ra đời như một giải pháp để tự động hóa quy trình, giải quyết các vấn đề trên, giúp tích hợp code thường xuyên, kiểm thử liên tục và triển khai một cách an toàn.
CI (Continuous Integration)
Định nghĩa
Là quá trình các lập trình viên liên tục tích hợp và kiểm tra mã nguồn của bản thân vào một mã nguồn chung của dự án (ví dụ như là git)
Quá trình kiểm tra sẽ diễn ra một cách tự động nhằm đảm bảo code chạy đúng (từ syntax, convention, performance, ...)
Gồm 2 quá trình
Build: Biên dịch mã nguồn thành một phần mềm chạy được.
Test: Chạy các bài kiểm thử tự động (unit test, integration test) để đảm bảo thay đổi mới không làm hỏng những gì đang có.
Các bước kiểm thử cơ bản
Functional tests: Kiểm tra xem phần mềm có hoạt động đúng theo mong đợi hay không. Đây thường là các bài kiểm tra tự động mà đội ngũ QA (Quality Assurance) phát triển để đảm bảo tính năng hoạt động đúng. VD: Người dùng có thể thêm sản phẩm vào giỏ hàng và thực hiện thanh toán thành công hay không.
Security scans: Kiểm tra code có lỗ hổng bảo mật nào không, chẳng hạn như khả năng bị SQL Injection hay XSS (Cross-Site Scripting).
Code quality scans: Đảm bảo code tuân thủ các tiêu chuẩn, ví dụ như độ dài hàm, cách sử dụng khoảng trắng, và các quy tắc coding style. VD: Tiêu chuẩn như đặt tên biến.
Performance tests: Kiểm tra xem code có đáp ứng được yêu cầu về hiệu suất không, chẳng hạn như thời gian xử lý yêu cầu hoặc khả năng chịu tải.
License scanning: Kiểm tra xem tất cả các thư viện hoặc công cụ bạn sử dụng có giấy phép phù hợp hay không, để tránh các vấn đề pháp lý.
Fuzz testing: Gửi các dữ liệu bất thường, như chuỗi ký tự quá dài hoặc số không hợp lệ, vào ứng dụng để kiểm tra xem nó có bị crash hay gặp lỗi bất ngờ không.
CD
Continuous Delivery (Phân phối liên tục)
Định nghĩa
Là quá trình nhằm đảm bảo rằng code luôn sẵn sàng để được triển khai bất cứ lúc nào. Sau khi code đã vượt qua các kiểm tra CI, nó được đặt ở trạng thái sẵn sàng để triển khai. Tuy nhiên, việc triển khai có thể được thực hiện thủ công.
PipeLine
Giai đoạn 1: Lấy “Thành phẩm” từ CI (Artifact)
Hành động: Pipeline sẽ tự động lấy gói phần mềm (được gọi là artifact) đã được CI build và kiểm thử thành công. Đây có thể là một file
.jar,.war, một Docker image, hoặc một thư mục chứa các file đã được biên dịch.
Giai đoạn 2: Giai đoạn Chấp nhận (Acceptance Phase)
Giai đoạn này xác nhận rằng phiên bản mới không chỉ đúng về mặt kỹ thuật mà còn đáp ứng yêu cầu kinh doanh thông qua các bài kiểm thử tự động ở cấp độ cao:
Kiểm thử Chấp nhận Tự động (Automated Acceptance/E2E Tests):
Mục đích: Mô phỏng chính xác hành vi của người dùng cuối để xác minh các luồng nghiệp vụ quan trọng hoạt động đúng.
Ví dụ: Một kịch bản tự động sẽ mở trình duyệt, truy cập trang đăng nhập, nhập username/password, thêm sản phẩm vào giỏ hàng và tiến hành thanh toán.
Kiểm thử Hiệu năng và Chịu tải (Performance & Load Tests):
Mục đích: Đảm bảo ứng dụng vẫn nhanh, ổn định và đáp ứng tốt khi có nhiều người dùng truy cập cùng lúc.
Ví dụ: Giả lập 1000 người dùng đồng thời truy cập vào trang khuyến mãi để xem hệ thống có bị chậm hoặc sập không.
Quét Bảo mật (Security Scans):
Mục đích: Tự động rà soát mã nguồn và các thư viện đang sử dụng để tìm ra các lỗ hổng bảo mật đã biết.
Ví dụ: Quét để phát hiện các lỗ hổng phổ biến như SQL Injection, Cross-Site Scripting (XSS), hoặc các thư viện bên thứ ba đã lỗi thời.
Giai đoạn 3: Cổng Phê duyệt Thủ công (The Manual Approval Gate)
Đây là quá trình vô cùng quan trọng, nhằm quyết định việc triển khai sẽ được diễn khi nào, gồm các chức năng gì dựa theo chiến lược kinh doanh. Quá trình này thường thuộc về những người có thẩm quyền như giám đốc, trưởng phòng kinh doanh.
Giai đoạn 4: Triển khai Lên Production (Release Phase)
Sau khi được phê duyệt, pipeline sẽ triển khai phiên bản phần mềm mới nhất lên môi trường Production, nơi người dùng cuối có thể truy cập.
Các chiến lược triển khai phổ biến:
Blue-Green Deployment: Chạy song song hai môi trường Production giống hệt nhau (Blue và Green). Phiên bản mới được triển khai lên môi trường Green trong khi người dùng vẫn đang truy cập môi trường Blue. Khi đã sẵn sàng, lưu lượng truy cập sẽ được chuyển hết sang Green.
Canary Release: Triển khai phiên bản mới cho một nhóm nhỏ người dùng trước. Nếu không có vấn đề gì xảy ra, sẽ dần dần mở rộng ra cho toàn bộ người dùng.
Feature Flags (Feature Toggles): Kỹ thuật quản lý việc bật hoặc tắt các tính năng cụ thể trong ứng dụng mà không cần triển khai lại mã nguồn. Toàn bộ mã nguồn mới được triển khai, nhưng tính năng đó chỉ được kích hoạt (bật flag) cho một nhóm người dùng nhất định (ví dụ: nhân viên, người dùng beta) hoặc toàn bộ người dùng khi đã sẵn sàng. Chiến lược này cho phép đội ngũ phát triển giảm thiểu rủi ro tức thời (bằng cách tắt tính năng gây lỗi ngay lập tức) và thực hiện A/B Testing dễ dàng.
Giai đoạn 5: Giám sát và Phản hồi (Monitoring & Feedback)
Hành động: Sau khi triển khai, các công cụ giám sát sẽ theo dõi tình trạng của ứng dụng trên môi trường Production (ví dụ: tỷ lệ lỗi, thời gian phản hồi, tài nguyên sử dụng).
Mục đích: Nhanh chóng phát hiện và cảnh báo nếu có sự cố xảy ra, giúp đội ngũ phát triển có thể khắc phục hoặc kích hoạt cơ chế rollback (quay lại phiên bản ổn định trước đó) một cách nhanh chóng.
Use Case
Các ứng dụng B2B/Doanh nghiệp (Enterprise)
Các hệ thống tài chính, ERP, bảo hiểm, hoặc các dịch vụ phục vụ khách hàng doanh nghiệp có yêu cầu nghiêm ngặt về tính ổn định và tuân thủ.
Yêu cầu phê duyệt chính thức của quản lý, kiểm toán, hoặc đội ngũ vận hành trước khi thay đổi hệ thống quan trọng, nhằm giảm thiểu rủi ro pháp lý/tài chính.
Các sản phẩm có quy trình kiểm thử thủ công phức tạp
Các ứng dụng yêu cầu kiểm thử chấp nhận người dùng (UAT) kéo dài hoặc kiểm thử hiệu năng chuyên sâu mà chưa thể tự động hóa hoàn toàn.
Pipeline tự động dừng lại sau môi trường Staging/QA, chờ phản hồi từ người dùng/kiểm thử viên trước khi triển khai chính thức.
Các dịch vụ có độ trễ cao (High-Latency Services)
Các dịch vụ được sử dụng rộng rãi và việc triển khai có thể gây ra ảnh hưởng lớn đến hàng triệu người dùng (ví dụ: một bản cập nhật lớn của ngân hàng, viễn thông).
Cần có thời gian cụ thể để triển khai (ví dụ: ngoài giờ làm việc) và cần có con người giám sát quá trình chuyển đổi.
Ứng dụng di động (Mobile Apps)
Ứng dụng cần được gửi lên App Store hoặc Google Play để phê duyệt trước khi đến tay người dùng.
Pipeline tự động hóa mọi thứ, nhưng bước cuối cùng là quá trình phê duyệt bên thứ ba (Apple/Google), không thể tự động hóa hoàn toàn.
Continuous Deployment (Triển khai Liên tục)
Định nghĩa:
Là bước tiến cao nhất của CI/CD, loại bỏ hoàn toàn “Cổng Phê duyệt Thủ công” của Continuous Delivery. Mọi thay đổi vượt qua được tất cả các giai đoạn kiểm thử tự động sẽ được tự động triển khai thẳng lên môi trường Production mà không cần bất kỳ sự can thiệp nào của con người.
So sánh
Ưu điểm
Tốc độ phát hành tối đa: Đây là lợi ích lớn nhất. Vì không có bước phê duyệt thủ công, mọi thay đổi vượt qua tất cả các bài kiểm thử tự động sẽ được triển khai thẳng lên môi trường Production ngay lập tức
Vòng lặp phản hồi (Feedback Loop) ngắn hơn:
Phát hiện vấn đề sớm: Các lỗi hoặc vấn đề về trải nghiệm người dùng trên môi trường thực sẽ được phát hiện ngay, thay vì chờ đợi vài ngày hoặc vài tuần cho một đợt phát hành thủ công.
Xác thực ý tưởng nhanh: Bạn có thể nhanh chóng kiểm chứng xem một tính năng mới có thực sự mang lại giá trị cho người dùng hay không, từ đó đưa ra quyết định phát triển tiếp theo dựa trên dữ liệu thực tế.
Rủi ro thấp hơn trên mỗi lần triển khai:
Thay đổi nhỏ, dễ quản lý: Mỗi lần triển khai chỉ bao gồm một vài thay đổi nhỏ. Nếu có lỗi xảy ra, việc xác định nguyên nhân và sửa chữa sẽ dễ dàng hơn rất nhiều so với việc triển khai một bản cập nhật lớn chứa hàng chục thay đổi.
Giảm tâm lý “sợ hãi” khi phát hành: Quá trình triển khai trở thành một hoạt động thường nhật, ít căng thẳng, thay vì là một sự kiện lớn, đầy rủi ro.
Tăng năng suất cho đội ngũ phát triển:
Lập trình viên có thể tập trung hoàn toàn vào việc viết mã và cải tiến sản phẩm mà không bị gián đoạn bởi các quy trình phát hành thủ công. Họ thấy được kết quả công việc của mình gần như ngay lập tức, điều này tạo ra động lực và sự hài lòng lớn hơn.
Use Case
Các dịch vụ web/API có quy mô lớn (High-Scale Web/API):
Các công ty công nghệ lớn có hàng trăm vi dịch vụ (microservices) và cần phát hành các bản cập nhật nhỏ nhiều lần trong ngày (ví dụ: Netflix, Amazon).
Tốc độ là yếu tố quyết định. Lỗi được quản lý bằng Canary Release và Feature Flags, cho phép phục hồi nhanh hơn là ngăn chặn.
Các ứng dụng có bộ kiểm thử tự động cực kỳ mạnh mẽ:
Khi toàn bộ pipeline đã được tin tưởng tuyệt đối, bao gồm kiểm thử đơn vị (Unit), kiểm thử tích hợp (Integration), và kiểm thử đầu cuối (E2E) đều có độ bao phủ cao (High Coverage).
Các sản phẩm có tốc độ phát triển cao (High Velocity):
Các startup hoặc đội ngũ cần lặp lại và thử nghiệm các tính năng mới trên thị trường nhanh nhất có thể.
Cho phép thực hiện vòng lặp phản hồi (feedback loop) ngắn nhất có thể, thúc đẩy học hỏi và đổi mới nhanh chóng.
Các tính năng hoặc dịch vụ phụ trợ ít rủi ro:
Các dịch vụ không tương tác trực tiếp với dữ liệu nhạy cảm của khách hàng, hoặc các công cụ nội bộ.
Trụ cột để CD thành công
Kim Tự Tháp Kiểm thử Tự động: Tin cậy vào Code phải là nền tảng.
Unit Tests (Nền): Kiểm tra từng phần nhỏ của code (tốc độ, độ bao phủ cao).
Integration Tests (Giữa): Kiểm tra tương tác giữa các thành phần.
E2E Tests (Đỉnh): Mô phỏng hành vi người dùng (ít, chỉ cho luồng quan trọng).
Pipeline CD Vững chắc: Toàn bộ quá trình từ commit code đến Production phải tự động hóa và không thể thương lượng (dừng lại ngay lập tức nếu có bất kỳ lỗi nào).
Giám sát và Quan sát (Monitoring & Observability): Sau khi triển khai, bạn phải biết ngay lập tức hệ thống có ổn không thông qua theo dõi chỉ số, cảnh báo (Alerting) và ghi lại log.
Các Kỹ thuật Triển khai An toàn (Safety Nets)
