Tích hợp liên tục

Trong kỹ thuật phần mềm, Tích hợp liên tục (CI - Continuous Integration) là việc trộn (merge) và biên dịch (build hoặc compile) tất cả các phiên bản (revision) mã nguồn làm việc của các lập trình viên trên một bản chính (mainline hoặc master) mỗi ngày. Grady Booch lần đầu tiên đặt tên và đề nghị về CI năm 1991, mặc dù ông không ủng hộ việc tích hợp nhiều lần một ngày. Nói một cách đơn giản, mã nguồn của dự án phần mềm cần được tích hợp lại vào một nhánh chính và chạy các lệnh build, kiểm thử... ít nhất một lần mỗi ngày.

Lập trình cực hạn (XP) thông qua các khái niệm của CI đã ủng hộ việc tích hợp nhiều hơn một lần mỗi ngày - có lẽ nhiều hơn hàng chục lần mỗi ngày.

== Lịch sử ==
Vào năm 1994, Grady Booch dùng cụm từ tích hợp liên tục trong sách của mình. Trong năm 1997, Kent Beck và Ron Jeffries phát minh lập trình XP có bao gồm cả tích hợp liên tục. Beck công bố về  tích hợp liên tục năm 1998, nhấn mạnh tầm quan trọng của giao tiếp mặt-đối-mặt. Trong năm 1999, Beck xây dựng cuốn sách đầy đủ hơn cho lập trình XP. Phần mềm CruiseControl được phát hành vào năm 2001.

== Cơ sở hình thành ==
Mục tiêu chính của CI là để ngăn chặn những vấn đề, được gọi là "địa ngục tích hợp" trong phần đầu mô tả của lập trình XP. CI không được chấp nhận là một sự cải tiến của việc Thường xuyên tích hợp, vì vậy cần phân biệt giữa hai phương pháp này, tùy theo sự bất đồng về triết lý của mỗi người.

Trong lập trình XP, CI đã được thiết kế để được sử dụng kết hợp với kiểm thử đơn vị, viết thông qua các hoạt động của Phát triển theo hướng kiểm thử (Test-driven development). Ban đầu, điều này nghĩa là chạy tất cả các kiểm thử đơn vị trên máy của nhà phát triển phần mềm trước khi đệ trình (commit) lên nhánh mainline. Điều này sẽ giúp tránh việc một nhà phát triển phá vỡ công việc của một nhà phát triển khác. Nếu cần thiết, một phần tính năng hoàn toàn có thể được vô hiệu hóa trước khi đệ trình, như sử dụng tính năng toggles.

== Luồng làm việc ==
Khi bắt tay làm việc, một nhà phát triển phần mềm sẽ lấy một bản sao của mã nguồn hiện tại để làm việc. Và sau đó, các nhà phát triển khác gửi mã nguồn đã thay đổi lên kho mã nguồn (repository) khiến cho bản sao ban đầu không còn cập nhật. Xung đột sẽ xảy ra khi nhà phát triển gửi bản sửa đổi của mình lên lại kho mã nguồn.

Một nhánh mã nguồn càng phát triển lâu càng dễ phát sinh xung đột khi các nhà phát triển tích hợp mã nguồn của mình trở lại kho mã nguồn. Đầu tiên họ phải tải lại các thay đổi của kho mã nguồn để trộn với các thay đổi của mình. Sau khi giải quyết xung đột, họ mới có thể gửi mã nguồn đó lên lại kho.

Tích hợp liên tục CI đòi hỏi tất cả các nhà phát triển phải tích hợp mã nguồn của mình lên kho mỗi ngày. Do đó, nó phần nào hạn chế các khó khăn khi trộn cách thay đổi với nhau.

Một bổ sung khác của CI là trước khi gửi mã nguồn lên kho, mỗi lập trình viên phải chạy tất cả các kiểm thử đơn vị. Kiểm thử tích hợp thường chạy tự động trên một máy chủ CI khi nó phát hiện một đệ trình (commit) mới.

== Các bài thực hành ==
Một số nguyên tắc của Tích hợp liên tục.

=== Duy trì một kho mã nguồn ===
Các dự án phần mềm nên có một kho lưu trữ mã nguồn. Có thể dùng các phần mềm quản lý mã nguồn như Git, Subversion...

=== Tự động hoá việc build phần mềm ===
Việc build dự án phần mềm cần được tự động hóa khi có sự thay đổi trong mã nguồn. Việc này có thể làm dựa trên các cơ chế hook của phần mềm quản lý mã nguồn hoặc dựa theo thời gian.

=== Làm cho việc build tự chạy kiểm thử ===
Sau khi mã nguồn đã được build, nó cần được chạy các kiểm thử đơn vị.

=== Tất cả mọi người gửi mã nguồn lên nhánh chính mỗi ngày ===
Gửi mã nguồn thường xuyên lên kho sẽ giúp phát hiện các xung đột nhanh chóng, hạn chế khó khăn khi trộn các phiên bản với nhau.

=== Mọi thay đổi mã nguồn (trên nhánh chính) cần được build ===
Tất cả các thay đổi về mã nguồn cần được build để đảm bảo khả năng tích hợp của thay đổi đó.

=== Giữ việc build diễn ra nhanh ===
Việc build diễn ra nhanh giúp phát hiện vấn đề nhanh khi tích hợp.

=== Kiểm thử trên một bản sao của môi trường production ===
Môi trường production có thể có nhiều khác biệt với môi trường kiểm thử, cần phải kiểm thử trên một bản sao của môi trường production để đảm bảo phần mềm hoạt động đúng.

=== Dễ dàng lấy được phiên bản build mới nhất ===
Các build cần dễ tiếp cho các bên liên quan để giảm thiểu thời gian cài đặt.

=== Tất cả mọi người có thể thấy kết quả build mới nhất ===
Dễ biết nguyên nhân build lỗi.

=== Triển khai tự động ===
Đa số hệ thống CI cho phép viết mã để triển khai phần mềm tự động sau khi build xong.

== Chi phí và lợi ích ==
CI có các lợi ích:
- Phát hiện sớm lỗi tích hợp, tiết kiệm thời gian và tiền bạc của dự án khi sửa lỗi.
- Hạn chế lỗi khi sắp đến ngày bàn giao sản phẩm
- Nhà phát tiển giảm thời gian sửa lỗi khi phát hiện lỗi lúc chạy kiểm thử đơn vị do họ thường xuyên chạy chúng. Các lỗi sẽ nhỏ hơn do đó tiết kiêm thời gian sửa chữa.
- Luôn có được một sản phẩm có thể chạy hoặc demo cho khách hàng

== Phần mềm phục vụ CI ==
Bảng sau đây liệt kê một số phần mềm phổ biến phục vụ triển khai Tích hợp liên tục. Những phần mềm thông dụng trong CI là Jenkins, Travis-CI, TeamCity, Bamboo...
== Xem thêm ==
- Tích hợp liên tục
- Phân phối liên tục
- Kiểm thử liên tục
- Hệ thống quản lý phiên bản
- Lập trình cực hạn
- Lập trình linh hoạt