Tích hợp liên tục (CI) là gì và nó hữu ích như thế nào? [đóng cửa]

Ai đó có thể giải thích cho tôi khái niệm về Tích hợp liên tục, làm thế nào nó hoạt động một cách dễ hiểu? Và tại sao một công ty nên áp dụng CI trong quy trình phân phối mã của họ? Tôi là một nhà phát triển và công ty của tôi (chủ yếu là nhóm xây dựng) sử dụng Team City. Là một nhà phát triển, tôi luôn kiểm tra, cập nhật và cam kết mã cho SVN nhưng không bao giờ thực sự phải bận tâm về TeamCity hay CI nói chung. Vậy tôi muốn hiểu tính hữu dụng của CI là gì? CI có phải là một phần của phương pháp Agile không?

Tích hợp liên tục trong tóm tắt có nghĩa là bạn lưu công việc của mình, bạn đẩy nó vào hệ thống quản lý tài liệu (SVN trong trường hợp của bạn), tất cả các kiểm tra được chạy tự động (cả kiểm tra đơn vị, tích hợp, chức năng, v.v.) và ứng dụng được biên dịch và chuẩn bị để phân phối (tức là hình ảnh ISO được tạo). Tích hợp liên tục không giống với Giao hàng liên tục. Giao hàng vẫn được thực hiện trong những thời điểm khác nhau. CI đảm bảo sản phẩm có thể được giao nếu cần, không có gì hơn.

Bất cứ khi nào có sự cố, nhóm sẽ nhận được thông báo. Thông thường tại thời điểm đó, mọi công việc đều bị dừng lại và mọi nỗ lực tập trung vào việc đảm bảo sản phẩm ở trạng thái ổn định. Không có sự thúc đẩy và cam kết xảy ra trên kho lưu trữ trong khi hệ thống không có màu xanh.

CI đảm bảo rằng sản phẩm luôn ở trạng thái ổn định và có khả năng có thể được giao bất cứ lúc nào. Xin lưu ý rằng ổn định không có nghĩa là tính năng hoàn thành. Cũng có thể có một nửa tính năng được triển khai, nhưng hệ thống có thể ổn định.

CI thường được liên kết với các phương pháp Agile, tuy nhiên cá nhân tôi không biết chính xác lịch sử của CI.

Tích hợp liên tục có nghĩa là: tích hợp mã vào một sản phẩm thực sự chạy và có thể được kiểm tra xảy ra mọi lúc , chứ không phải (như trường hợp trước đây) như một hoạt động riêng biệt vào cuối vòng đời phát triển.

Nó đòi hỏi quá trình xây dựng của ứng dụng phải hoàn toàn tự động, và một bộ kiểm thử tự động và một máy chủ xây dựng trạng thái hiện tại của mã và chạy bộ kiểm thử trên nó. Điều này sẽ xảy ra hàng ngày, hoặc thậm chí sau mỗi lần đăng ký mã.

Ưu điểm là có phản hồi ngay lập tức về các thay đổi mã gây ra lỗi biên dịch (ví dụ: do nhà phát triển không kiểm tra tất cả các thay đổi hoặc sử dụng một số thành phần không có trong hệ thống xây dựng) hoặc lỗi trường hợp thử nghiệm. Điều này làm cho các lỗi như vậy dễ dàng hơn nhiều để sửa chữa, vì bạn biết thay đổi nào gây ra chúng và người chịu trách nhiệm vẫn có những ký ức mới về những gì họ đã làm.

Không có CI, tất cả các lỗi này xuất hiện cùng một lúc trong giai đoạn tích hợp, điều này khiến chúng cực kỳ khó sửa.

Bạn có thể có một phong cách nhất định trong phát triển: Bạn kiểm tra, viết mã, biên dịch, kiểm tra, nguyền rủa, thay đổi, biên dịch, cổ vũ, cam kết. Bạn chỉ cam kết mã làm việc, thậm chí có thể theo kiểu ít chi tiết hơn vào cuối ngày làm việc hoặc khi một tính năng hoàn tất. Bạn xác minh sự phụ thuộc của mình bất cứ khi nào bạn nhập thư viện API.

