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

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

Phát triển phần mềm truyền thống thường để người phát triển làm việc độc lập. Từng người được phân công cho một số nhiệm vụ nơi họ làm việc trên máy tính riêng của họ và công việc của họ không được tích hợp mãi cho tới cột mốc nào đó. Những người phát triển làm việc trong nhiều tuần trên các nhiệm vụ mà không nhận ra họ đã tạo ra bao nhiêu lỗi. Tất nhiên nhiệm vụ của họ phải qua kiểm thử đơn vị nhưng các vấn đề thường xảy ra trong kiểm thử tích hợp. Mã của họ càng được chia sẻ với những người khác, họ càng có nhiều vấn đề và phải mất nhiều thời gian và nỗ lực để sửa.

Phương pháp Agile tránh vấn đề này bằng việc yêu cầu mọi nhiệm vụ đều được tích hợp thường xuyên, thường trên cơ sở hàng ngày. Cách tiếp cận này được gọi là Tích hợp liên tục (CI) và qui tắc là người phát triển không bao giờ để cái gì không được tích hợp vào cuối ngày. Khi phần mềm được tích hợp hàng ngày, nếu có các vấn đề họ có thể sửa ngay lập tức. Bằng việc làm điều đó, mọi người sẽ bắt đầu từng ngày với một phiên bản dựng của phần mềm và điều này làm tăng chất lượng và năng suất của dự án. Bằng việc cho phép người dùng dùng phần mềm sớm hơn, điều đó khuyến khích phản hồi nhanh hơn giữa người dùng và người phát triển và giúp tổ làm những điều đúng trước khi đưa ra phần mềm chính thức. Tích hợp liên tục làm việc tốt khi tổ đã tự động hoá kiểm thử đơn vị mà đảm bảo phần mềm thường xuyên được kiểm thử để giảm bất kì rủi ro nào có thể xảy ra ở cuối.

Với các phương pháp phát triển truyền thống, tích hợp không xảy ra mãi cho tới muộn về sau và không ai biết họ có bao nhiêu lỗi chừng nào họ chưa làm kiểm thử tích hợp. Điều đó là rủi ro vì bạn đang để bản thân bạn vào tình huống không biết mãi tới phút cuối cùng. Thỉnh thoảng quá nhiều lỗi có thể trở thành đau đầu về lịch biểu chính cho tổ. Tích hợp liên tục giải quyết vấn đề này vì bạn không phải chờ đợi quá lâu. Nếu bạn phạm sai lầm bạn có thể sửa nó ngay lập tức. Tất nhiên Tích hợp liên tục không đảm bảo không có lỗi, nhưng nó làm cho họ dễ tìm và sửa hơn. Nếu bạn tạo ra bất kì lỗi nào, bạn sẽ nhanh chóng thấy ra trong vài giờ hay ở cuối ngày cho nên dễ sửa hơn vì bạn chỉ viết mã và logic vẫn còn mới trong trí nhớ của bạn.

Tác phẩm, tác giả, nguồn

  • Tác phẩm: Quản lý dự án
  • Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
  • Wiki hóa: https://kipkis.com

Có thể bạn muốn xem