Bạn không thể biết CI là gì trừ khi bạn biết chúng ta đã từng làm gì. Hãy tưởng tượng một hệ thống có 3 phần. Có một UI thu thập dữ liệu và đưa nó vào cơ sở dữ liệu. Có một hệ thống báo cáo tạo báo cáo từ cơ sở dữ liệu. Và có một số loại máy chủ theo dõi cơ sở dữ liệu và gửi thông báo qua email nếu các tiêu chí nhất định được đáp ứng.
Từ lâu điều này sẽ được viết như sau:
- Đồng ý về lược đồ cho cơ sở dữ liệu và các yêu cầu - việc này sẽ mất vài tuần vì nó phải hoàn hảo vì bạn sẽ sớm thấy tại sao
- Chỉ định 3 nhà phát triển hoặc 3 nhóm nhà phát triển độc lập cho 3 phần
- Mỗi nhà phát triển sẽ làm việc trên mảnh của họ và kiểm tra mảnh của họ bằng cách sử dụng bản sao cơ sở dữ liệu của họ, trong nhiều tuần hoặc nhiều tháng.
Trong thời gian này, các nhà phát triển sẽ không chạy mã của nhau, cũng không thử sử dụng phiên bản cơ sở dữ liệu đã được tạo bởi mã của người khác. Người viết báo cáo sẽ chỉ cần thêm một loạt các dữ liệu mẫu. Người viết cảnh báo sẽ thêm các bản ghi mô phỏng các sự kiện báo cáo. Và người viết GUI sẽ nhìn vào cơ sở dữ liệu để xem GUI đã thêm gì. Theo thời gian, các nhà phát triển sẽ nhận ra thông số kỹ thuật bị sai theo một cách nào đó, chẳng hạn như không chỉ định chỉ mục hoặc có độ dài trường quá ngắn và "sửa" điều đó trong phiên bản của họ. Họ có thể nói với những người khác, những người có thể hành động, nhưng thường thì những điều này sẽ được đưa vào danh sách sau.
Khi cả ba phần được mã hóa hoàn toàn và được kiểm tra bởi các nhà phát triển của họ và đôi khi thậm chí được kiểm tra bởi người dùng (hiển thị cho họ một báo cáo, màn hình hoặc thông báo email) sẽ đến giai đoạn "tích hợp". Điều này thường được ngân sách ở một vài tháng nhưng vẫn sẽ đi qua. Sự thay đổi độ dài trường theo dev 1 sẽ được phát hiện ở đây và sẽ yêu cầu dev 2 và 3 thực hiện các thay đổi mã lớn và có thể cả UI cũng thay đổi. Chỉ số bổ sung đó sẽ tàn phá chính nó. Và như vậy. Nếu một trong những nhà phát triển được người dùng yêu cầu thêm một trường và đã làm, thì bây giờ sẽ là lúc hai người kia cũng phải thêm nó.
Giai đoạn này rất đau đớn và không thể dự đoán được. Vì vậy, mọi người bắt đầu nói "chúng ta phải hòa nhập thường xuyên hơn." "Chúng tôi phải làm việc cùng nhau ngay từ đầu." "Khi một trong số chúng tôi đưa ra yêu cầu thay đổi [đó là cách chúng tôi đã nói chuyện] thì những người khác phải biết về nó." Một số nhóm bắt đầu thực hiện các bài kiểm tra tích hợp trước đó trong khi tiếp tục làm việc riêng. Và một số đội bắt đầu sử dụng mã của nhau và xuất ra mọi lúc, ngay từ đầu. Và điều đó đã trở thành tích hợp liên tục.
Bạn có thể nghĩ rằng tôi đang phóng đại câu chuyện đầu tiên đó. Tôi đã làm một số công việc cho một công ty một lần khi liên hệ của tôi nhai tôi để kiểm tra một số mã bị lỗi sau:
- một màn hình mà anh ta không làm việc có một nút chưa làm gì cả
- không có người dùng nào đã đăng xuất trên thiết kế màn hình (màu sắc và phông chữ chính xác; sự tồn tại của màn hình, khả năng của nó và những nút nào có trong thông số 300 trang.)
Đó là ý kiến của anh ấy rằng bạn không đặt công cụ vào kiểm soát nguồn cho đến khi nó là XONG. Anh ấy thường làm một hoặc hai lần đăng ký một NĂM. Chúng tôi đã có một chút khác biệt về triết lý :-)
Ngoài ra, nếu bạn cảm thấy khó tin rằng các nhóm sẽ bị ngắt kết nối xung quanh một tài nguyên được chia sẻ như cơ sở dữ liệu, bạn thực sự sẽ không tin (nhưng đó là sự thật) rằng cách tiếp cận tương tự đã được thực hiện để mã hóa. Bạn sẽ viết một chức năng tôi có thể gọi? Thật tuyệt, hãy tiếp tục và làm điều đó, tôi sẽ chỉ mã hóa những gì tôi cần trong lúc này. Nhiều tháng sau tôi sẽ "tích hợp" mã của mình để nó gọi API của bạn và chúng tôi sẽ phát hiện ra nó sẽ nổ tung nếu tôi vượt qua null, tôi sẽ nổ tung nếu nó trả về null (và nó rất nhiều) nó trả về những thứ quá lớn đối với tôi, nó không thể xử lý năm nhuận và hàng ngàn thứ khác. Làm việc độc lập và sau đó có một giai đoạn tích hợp là bình thường. Bây giờ nghe có vẻ điên rồ.
