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.

—-English version—-

Continuous integration

Traditional software development often lets developers work independently. Each is assigned a number of tasks where they work on their own computer and their works are not integrated until certain milestone. Developers work for weeks on tasks without realizing how many bugs that they created. Of course their tasks pass unit tests but problems often happen during integration test. The more their code is shared with others, the more problems they have and it takes lots of time and efforts to fix.

Agile development avoids this problem by require all tasks to be integrated frequently, usually on a daily basis. This approach is called Continuous Integration (CI) and the rule is developers never leave anything un-integrated at the end of the day. When software is integrated daily, if there are problems they can be fixed immediately. By doing that, everyone will start each day with a clean build version of software and this increases the quality and productivity of the project. By allowing users to use software sooner, it encourages faster feedbacks between users and developers and helps the team do things right before the formal software release. Continuous integration works well when the team has automated unit tests that ensure software is constantly tested to reduce any risk that may happen at the end.

With traditional development methods, integration does not happen until later and no one knows how many bugs that they have until integration test. It is risky as you are putting yourself into an unknown situation until the last minute. Sometime too many bugs could become a major schedule headache for the team. Continuous Integration solves this problem since you do not have to wait too long. If you make mistake you can fix it immediately. Of course Continuous Integrations does guarantee no bugs, but it makes them easier to find and fix. If you create any bug, you will find out quickly within few hours or at the end of the day so it is easier to fix since you just write the code and the logic is still fresh in your memory.