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,[1] 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ử
[sửa | sửa mã nguồn]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.[2] 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.[3] Trong năm 1999, Beck xây dựng cuốn sách đầy đủ hơn cho lập trình XP.[4] Phần mềm CruiseControl được phát hành vào năm 2001.
Cơ sở hình thành
[sửa | sửa mã nguồn]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.[cần dẫn nguồn]
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
[sửa | sửa mã nguồn]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
[sửa | sửa mã nguồn]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
[sửa | sửa 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
[sửa | sửa mã nguồn]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ử
[sửa | sửa mã nguồn]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
[sửa | sửa mã nguồn]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
[sửa | sửa mã nguồn]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
[sửa | sửa mã nguồn]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
[sửa | sửa mã nguồn]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
[sửa | sửa mã nguồn]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
[sửa | sửa mã nguồn]Dễ biết nguyên nhân build lỗi.
Triển khai tự động
[sửa | sửa mã nguồn]Đ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.[5][6]
Chi phí và lợi ích
[sửa | sửa mã nguồn]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
[sửa | sửa mã nguồn]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
[sửa | sửa mã nguồn]- 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
Tham khảo
[sửa | sửa mã nguồn]- ^ Booch, Grady (1991). Object Oriented Design: With Applications. Benjamin Cummings. p. 209. ISBN 9780805300918. Truy cập 2014-08-18.
- ^ Fowler, Martin (ngày 1 tháng 5 năm 2006). “Continuous Integration”. martinfowler.com. Truy cập ngày 9 tháng 1 năm 2014.
- ^ Beck, Kent (1998-03-28). "Extreme Programming: A Humanistic Discipline of Software Development". Fundamental Approaches to Software Engineering: First International Conference, FASE'98, Held as Part of the Joint European Conferences on Theory and Practice of Software, ETAPS'98, Lisbon, Portugal, March 28 - ngày 4 tháng 4 năm 1998, Proceedings, Volume 1. Lisbon: Springer. p. 4. ISBN 9783540643036.
- ^ Beck, Kent (1999). Extreme Programming Explained. ISBN 0-201-61641-6.
- ^ Ries, Eric (ngày 30 tháng 3 năm 2009). “Continuous deployment in 5 easy steps”. O’Reilly. Truy cập ngày 10 tháng 1 năm 2013.
- ^ Fitz, Timothy (ngày 10 tháng 2 năm 2009). “Continuous Deployment at IMVU: Doing the impossible fifty times a day”. Wordpress. Truy cập ngày 10 tháng 1 năm 2013.
- ^ “Continuum Features”. Continuum. Apache Software Foundation. ngày 23 tháng 9 năm 2013. Truy cập ngày 3 tháng 3 năm 2014.
- ^ “MSBuild”.
- ^ “NAnt”.
- ^ “Visual Studio”.
- ^ “Ant”.
- ^ “Maven”.
- ^ “Xcode”.
- ^ “Bản sao đã lưu trữ”. Bản gốc lưu trữ ngày 7 tháng 4 năm 2015. Truy cập ngày 17 tháng 11 năm 2016.
- ^ “"Resource types"”. Bản gốc lưu trữ ngày 13 tháng 11 năm 2016. Truy cập ngày 17 tháng 11 năm 2016.
- ^ “Building a Java project in Travis CI”.