CruiseControl thực sự làm gì? tôi không thể hiểu nó Tôi dùng nó để làm gì? ai đó nói với tôi rằng nó theo dõi ngày xây dựng của bạn và nếu đó là thành công hay lỗi nhưng thực sự tại sao tôi cần điều đó? Tôi sẽ cho rằng nó có thể gửi email cho bạn nếu có lỗi xây dựng nhưng ngoài đó (giả sử nó dài và tôi thực hiện các bản dựng hàng đêm hoặc buổi tối) thì tôi có thể sử dụng nó để làm gì không? là người có sở thích hoặc trong một dự án nhỏ với & lt; = 5 ppl?
Câu trả lời:
Những lợi thế của các hệ thống xây dựng liên tục thường được áp dụng cho các dự án đa nhà phát triển, nhưng chúng có một số lợi thế cho các nhóm nhỏ hơn hoặc các nhà phát triển duy nhất.
Trước tiên hãy xem xét trường hợp sử dụng điển hình: Một dự án lớn với rất nhiều ủy viên. Có thể đôi khi, bản dựng sẽ bị hỏng. Có thể môi trường cục bộ của ai đó không khớp với máy chủ và họ cam kết mã chỉ biên dịch trên máy của họ hoặc ai đó không kiểm tra mã biên dịch của họ vì họ đang vội hoặc thanh toán của ai đó không cập nhật chỉnh sửa và cam kết.
Dù bằng cách nào, bản dựng bây giờ đã bị hỏng. Lỗi cần phải được sửa, nhưng có thể không rõ ai thực sự gây ra nó và thời gian là điều cốt yếu! Khi mọi người cập nhật lên đầu, họ sẽ không còn mã biên dịch, khiến họ khó thực hiện công việc hơn.
Theo dõi trạng thái của bản dựng có thể giúp tránh nhiều sự kiện này xảy ra. Ngay khi mã vi phạm đi vào repo, bản dựng sẽ thất bại, nhưng họ sẽ biết ngay lập tức để mọi người không kiểm tra nó. Vì nó là cái đầu hiện tại, nó dễ dàng trở lại hơn. Ngay cả khi mọi người kết thúc với mã đó, ít nhất họ cũng biết ai gây ra nó và cam kết đó là gì.
Thậm chí có thể (tùy thuộc vào tốc độ của quá trình xây dựng) có thể có kiểm tra bản dựng dưới dạng hook pre-commit, ngăn chặn mã xấu từng xâm nhập vào cơ sở mã trung tâm ở vị trí đầu tiên.
Vì vậy, những gì nó cung cấp cho các nhóm nhỏ hơn hoặc các nhà phát triển đơn độc?
Chà, vẫn có thể hữu ích để biết liệu bản dựng có bị hỏng hay không, tùy thuộc vào cách thực hành công việc của bạn như thế nào với mã viết và kiểm tra. Trong các nhóm nhỏ, nếu có sự tách biệt về địa lý nói riêng, tôi có thể thấy nó hữu ích khi biết bản dựng bị hỏng và ai đã phá vỡ nó khi nào và cái gì.
Có những thứ khác bạn có thể sử dụng nó cho. Nếu bạn đã thiết lập nó, thì bạn có một máy chủ luôn có một bản sao của bản dựng mới nhất trên đó. Nếu máy chủ phải đối mặt với web, giờ đây bạn có một cách dễ dàng để mọi người dùng thử phiên bản mới nhất của phần mềm của bạn (ví dụ: áo ngủ Firefox và những thứ tương tự). Những người bên ngoài dự án của bạn cũng có thể quan tâm đến việc liệu mã có được xây dựng trên nền tảng của họ hay không, nếu nó vượt qua các thử nghiệm cụ thể.
Cuối cùng, hãy xem Bảng điều khiển CI cho Chromium cho một ý tưởng về loại thông tin bạn có thể nhận được. Chúng ta có thể thấy trạng thái xây dựng trên mỗi nền tảng, các cam kết và tác động của chúng đối với điều đó, thống kê bảo hiểm mã, tải xuống các bản dựng mới nhất và đối với bản dựng không thành công, chúng ta có thể xem thử nghiệm nào thất bại và thông báo lỗi là gì. Tuyệt đấy!
Trường hợp sử dụng thông thường cho CruiseControl (và các Hệ thống [CI] Continous Build khác như Hudson, Anthill, ...) là thường xuyên kiểm tra hệ thống quản lý mã nguồn trung tâm (SCM) (mỗi phút?) Hoặc được repo thông báo nếu có là những thay đổi. CI sau đó nên xây dựng mã.
Ngoài ra, có thể chạy thử nghiệm, triển khai các tạo phẩm (ví dụ: repo maven hoặc máy chủ demo) trên mỗi bản dựng. Bạn có thể có nhiều bản dựng, ví dụ một bản dựng sẽ được kích hoạt bởi mỗi thay đổi trong SCM của bạn và một bản sẽ được kích hoạt mỗi đêm vào giờ nghỉ trưa. Bản dựng CI "thực" sẽ chỉ biên dịch mã và chạy thử nghiệm đơn vị trong khi bản dựng "lớn" có thể chạy thử nghiệm tích hợp và các tác vụ khác mất nhiều thời gian.
IMHO một lợi ích của hệ thống CI là có ít nhất một môi trường xây dựng khác với các máy phát triển. Ví dụ, môi trường có thể được sửa đổi để bắt chước môi trường của khách hàng của bạn. Một tính năng hay khác là thông báo về các lỗi xây dựng NHƯ VẬY. Bằng cách đó, sẽ dễ dàng hơn để tìm ra khi nào các bản dựng bị hỏng và cách khắc phục.
Bạn cũng có thể định cấu hình các bản dựng trên máy CI sẽ được chạy thủ công để tự động hóa quy trình giới thiệu (nếu ứng dụng và khách hàng của bạn cho phép điều này). Hoặc có một bản dựng tạo ra một tệp thực thi cho những người không phải là nhà phát triển, những người cần tạo các phiên bản chụp nhanh của ứng dụng của bạn để kiểm tra chúng.
Một hệ thống CI khá linh hoạt và là một điều tốt để có nó ngay cả trong các nhóm nhỏ. Một người có sở thích có thể không cần một công cụ như vậy, nhưng nếu có ít nhất 2 nhà phát triển tham gia thì đó là một điều tốt để có CI!