Giới thiệu về Tích hợp, Phân phối và Triển khai Liên tục
Phát triển và phát hành phần mềm có thể là một quá trình phức tạp, đặc biệt là khi các ứng dụng, group và cơ sở hạ tầng triển khai tự phát triển với độ phức tạp. Thông thường, những thách thức trở nên rõ rệt hơn khi các dự án phát triển. Để phát triển, kiểm tra và phát hành phần mềm một cách nhanh chóng và nhất quán, các nhà phát triển và tổ chức đã tạo ra ba chiến lược liên quan nhưng riêng biệt để quản lý và tự động hóa các quy trình này.Tích hợp liên tục tập trung vào việc tích hợp công việc từ các nhà phát triển riêng lẻ vào một repository chính nhiều lần trong ngày để phát hiện sớm các lỗi tích hợp và tăng tốc phát triển cộng tác. Phân phối liên tục có liên quan đến việc giảm ma sát trong quá trình triển khai hoặc phát hành, tự động hóa các bước cần thiết để triển khai một bản dựng để mã có thể được phát hành an toàn bất cứ lúc nào. Việc triển khai liên tục sẽ tiến thêm một bước nữa bằng cách tự động triển khai mỗi khi thực hiện thay đổi mã.
Trong hướng dẫn này, ta sẽ thảo luận về từng chiến lược này, cách chúng liên quan với nhau và cách kết hợp chúng vào vòng đời ứng dụng của bạn có thể biến đổi các phương pháp phát triển và phát hành phần mềm của bạn. Để hiểu rõ hơn về sự khác biệt giữa các dự án CI / CD open-souce khác nhau, hãy xem phần so sánh công cụ CI / CD của ta .
Tích hợp liên tục là gì và tại sao nó hữu ích?
Tích hợp liên tục là một thực tiễn khuyến khích các nhà phát triển tích hợp mã của họ vào một nhánh chính của repository được chia sẻ sớm và thường xuyên. Thay vì xây dựng các tính năng một cách riêng lẻ và tích hợp chúng vào cuối chu kỳ phát triển, mã được tích hợp với repository được chia sẻ bởi mỗi nhà phát triển nhiều lần trong ngày.
Ý tưởng là giảm thiểu chi phí tích hợp bằng cách xem xét sớm nó. Các nhà phát triển có thể phát hiện sớm các xung đột ở ranh giới giữa mã mới và mã hiện có, trong khi các xung đột vẫn tương đối dễ hòa giải. Khi xung đột được giải quyết, công việc có thể tiếp tục với sự tin tưởng rằng mã mới đáp ứng các yêu cầu của cơ sở mã hiện có.
Việc tích hợp mã thường xuyên tự nó không cung cấp bất kỳ đảm bảo nào về chất lượng của mã hoặc chức năng mới. Trong nhiều tổ chức, việc tích hợp rất tốn kém vì các quy trình thủ công được sử dụng đảm bảo rằng mã đáp ứng các tiêu chuẩn, không đưa ra lỗi và không phá vỡ chức năng hiện có. Việc tích hợp thường xuyên có thể tạo ra xung đột khi mức độ tự động hóa không phù hợp với các biện pháp đảm bảo chất lượng về số lượng tại chỗ.
Trên thực tế, để giải quyết vấn đề này trong quá trình tích hợp, tích hợp liên tục dựa vào các bộ thử nghiệm mạnh mẽ và một hệ thống tự động để chạy các thử nghiệm đó. Khi một nhà phát triển hợp nhất mã vào repository chính, các quy trình tự động bắt đầu xây dựng mã mới. Sau đó, các bộ thử nghiệm được chạy trên bản dựng mới để kiểm tra xem có bất kỳ sự cố tích hợp nào được đưa ra hay không. Nếu quá trình xây dựng hoặc giai đoạn thử nghiệm không thành công, group sẽ được thông báo để họ có thể làm việc để khắc phục bản dựng.
Mục tiêu cuối cùng của tích hợp liên tục là làm cho việc tích hợp trở thành một quá trình đơn giản, có thể lặp lại, là một phần của quy trình phát triển hàng ngày nhằm giảm chi phí tích hợp và sớm ứng phó với các khiếm khuyết. Làm việc đảm bảo hệ thống hoạt động mạnh mẽ, tự động và nhanh chóng trong khi nuôi dưỡng văn hóa group khuyến khích lặp lại thường xuyên và phản hồi nhanh để xây dựng các vấn đề là điều cơ bản cho sự thành công của chiến lược.
Phân phối liên tục là gì và tại sao nó hữu ích?
Phân phối liên tục là một phần mở rộng của tích hợp liên tục. Nó tập trung vào việc tự động hóa quy trình phân phối phần mềm để các group có thể dễ dàng và tự tin triển khai mã của họ vào production bất cứ lúc nào. Bằng cách đảm bảo cơ sở mã luôn ở trạng thái có thể triển khai, việc phát hành phần mềm trở thành một sự kiện không đáng kể mà không cần đến các nghi thức phức tạp. Các đội có thể tự tin rằng họ có thể phát hành khi nào họ cần mà không cần phối hợp phức tạp hoặc kiểm tra giai đoạn cuối. Cũng như tích hợp liên tục, phân phối liên tục là một hoạt động đòi hỏi sự kết hợp của các cải tiến kỹ thuật và tổ chức để có hiệu quả.
Về mặt công nghệ, phân phối liên tục chủ yếu dựa vào các đường ống triển khai để tự động hóa các quy trình thử nghiệm và triển khai. Đường ống triển khai là một hệ thống tự động chạy các bộ thử nghiệm ngày càng nghiêm ngặt dựa trên việc xây dựng như một chuỗi các giai đoạn tuần tự. Điều này bắt nguồn từ việc tích hợp liên tục, do đó, cài đặt tích hợp liên tục tin cậy là yêu cầu để triển khai phân phối liên tục.
Ở mỗi giai đoạn, bản dựng không đạt được các bài kiểm tra, điều này sẽ cảnh báo cho group hoặc vượt qua các bài kiểm tra, dẫn đến việc tự động thăng hạng lên giai đoạn tiếp theo. Khi bản dựng di chuyển qua đường ống, các giai đoạn sau sẽ triển khai bản dựng đến các môi trường phản ánh môi trường production càng gần càng tốt. Bằng cách này, quá trình xây dựng, quá trình triển khai và môi trường có thể được kiểm tra song song. Đường ống kết thúc bằng một bản dựng có thể được triển khai vào production bất kỳ lúc nào trong một bước duy nhất.
Các khía cạnh tổ chức của phân phối liên tục khuyến khích ưu tiên “khả năng triển khai” như một mối quan tâm chính. Điều này có tác động đến cách các tính năng được xây dựng và kết nối với phần còn lại của cơ sở mã. Ý tưởng phải được đưa vào thiết kế của mã để các tính năng có thể được triển khai một cách an toàn vào production bất cứ lúc nào, ngay cả khi chưa hoàn thiện. Một số kỹ thuật đã xuất hiện để hỗ trợ trong lĩnh vực này.
Phân phối liên tục rất hấp dẫn vì nó tự động hóa các bước giữa việc kiểm tra mã vào repository và quyết định xem có phát hành các bản dựng chức năng, đã được kiểm tra tốt cho cơ sở hạ tầng production của bạn hay không. Các bước giúp khẳng định chất lượng và tính đúng đắn của mã được tự động hóa, nhưng quyết định cuối cùng về những gì sẽ phát hành được để trong tay của tổ chức để có sự linh hoạt tối đa.
Triển khai liên tục là gì và tại sao nó lại hữu ích?
Triển khai liên tục là một phần mở rộng của phân phối liên tục, tự động triển khai từng bản dựng vượt qua chu kỳ thử nghiệm đầy đủ. Thay vì đợi người gác cổng quyết định cái gì và khi nào sẽ triển khai cho production , một hệ thống triển khai liên tục triển khai mọi thứ đã thành công trong quá trình triển khai. Lưu ý mặc dù mã mới được triển khai tự động, nhưng vẫn tồn tại các kỹ thuật để kích hoạt các tính năng mới sau này hoặc cho một group nhỏ user . Việc triển khai tự động đẩy các tính năng và bản sửa lỗi cho khách hàng một cách nhanh chóng, khuyến khích các thay đổi nhỏ hơn với phạm vi hạn chế và giúp tránh nhầm lẫn về những gì hiện đang được triển khai cho production .
Chu trình triển khai hoàn toàn tự động này có thể là nguồn root gây lo lắng cho các tổ chức lo lắng về việc từ bỏ quyền kiểm soát đối với hệ thống tự động hóa của họ về những gì được phát hành.Sự đánh đổi được cung cấp bởi các triển khai tự động đôi khi được đánh giá là quá nguy hiểm đối với thành quả mà chúng mang lại.
Các group khác tận dụng lời hứa về việc phát hành tự động như một phương pháp đảm bảo các thực hành tốt nhất luôn được tuân theo và để mở rộng quy trình thử nghiệm vào một môi trường production hạn chế. Nếu không có xác minh thủ công cuối cùng trước khi triển khai một đoạn mã, các nhà phát triển phải chịu trách nhiệm đảm bảo mã của họ được thiết kế tốt và các bộ thử nghiệm được cập nhật. Điều này làm sụp đổ quyết định về cái gì và khi nào thì commit với repository chính và cái gì và khi nào thì phát hành vào production thành một điểm duy nhất tồn tại chắc chắn trong tay của group phát triển.
Việc triển khai liên tục cũng cho phép các tổ chức hưởng lợi từ những phản hồi sớm nhất quán. Các tính năng có thể được cung cấp ngay lập tức cho user và các lỗi hoặc triển khai không hữu ích có thể được phát hiện sớm trước khi group dành nhiều nỗ lực theo hướng không hiệu quả. Nhận phản hồi nhanh rằng một tính năng không hữu ích cho phép group chuyển trọng tâm thay vì dồn nhiều năng lượng hơn vào một khu vực có tác động tối thiểu.
Các khái niệm và thực hành chính cho các quá trình liên tục
Mặc dù tích hợp, phân phối và triển khai liên tục khác nhau về phạm vi tham gia của chúng, nhưng có một số khái niệm và thực hành là cơ bản cho sự thành công của mỗi loại.
Các thay đổi nhỏ, lặp đi lặp lại
Một trong những thực tiễn quan trọng nhất khi áp dụng tích hợp liên tục là khuyến khích những thay đổi nhỏ. Các nhà phát triển nên thực hành chia nhỏ công việc lớn hơn thành các phần nhỏ và thực hiện sớm. Các kỹ thuật đặc biệt như rẽ nhánh theo trừu tượng và cờ đặc trưng (xem bên dưới) giúp bảo vệ chức năng của nhánh chính khỏi những thay đổi mã đang diễn ra.
Những thay đổi nhỏ giảm thiểu khả năng và tác động của các vấn đề tích hợp. Bằng cách commit với nhánh chia sẻ ở giai đoạn sớm nhất có thể và sau đó liên tục trong suốt quá trình phát triển, chi phí tích hợp được giảm bớt và các công việc không liên quan được đồng bộ hóa thường xuyên.
Phát triển dựa trên thân cây
Với sự phát triển dựa trên thân cây, công việc được thực hiện trong nhánh chính của repository hoặc được hợp nhất trở lại repository dùng chung theo các khoảng thời gian thường xuyên. Cho phép các nhánh tính năng tồn tại trong thời gian ngắn miễn là chúng đại diện cho những thay đổi nhỏ và được hợp nhất trở lại càng sớm càng tốt.
Ý tưởng đằng sau sự phát triển dựa trên thân cây là tránh các commit lớn vi phạm khái niệm về các thay đổi nhỏ, lặp đi lặp lại đã thảo luận ở trên. Mã có sẵn cho các đồng nghiệp sớm để các xung đột có thể được giải quyết khi phạm vi của chúng còn nhỏ.
Việc phát hành được thực hiện từ nhánh chính hoặc từ một nhánh phát hành được tạo ra từ thân cây đặc biệt cho mục đích đó. Không có sự phát triển nào xảy ra trên các nhánh phát hành để duy trì sự tập trung vào nhánh chính như là nguồn sự thật duy nhất.
Giữ các giai đoạn xây dựng và thử nghiệm nhanh chóng
Mỗi quy trình dựa trên xây dựng và thử nghiệm tự động để xác nhận tính đúng đắn. Bởi vì các bước xây dựng và kiểm tra phải được thực hiện thường xuyên, điều cần thiết là các quy trình này phải được sắp xếp hợp lý để giảm thiểu thời gian dành cho các bước này.
Việc tăng thời gian xây dựng nên được coi là một vấn đề lớn vì tác động của nó là do thực tế là mỗi lần commit khởi động một bản dựng.Bởi vì các quy trình liên tục buộc các nhà phát triển phải tham gia vào các hoạt động này hàng ngày, nên việc giảm thiểu ma sát trong các lĩnh vực này là một mục tiêu đáng theo đuổi.
Khi có thể, chạy song song các phần khác nhau của bộ thử nghiệm có thể giúp di chuyển bản dựng qua đường ống nhanh hơn. Cũng nên cẩn thận đảm bảo tỷ lệ của mỗi loại thử nghiệm có ý nghĩa. Các bài kiểm tra đơn vị thường rất nhanh và có chi phí bảo trì tối thiểu. Ngược lại, hệ thống tự động hoặc kiểm thử chấp nhận thường phức tạp và dễ bị hỏng. Để giải thích điều này, bạn nên dựa nhiều vào các bài kiểm tra đơn vị, tiến hành một số bài kiểm tra tích hợp hợp lý và sau đó dựa vào số lần kiểm tra phức tạp hơn sau này.
Tính nhất quán trong suốt lộ trình triển khai
Bởi vì triển khai phân phối hoặc triển khai liên tục được cho là mức độ phù hợp của bản phát hành thử nghiệm, điều cần thiết là phải duy trì tính nhất quán trong mỗi bước của quy trình — bản thân xây dựng, môi trường triển khai và bản thân quá trình triển khai:
- Mã nên được xây dựng một lần khi bắt đầu quy trình : Phần mềm kết quả phải được lưu trữ và có thể truy cập vào các quy trình sau này mà không cần xây dựng lại. Bằng cách sử dụng cùng một tạo tác chính xác trong mỗi giai đoạn, bạn có thể chắc chắn rằng bạn không tạo ra sự mâu thuẫn do kết quả của các công cụ xây dựng khác nhau.
- Môi trường triển khai phải nhất quán : Hệ thống quản lý cấu hình có thể kiểm soát các môi trường khác nhau và các thay đổi môi trường có thể được thực hiện thông qua chính quy trình triển khai đảm bảo tính đúng đắn và nhất quán. Môi trường triển khai sạch nên được cung cấp cho mỗi chu kỳ thử nghiệm để ngăn các điều kiện kế thừa ảnh hưởng đến tính toàn vẹn của các thử nghiệm. Môi trường dàn dựng phải phù hợp với môi trường production nhất có thể để giảm thiểu các yếu tố không xác định xuất hiện khi quá trình xây dựng được xúc tiến.
- Các quy trình nhất quán nên được sử dụng để triển khai bản dựng trong từng môi trường : Mỗi quá trình triển khai phải được tự động hóa và mỗi lần triển khai phải sử dụng cùng các công cụ và thủ tục tập trung. Việc triển khai đặc biệt nên được loại bỏ để chỉ triển khai với các công cụ đường ống.
Tách triển khai và phát hành
Tách việc triển khai mã khỏi bản phát hành cho user là một phần cực kỳ mạnh mẽ của phân phối và triển khai liên tục. Mã có thể được triển khai cho production mà không cần kích hoạt ban đầu hoặc làm cho nó có thể truy cập được cho user . Sau đó, tổ chức quyết định thời điểm phát hành chức năng hoặc tính năng mới độc lập với việc triển khai.
Điều này mang lại cho các tổ chức rất nhiều tính linh hoạt bằng cách tách các quyết định kinh doanh khỏi các quy trình kỹ thuật. Nếu mã đã có trên server , thì việc triển khai không còn là một phần tế nhị của quá trình phát hành, điều này giảm thiểu số lượng cá nhân và dung lượng công việc liên quan tại thời điểm phát hành.
Có một số kỹ thuật giúp các group triển khai mã chịu trách nhiệm cho một tính năng mà không cần phát hành nó. Các cờ tính năng cài đặt logic có điều kiện để kiểm tra xem có chạy mã dựa trên giá trị của một biến môi trường hay không. Phân nhánh theo sự trừu tượng cho phép các nhà phát triển thay thế các triển khai bằng cách đặt một lớp trừu tượng giữa người tiêu dùng và nhà cung cấp tài nguyên. Lập kế hoạch cẩn thận để kết hợp các kỹ thuật này mang lại cho bạn khả năng tách rời hai quy trình này.
Các loại kiểm tra
Việc tích hợp, phân phối và triển khai liên tục đều dựa chủ yếu vào các bài kiểm tra tự động để xác định hiệu quả và tính đúng đắn của mỗi lần thay đổi mã. Các loại thử nghiệm khác nhau là cần thiết trong suốt các quá trình này để đạt được sự tin tưởng vào một giải pháp nhất định.
Mặc dù các danh mục dưới đây không đại diện cho một danh sách đầy đủ và mặc dù có sự bất đồng về định nghĩa chính xác của từng loại, các danh mục thử nghiệm rộng này đại diện cho nhiều cách khác nhau để đánh giá mã trong các ngữ cảnh khác nhau.
Kiểm tra khói
Kiểm tra khói là một loại kiểm tra ban đầu đặc biệt được thiết kế đảm bảo chức năng rất cơ bản cũng như một số thực hiện cơ bản và các giả định về môi trường. Kiểm tra khói thường được chạy vào đầu mỗi chu kỳ thử nghiệm như một kiểm tra sự tỉnh táo trước khi chạy bộ thử nghiệm hoàn chỉnh hơn.
Ý tưởng đằng sau loại thử nghiệm này là giúp nắm bắt được những dấu hiệu nổi bật trong quá trình triển khai và thu hút sự chú ý đến các vấn đề có thể cho biết thử nghiệm thêm là không thể hoặc không đáng giá. Thử nghiệm khói không quá rộng, nhưng sẽ cực kỳ nhanh chóng. Nếu một thay đổi không thực hiện được thử nghiệm khói, đó là tín hiệu sớm cho thấy các xác nhận cốt lõi đã bị hỏng và bạn không nên dành thêm thời gian để thử nghiệm cho đến khi sự cố được giải quyết.
Các thử nghiệm khói theo ngữ cảnh cụ thể được dùng khi bắt đầu bất kỳ thử nghiệm giai đoạn mới nào để khẳng định rằng các giả định và yêu cầu cơ bản được đáp ứng. Ví dụ: thử nghiệm khói được dùng cả trước khi thử nghiệm tích hợp hoặc triển khai cho các server dàn, nhưng các điều kiện được kiểm tra sẽ khác nhau trong từng trường hợp.
Kiểm tra đơn vị
Các bài kiểm tra đơn vị chịu trách nhiệm kiểm tra các phần tử riêng lẻ của mã theo cách riêng biệt và được nhắm đến cao. Chức năng của các chức năng và lớp riêng lẻ được kiểm tra riêng. Bất kỳ phần phụ thuộc bên ngoài nào cũng được thay thế bằng các triển khai sơ khai hoặc mô phỏng để tập trung hoàn toàn thử nghiệm vào mã được đề cập.
Các bài kiểm tra đơn vị là điều cần thiết để kiểm tra tính đúng đắn của các thành phần mã riêng lẻ về tính nhất quán và tính đúng đắn bên trong trước khi chúng được đặt trong các ngữ cảnh phức tạp hơn. Mức độ hạn chế của các bài kiểm tra và việc loại bỏ các phụ thuộc giúp việc tìm kiếm nguyên nhân của bất kỳ khiếm khuyết nào trở nên dễ dàng hơn. Đây cũng là thời điểm tốt nhất để kiểm tra nhiều loại đầu vào và các nhánh mã có thể khó đạt được sau này. Thông thường, sau bất kỳ thử nghiệm khói nào, kiểm tra đơn vị là kiểm tra đầu tiên được thực hiện khi có bất kỳ thay đổi nào.
Các bài kiểm tra đơn vị thường do các nhà phát triển riêng lẻ chạy trên trạm làm việc của riêng họ trước khi gửi các thay đổi. Tuy nhiên, các server tích hợp liên tục hầu như luôn chạy lại các bài kiểm tra này như một biện pháp bảo vệ an toàn trước khi bắt đầu các bài kiểm tra tích hợp.
Thử nghiệm hội nhập
Sau các bài kiểm tra đơn vị, kiểm tra tích hợp được thực hiện bằng cách group các thành phần lại với nhau và kiểm tra chúng dưới dạng lắp ráp. Trong khi các bài kiểm tra đơn vị xác nhận chức năng của mã một cách riêng biệt, các bài kiểm tra tích hợp đảm bảo các thành phần hợp tác khi giao tiếp với nhau. Loại thử nghiệm này có cơ hội bắt được một lớp lỗi hoàn toàn khác được phát hiện thông qua tương tác giữa các thành phần.
Thông thường, các bài kiểm tra tích hợp được thực hiện tự động khi mã được kiểm tra vào repository được chia sẻ. Server tích hợp liên tục kiểm tra mã, thực hiện bất kỳ bước xây dựng cần thiết nào (thường thực hiện kiểm tra khói nhanh đảm bảo quá trình xây dựng thành công) và sau đó chạy kiểm tra đơn vị và tích hợp. Các module được nối với nhau theo các cách kết hợp khác nhau và được thử nghiệm.
Các bài kiểm tra tích hợp rất quan trọng đối với công việc được chia sẻ vì chúng bảo vệ sức khỏe của dự án. Các thay đổi phải chứng minh rằng chúng không phá vỡ chức năng hiện có và chúng tương tác với mã khác như mong đợi. Mục đích thứ hai của thử nghiệm tích hợp là để xác minh các thay đổi có thể được triển khai trong một môi trường sạch. Đây thường là chu kỳ thử nghiệm đầu tiên được thực hiện trên máy của chính nhà phát triển, vì vậy phần mềm không xác định và phụ thuộc môi trường cũng có thể được phát hiện trong quá trình này. Đây cũng thường là lần đầu tiên mã mới được kiểm tra dựa trên các thư viện, dịch vụ và dữ liệu thực bên ngoài.
Thử nghiệm hệ thống
Sau khi các bài kiểm tra tích hợp được thực hiện, một cấp độ kiểm tra khác được gọi là kiểm tra hệ thống có thể bắt đầu. Theo nhiều cách, kiểm thử hệ thống hoạt động như một phần mở rộng cho kiểm thử tích hợp. Trọng tâm của các bài kiểm tra hệ thống là đảm bảo các group thành phần hoạt động chính xác như một tổng thể mount .
Thay vì tập trung vào giao diện giữa các thành phần, các bài kiểm tra hệ thống thường đánh giá chức năng bên ngoài của một phần mềm đầy đủ. Tập hợp các bài kiểm tra này bỏ qua các phần cấu thành để đánh giá phần mềm được cấu thành như một thực thể thống nhất. Do sự khác biệt này, các bài kiểm tra hệ thống thường tập trung vào các giao diện user hoặc bên ngoài có thể truy cập.
Kiểm tra chấp nhận
Kiểm tra chấp nhận là một trong những loại kiểm tra cuối cùng được thực hiện trên phần mềm trước khi giao hàng. Kiểm thử chấp nhận được sử dụng để xác định xem một phần mềm có đáp ứng tất cả các yêu cầu từ quan điểm của doanh nghiệp hoặc user hay không. Các bài kiểm tra này đôi khi được xây dựng dựa trên đặc điểm kỹ thuật root và thường kiểm tra các giao diện về chức năng mong đợi và khả năng sử dụng.
Kiểm thử chấp nhận thường là một giai đoạn liên quan nhiều hơn có thể kéo dài sau khi phát hành phần mềm. Kiểm tra chấp nhận tự động được dùng đảm bảo các yêu cầu công nghệ của thiết kế được đáp ứng, nhưng kiểm tra thủ công cũng thường đóng một role nhất định.
Thông thường, kiểm tra chấp nhận bắt đầu bằng cách triển khai bản dựng đến một môi trường dàn dựng phản chiếu hệ thống production . Từ đây, các bộ kiểm tra tự động có thể được chạy và user nội bộ có thể truy cập hệ thống để kiểm tra xem nó có hoạt động theo cách họ cần hay không. Sau khi phát hành hoặc cung cấp quyền truy cập beta cho khách hàng, kiểm tra chấp nhận thêm được thực hiện bằng cách đánh giá cách phần mềm hoạt động khi sử dụng thực tế và bằng cách thu thập phản hồi từ user .
Thuật ngữ bổ sung
Trong khi ta đã thảo luận về một số ý tưởng rộng hơn ở trên, có nhiều khái niệm liên quan mà bạn có thể bắt gặp khi tìm hiểu về tích hợp, phân phối và triển khai liên tục. Hãy xác định một số thuật ngữ khác mà bạn có thể thấy:
- Triển khai Blue-Green : Triển khai blue-green là một chiến lược để kiểm tra mã trong môi trường giống như production và để triển khai mã với thời gian chết tối thiểu.Hai group môi trường có khả năng production được duy trì và mã được triển khai cho group không hoạt động nơi thử nghiệm có thể diễn ra. Khi sẵn sàng phát hành, lưu lượng production được chuyển đến các server với mã mới, ngay lập tức áp dụng các thay đổi .
- Nhánh theo trừu tượng : Nhánh theo trừu tượng là một phương pháp thực hiện các hoạt động tái cấu trúc chính trong một dự án đang hoạt động mà không có các nhánh phát triển tồn tại lâu dài trong repository mã nguồn, điều mà các phương pháp tích hợp liên tục không khuyến khích. Một lớp trừu tượng được xây dựng và triển khai giữa user và triển khai hiện tại để triển khai mới có thể được xây dựng song song đằng sau lớp trừu tượng.
- Bản dựng (danh từ) : Bản dựng là một version cụ thể của phần mềm được tạo từ mã nguồn. Tùy thuộc vào ngôn ngữ, đây có thể là mã được biên dịch hoặc một bộ mã được thông dịch nhất quán.
- Bản phát hành Canary : Bản phát hành Canary là một chiến lược để phát hành các thay đổi cho một group nhỏ user hạn chế. Ý tưởng là đảm bảo mọi thứ hoạt động chính xác với dung lượng công việc production trong khi giảm thiểu tác động nếu có vấn đề.
- Chạy tối : Chạy tối là hoạt động triển khai mã cho quá trình production nhận được lưu lượng truy cập production nhưng không ảnh hưởng đến trải nghiệm user . Các thay đổi mới được triển khai cùng với các triển khai hiện có và cùng một lưu lượng thường được chuyển đến cả hai nơi để thử nghiệm. Việc triển khai cũ vẫn được kết nối với giao diện của user , nhưng đằng sau mức thấp , mã mới có thể được đánh giá về tính đúng đắn bằng cách sử dụng các yêu cầu thực của user trong môi trường production .
- Đường ống triển khai : Đường ống triển khai là một tập hợp các thành phần di chuyển phần mềm thông qua các kịch bản thử nghiệm và triển khai ngày càng nghiêm ngặt để đánh giá mức độ sẵn sàng phát hành của phần mềm. Quy trình này thường kết thúc bằng cách tự động triển khai vào production hoặc cung cấp tùy chọn để làm điều đó theo cách thủ công.
- Cờ đặc trưng hoặc Chuyển đổi tính năng : Cờ đặc trưng là một kỹ thuật triển khai các tính năng mới đằng sau logic có điều kiện để xác định có chạy hay không dựa trên giá trị của một biến môi trường. Mã mới có thể được triển khai cho production mà không cần được kích hoạt bằng cách đặt cờ một cách thích hợp. Để phát hành phần mềm, giá trị của biến môi trường được thay đổi, làm cho đường dẫn mã mới được kích hoạt. Cờ tính năng thường chứa logic cho phép tập hợp con user có quyền truy cập vào tính năng mới, tạo cơ chế triển khai dần mã mới.
- Quảng bá : Trong bối cảnh các quy trình liên tục, quảng cáo nghĩa là chuyển một bản xây dựng phần mềm sang giai đoạn thử nghiệm tiếp theo.
- Kiểm tra ngâm : Kiểm tra ngâm liên quan đến việc kiểm tra phần mềm trong production quan trọng hoặc tải tương tự như production trong một khoảng thời gian dài.
Kết luận
Trong hướng dẫn này, ta đã giới thiệu tích hợp liên tục, phân phối liên tục và triển khai liên tục cũng như thảo luận về cách chúng được dùng để xây dựng và phát hành phần mềm đã được kiểm tra tốt một cách an toàn và nhanh chóng. Các quy trình này tận dụng tự động hóa rộng rãi và khuyến khích chia sẻ mã liên tục để sớm sửa chữa các lỗi. Mặc dù các kỹ thuật, quy trình và công cụ cần thiết để thực hiện các giải pháp này là một thách thức đáng kể, nhưng lợi ích của một hệ thống được thiết kế tốt và sử dụng đúng cách có thể là rất lớn.
Để tìm hiểu giải pháp CI / CD nào có thể phù hợp với dự án của bạn, hãy xem hướng dẫn so sánh công cụ CI / CD của ta để biết thêm thông tin.
Các tin liên quan