Khi bạn bắt đầu viết mã cùng với những người khác và khi có sự phụ thuộc lẫn nhau, sẽ hợp lý khi áp dụng tích hợp liên tục. Đơn giản vì bạn không thể biết tác động của những thay đổi đối với những người phụ thuộc vào mã của bạn và bạn không nhận được tín hiệu nào mỗi khi bạn cần cập nhật hàng nhập của mình.

Vì vậy, khi một trong hai bạn thực hiện thay đổi, cả hai dự án nên được xây dựng và thử nghiệm cùng nhau, tức là chạy với API của nhau, được xây dựng và thử nghiệm với thư viện mới, v.v. Các thử nghiệm như vậy, mã của bạn và của người khác, được gọi là thử nghiệm tích hợp.

Tại sao liên tục? Bởi vì việc ủy ​​thác phối hợp tích hợp vào một hệ thống kiểm tra một bản dựng sạch sẽ dễ dàng hơn bất cứ khi nào có sự thay đổi trong cơ sở mã hơn là tổ chức tất cả những điều đó cho một con người. Hệ thống có thể mở rộng quy mô.

Có hai khía cạnh để tích hợp liên tục.

1. Chiến lược kiểm soát nguồn phát triển đảm bảo rằng các nhà phát triển có thể liên tục tích hợp công việc đang diễn ra của họ với mã ổn định của các nhà phát triển khác.
2. Việc xây dựng và kiểm tra mã nguồn tự động được kích hoạt bởi một cam kết đối với kiểm soát nguồn

Điểm 1 là rất quan trọng. Đó là động thái để làm cho các sự hợp nhất mà các nhà phát triển thực sự thực hiện là thường xuyên và bản chất nhỏ làm cho việc sáp nhập có nhiều khả năng thành công hơn.

Điểm 2 là các công cụ và khung cần thiết để cho phép điểm 1 xảy ra an toàn, nhanh chóng xác định các sự hợp nhất đã thất bại bằng cách phá vỡ mã hiện có.

Nó hữu ích như thế nào?

Thật đáng kinh ngạc. Là một nhà phát triển làm việc trong một dự án, nó cho phép bạn dành phần lớn thời gian tập trung vào những gì bạn đang làm và không lo lắng về công việc đồng thời từ các thành viên còn lại trong nhóm. Khi công việc hiện tại của bạn hoàn tất, sau đó bạn sẽ xuất bản các thay đổi của mình cho các thành viên còn lại trong nhóm và trong vài giờ tới, tất cả họ sẽ hợp nhất các thay đổi của bạn vào công việc hiện tại của họ.

Không có nó, các nhà phát triển đang thực hiện hợp nhất vụ nổ lớn. Thông thường mất vài ngày làm việc của họ và phải hợp nhất nó với tất cả các thay đổi được thực hiện bởi phần còn lại của nhóm trong một lần. Khi một sự hợp nhất trở nên tồi tệ đáng chú ý, nhà phát triển khác có thể đã chuyển sang công việc khác và bắt đầu quên các chi tiết tốt để giúp giải nén mớ hỗn độn. Thậm chí tệ hơn, nếu không có quá trình xây dựng và kiểm tra liên tục, miễn là mã biên dịch, các lỗi hợp nhất có thể xuất hiện trong mã và sẽ không được chọn cho đến khi thử nghiệm (hoặc khách hàng) tìm thấy chúng.

CI rất hữu ích khi bạn có:

• Biên soạn mã
• Bộ kiểm tra thực tế
• Các báo cáo, dựa trên mã nguồn của bạn (phạm vi bảo hiểm mã, bạo lực của tiêu chuẩn mã, v.v.)
• Thường xuyên mà bạn thực hiện định kỳ, sau khi mã được biên dịch thành công

Danh sách có thể được tiếp tục ..