Giữ trẻ hệ thống tích hợp liên tục của bạn

Một trong những vai trò của tôi trong đội của tôi là người xây dựng . Tôi chịu trách nhiệm duy trì / cập nhật các tập lệnh xây dựng của chúng tôi và đảm bảo rằng chúng tôi đang xây dựng 'trơn tru' trên máy chủ tích hợp liên tục. Tôi thường không bận tâm đến công việc này, mặc dù thường thì tôi cảm thấy như mình liên tục trông nom máy chủ CI.

Công việc này đôi khi có thể gây phiền nhiễu vì nếu bản dựng bị hỏng, tôi phải bỏ câu chuyện tôi đang làm và điều tra lỗi bản dựng. Xây dựng thất bại xảy ra hàng ngày trên nhóm của chúng tôi. Đôi khi, các nhà phát triển chỉ đơn giản là không xây dựng cục bộ trước khi cam kết để các thử nghiệm thất bại trên máy chủ CI. Trong tình huống này, tôi muốn nhanh chóng tìm đến người có 'cam kết xấu' để bản dựng không bị hỏng quá lâu. Đôi khi (rất ít thường xuyên hơn) một điều kiện lạ tồn tại trên máy chủ CI cần được gỡ lỗi.

Tôi biết rằng nhiều nhóm trưởng thành sử dụng Tích hợp liên tục nhưng không có nhiều tài liệu về các thực tiễn tốt.

Các vấn đề của tôi chỉ ra rằng sự tích hợp liên tục của chúng tôi không chín chắn hay đây chỉ đơn giản là một phần của công việc?

Một số thực hành tốt để làm theo là gì? Các đặc điểm của hội nhập liên tục trưởng thành là gì?

Cập nhật

Thay vì trả lời một số ý kiến, tôi sẽ thực hiện cập nhật thay thế. Chúng tôi có một lệnh đơn giản, thực hiện chính xác những gì máy chủ xây dựng sẽ làm khi xây dựng ứng dụng. Nó sẽ biên dịch, chạy tất cả các đơn vị / tích hợp và một số bài kiểm tra dựa trên giao diện người dùng nhanh.

Đọc câu trả lời của mọi người, cảm thấy chúng ta có thể có hai vấn đề lớn.

1. Máy chủ CI không phàn nàn đủ lớn khi quá trình xây dựng thất bại.
2. Các nhà phát triển không cảm thấy trách nhiệm của mọi người là đảm bảo cam kết của họ được thực hiện thành công.

Điều khiến mọi thứ trở nên khó khăn hơn trong nhóm của tôi là chúng tôi có một nhóm lớn (hơn 10 nhà phát triển) VÀ chúng tôi có một vài thành viên trong nhóm ngoài khơi cam kết khi chúng tôi thậm chí không làm việc. Bởi vì nhóm lớn và chúng tôi thiết lập rằng các cam kết nhỏ thường xuyên được ưa thích, đôi khi chúng tôi thực sự có rất nhiều hoạt động trong một ngày.

Đầu tiên và quan trọng nhất: mỗi người chịu trách nhiệm cho quá trình xây dựng . Nghe có vẻ như các thành viên trong nhóm của bạn chưa trưởng thành ... Không ai có thể viết mã và bỏ qua máy chủ CI với hy vọng rằng nó hoạt động. Trước khi cam kết mã, nó cần được kiểm tra trên máy cục bộ của họ. Bạn nên chắc chắn rằng mã bạn đang kiểm tra sẽ không phá vỡ bản dựng. Tất nhiên, có những trường hợp khi bản dựng bị phá vỡ ngoài ý muốn (ví dụ: nếu một tệp cấu hình đã bị thay đổi hoặc cam kết cẩu thả đã vô tình được thực hiện).

Hầu hết các máy chủ CI (tôi chỉ sử dụng Hudson) sẽ gửi email tự động nêu chi tiết các cam kết khiến việc xây dựng bị phá vỡ. Phần duy nhất trong vai trò của bạn là đứng đằng sau họ trông cứng rắn cho đến khi nghi phạm sửa chữa bất cứ điều gì họ phá vỡ.

Nhóm của bạn có một điều sai:

Chịu trách nhiệm về máy chủ xây dựng không giống như chịu trách nhiệm cho việc xây dựng .

Người kiểm tra mã có trách nhiệm làm cho nó "hoạt động" (đối với một số giá trị của công việc). Lý do duy nhất để có một máy chủ xây dựng là để bắt quá mức trong quá trình này. Bất kỳ máy chủ xây dựng nào có giá trị muối đều có thể thông báo cho người đã kiểm tra mã kể từ lần xây dựng cuối cùng (cũng như bất kỳ ai khác quan tâm) với thông tin sau:

• Xây dựng bị phá vỡ!
• Điều gì đã sai khi xây dựng!
• Điều gì đã thay đổi kể từ lần xây dựng cuối cùng!

Điều này rất thường xuyên xảy ra qua email. Điều quan trọng là điều này xảy ra khá nhanh sau mỗi lần đăng ký.

Sau đó, người đó có thể thấy những gì đã sai và sửa nó, và máy chủ bản dựng sau đó thông báo cho bất kỳ ai quan tâm rằng bản dựng đã trở lại bình thường. Điều này sẽ tự xảy ra mà không có sự tham gia của người khác mà là thủ phạm đăng ký.

Vì vậy, để trả lời câu hỏi của bạn: Một môi trường CI trưởng thành KHÔNG yêu cầu sự tham gia của người gác cổng trong hoạt động bình thường của nó.

Ngoài ra, nếu "điều kiện lạ tồn tại" xảy ra rất thường xuyên thì hãy tìm hiểu nguyên nhân gây ra nó và làm cho hệ thống mạnh mẽ hơn.

Thay đổi quy trình. Nếu một cam kết phá vỡ bản dựng, hãy tự động khôi phục lại cam kết đó và thông báo cho nhà phát triển đã phá vỡ bản dựng đó. Thật ngớ ngẩn khi cho phép một thành viên trong nhóm làm chậm một phần còn lại của đội. Hoặc thay vì có các bản dựng tích hợp được thực hiện tự động, hãy nhờ các nhà phát triển kiểm tra máy tích hợp và nếu bản dựng thành công, thì họ có thể cam kết. Tích hợp liên tục không có nghĩa là "kiểm tra bất cứ thứ gì bạn thích và ai đó sẽ sửa nó cho bạn".

Chiến lược "nhánh vàng" không hoạt động trừ khi có người gác cổng cho nhánh vàng.

Một DVCS như Git có thể giúp đỡ; thay vì cam kết, nhà phát triển chỉ có thể gửi một bộ thay đổi để tích hợp vào máy chủ CI và sau đó máy chủ có thể cố gắng tích hợp bộ thay đổi. Nếu tích hợp thành công, bộ thay đổi sẽ được hợp nhất và nếu không, nó sẽ bị từ chối.

Một vấn đề tôi thường thấy là các nhà phát triển không thể thực hiện một bản dựng cục bộ có các bước chính xác giống như bản dựng CI. Nghĩa là, máy chủ CI được cấu hình để bao gồm các bước bổ sung như kiểm tra đơn vị / tích hợp, phạm vi bảo hiểm, v.v. không thể thực hiện cục bộ. Chắc chắn, các nhà phát triển sẽ bị cắn bởi một trong những bước mà họ không thể thực hiện tại địa phương và sẽ bắt đầu đặt câu hỏi tại sao họ lại bận tâm xây dựng một bản phát hành tại địa phương trước khi đăng ký.

Tôi giữ toàn bộ bản dựng của mình và máy chủ CI chỉ cần khởi động bản dựng phát hành mà không có cấu hình / bước không xác định. Các nhà phát triển có thể chạy một phiên bản build tại địa phương trước khi check-in bao gồm tất cả các bước sẽ được thực hiện bởi các CI xây dựng và được xa tự tin hơn rằng không có gì sẽ phá vỡ khi họ làm check-in.

Các lợi ích bổ sung cho phương pháp này bao gồm:

• thật dễ dàng để chuyển đổi giữa các máy chủ CI vì bạn chưa đầu tư nhiều thời gian để định cấu hình các bước không liên quan
• tất cả các công cụ thời gian xây dựng đều nằm dưới sự kiểm soát nguồn, có nghĩa là tất cả các nhà phát triển đang sử dụng chính xác cùng một bộ công cụ để xây dựng hệ thống của bạn
• ngoài điểm trên, thật đơn giản để thay đổi công cụ xây dựng theo cách được kiểm soát

Tái bút toàn bộ khái niệm người giữ trẻ xây dựng là vô lý, nhưng những người khác đã bao gồm điều đó.

Trước hết, các nhà phát triển không nên phá vỡ các bản dựng thường xuyên - họ nên xây dựng và chạy thử nghiệm cục bộ trước khi họ cam kết với chi nhánh CI. Nó nên là một dấu hiệu xấu hổ để phá vỡ công trình, và điều quan trọng là phải thực thi điều đó. Tôi đã thực hiện điều đó thông qua việc đăng số liệu thống kê và tôi đã thấy các đội khác có "túi xây dựng" nơi bạn đặt một đô la mỗi khi bạn phá vỡ công trình. Vào cuối dự án, tiền đi về phía bia.

Nếu sự xấu hổ / niềm tự hào cá nhân không hoạt động, bạn có thể phải chuyển sang những thứ nặng hơn (ví dụ như đe dọa chấm dứt). Phá vỡ công trình trước khi rời đi trong ngày nên là một hành vi phạm tội lớn. Và mọi nhà phát triển nên có một thông báo trạng thái xây dựng trên máy tính để bàn của họ. Phần tốt nhất của tất cả điều này là nó khuyến khích các cam kết nhỏ hơn, dù sao cũng được ưu tiên.

Điều đó nói rằng, việc xây dựng đôi khi sẽ phá vỡ (ví dụ lý do cấu hình CI). Và đôi khi mọi người sẽ làm hỏng việc và rời đi trong ngày với việc xây dựng bị phá vỡ. Đó là lý do tại sao bạn nên nhắm đến một quy trình cho phép quay ngược nhanh chóng và dễ dàng với các phiên bản tốt đã biết. Nếu bạn luôn có thể quay lại bản dựng tốt cuối cùng (và để phiên bản quay lại được triển khai đến tất cả các vị trí cần thiết), thì trong trường hợp xấu nhất là bản dựng bị hỏng trong đó thủ phạm đã rời đi vào buổi tối, bạn có thể lăn trở lại phiên bản tốt cuối cùng và la mắng anh ấy / cô ấy vào buổi sáng.

Tôi không thể giới thiệu cuốn sách Giao hàng liên tục đủ. Nếu bạn đang tìm kiếm một hướng dẫn về cách trưởng thành quy trình CI của bạn, hãy thử xem.

Tôi đã nghe nói về một điều mà Microsoft (có thể?) Làm, đó là có vai trò xây dựng người giữ trẻ di chuyển xung quanh đội. Cách họ làm điều này là khi ai đó phá vỡ bản dựng (có thể bao gồm cả việc kiểm tra thứ gì đó không thử nghiệm), họ sẽ đảm nhận vai trò này. Điều này khiến mọi người chịu trách nhiệm về hậu quả của hành động của họ một cách rất trực tiếp. Và cho rằng đó là một công việc hơi khó chịu để làm, nó khuyến khích họ không phá vỡ công trình một lần nữa.

Người hiện đang chịu trách nhiệm xây dựng có thể có một chiếc mũ đặc biệt. Có thể có một buổi lễ để bàn giao nó.

Lưu ý rằng như Thorbjørn nói, chịu trách nhiệm cho việc xây dựng không giống như chịu trách nhiệm cho máy chủ xây dựng. Trách nhiệm đối với máy chủ có thể thuộc về vĩnh viễn với một hoặc nhiều thành viên nghiêng về cơ sở hạ tầng trong khi trách nhiệm đối với việc xây dựng di chuyển xung quanh.

Bây giờ, chi tiết về quá trình sang một bên, tôi sẽ tham gia điệp khúc của những người bày tỏ sự mất tinh thần tại các nhà phát triển đăng ký mà không phải chạy một bản dựng và thử nghiệm. Không thể chấp nhận được!

Nếu bạn có một số thành viên của nhóm có khả năng phá vỡ bản dựng (và dựa trên kinh nghiệm của riêng tôi, tôi chủ yếu nghĩ đến các thành viên ở một quốc gia khác) và nếu bạn đang sử dụng một số điều khiển nguồn hiện đại tốt đẹp như Mercurial hoặc Git, bạn có thể yêu cầu họ đăng ký vào một nhánh khác với các thành viên khác trong nhóm, chạy một quy trình CI riêng trên đó và tự động hợp nhất các thay đổi từ nhánh đó vào trung kế sau khi xây dựng thành công (lưu ý rằng bạn phải chạy bản dựng thứ hai và kiểm tra sau khi hợp nhất trước khi kiểm tra hợp nhất trong!). Vì việc hợp nhất tự động không phải lúc nào cũng thành công, điều này cuối cùng sẽ khiến chi nhánh cần sự chú ý thủ công, tuy nhiên, đây có thể là một nỗi đau thực sự. Mặc dù vậy, có thể ít đau đớn hơn so với việc kiểm tra mã bị hỏng trong phần còn lại của đội.

Như Jonathan Khoo đã nói, tất cả các bạn phải chịu trách nhiệm về máy chủ xây dựng và tập lệnh xây dựng. Có ba lý do:

1. Tại thời điểm bạn gặp trường hợp "Xe buýt 1", điều đó có nghĩa là nếu bạn bị xe buýt chạy thì toàn bộ kiến ​​thức về máy chủ xây dựng và tập lệnh xây dựng sẽ bị mất.
2. Các tập lệnh đã được viết (đúng hoặc sai) bởi bạn chỉ có đầu vào của bạn. Cũng giống như bất kỳ mã nào, càng có nhiều người tham gia thì cơ sở tri thức có thể được áp dụng cho nó càng rộng.
3. Cuối cùng khi có sự cố xảy ra chỉ có bạn đang cảm thấy đau. Đau là một điều tốt nhưng không phải khi nó bị cô lập. Hiện tại bạn đang đối phó với cơn đau nhưng nếu những người khác bị đau thì bạn sẽ thấy họ cuối cùng sẽ nghiêm ngặt hơn trong việc kiểm tra mã trước khi cam kết.

Bản thân tôi rất quan tâm đến CI và rơi vào cái bẫy là người duy trì các kịch bản nhưng đây là một vài điều bạn có thể làm để giảm thiểu điều đó.

1. Xây dựng tập lệnh không chỉ chạy trên các máy chủ CI mà còn trên các máy phát triển cục bộ. Họ nên tạo ra cùng một kết quả đầu ra, chạy các thử nghiệm giống nhau và thất bại vì những lý do tương tự. Điều này cho phép các nhà phát triển chạy tập lệnh trước khi cam kết mã của họ.
2. Nếu bất kỳ ai phá vỡ bản dựng, hãy công khai thông qua việc sử dụng cửa sổ bật lên trên khay tác vụ, email, đèn nhấp nháy, tiếng ồn, v.v. Nó không chỉ gây khó chịu cho các thành viên trong nhóm mà còn tạo cơ hội cho mọi người khác trong nhóm nhảy lên và hỗ trợ.
3. Trong một thời gian tránh sửa chữa bản dựng. Hãy nhờ người khác làm điều đó. Nếu không có ai khác nhảy lên chờ đợi những điều tồi tệ xảy ra và sử dụng nó như một điểm học tập cho cả nhóm để hiểu tại sao máy chủ CI lại quan trọng.
4. Hãy thử và giữ cho máy chủ xây dựng và máy phát triển của bạn không có các thành phần bên thứ ba được cài đặt càng nhiều càng tốt, đặc biệt là giữ GAC sạch. Dựa vào các thành phần của bên thứ ba trong thư mục thư viện dự án. Điều này giúp xác định các thành phần bị thiếu nhanh hơn.

Tầm nhìn sẽ giúp bạn ra ngoài. Tất cả các thành viên trong nhóm cần biết rằng có một vấn đề đang hoạt động mà họ nên khắc phục. Thông báo email rất hữu ích, nhưng nếu nhà phát triển bận rộn và không phản ứng với nó ngay lập tức, anh ta có thể sẽ quên nó và email sẽ kết thúc trong một đống thông báo khổng lồ.

Bạn có thể thử sử dụng các công cụ như Catlight hoặc BuildNotify . Chúng hiển thị trạng thái hiện tại của các bản dựng quan trọng trong khu vực khay. Mỗi khi nhà phát triển nhìn vào đồng hồ, anh ta sẽ thấy rằng có một bản dựng bị hỏng cần được sửa chữa.

Catlight cũng sẽ cho thấy ai đã phá vỡ công trình trước, gây áp lực xã hội cho người này, vì toàn đội sẽ thấy điều đó trên mỗi lần xây dựng thất bại liên tiếp.

Một chiến lược là sử dụng nhiều chi nhánh nhỏ cho nhiều dự án nhỏ. Sau đó, khi ai đó phá vỡ bản dựng, họ chỉ phá vỡ bản dựng. Vì vậy, họ nhận được email khó chịu từ máy chủ xây dựng và họ phải lo lắng về điều đó.

Một cách khác là nâng cao trách nhiệm của mọi người. Ví dụ: nếu bạn sử dụng một cái gì đó như Rietveld thì mọi người không thể cam kết mà không vượt qua đánh giá ngang hàng. (Quá trình trong thực tế có trọng lượng nhẹ hơn nhiều so với bạn nghĩ. Nhưng nó buộc mọi người phải "đường ống" và làm việc trên nhiều thứ cùng một lúc.) Bảo tồn công trình là trách nhiệm của cả người đi làm và người đánh giá. Nếu bất cứ ai thường xuyên phá vỡ bản dựng hoặc phê duyệt những thứ phá vỡ bản dựng, thì đừng để họ đưa ra phê duyệt cuối cùng cho các cam kết. Kết hợp với quy trình mà bất kỳ ai cũng có thể dễ dàng khôi phục mọi thay đổi và bản dựng sẽ không bị hỏng như thường lệ và sẽ không bị hỏng khi thay đổi được thực hiện.

Tôi sẽ phá vỡ điệp khúc ở đây và nói rằng thực ra, việc phá vỡ bản dựng đôi khi không phải là một điều tồi tệ, vì nó cho thấy rằng công việc thực tế đang được thực hiện. Có, các nhà phát triển nên xây dựng và kiểm tra trước khi họ cam kết, nhưng gánh nặng chính của kiểm thử phải do các công cụ tự động hóa phát triển, bao gồm cả máy chủ tích hợp liên tục. Các công cụ này sẽ được sử dụng, và trừ khi việc xây dựng bị phá vỡ hết lần này đến lần khác, thì không rõ là bạn đang cố gắng hết sức có thể. Tuy nhiên, tôi nghĩ rằng việc xây dựng sẽ không bao giờ bị phá vỡ trong bất kỳ khoảng thời gian đáng kể nào, và thậm chí sẽ ủng hộ việc quay vòng tự động hoặc quy trình cam kết nhiều giai đoạn nếu điều đó giúp hỗ trợ các mục tiêu phản hồi nhanh từ các cơ sở thử nghiệm tự động tập trung, cộng với một thân cây "xanh".

Những điều vợ chồng cần lưu ý:

1. Nhóm của bạn cần một bộ tiêu chuẩn để tuân theo
2. Bạn cần có được sự quản lý trên tàu với ý tưởng về mã sạch và cố gắng cải thiện các thực hành mã.
3. Kiểm tra thử nghiệm thử nghiệm! Luôn luôn kiểm tra trước khi bạn đăng ký.
4. Mặc dù tôi đồng ý rằng việc phá vỡ bản dựng là ổn, nhưng đó là một dịp hiếm hoi và ý tôi là cực kỳ hiếm có thể chấp nhận được. Nếu điều này là hàng ngày, tôi sẽ tìm kiếm cánh cửa hoặc nói chuyện với sếp của tôi về các tiêu chuẩn.

Nhìn chung, các bạn cần phải thiết lập, viết ra các tiêu chuẩn dựa trên các thực tiễn tốt nhất và không phải là các thực tiễn của riêng bạn (rõ ràng là các cách này không hiệu quả). Khi mọi người đồng ý về các tiêu chuẩn, bắt đầu quy trình xem xét mã và thực thi các tiêu chuẩn. Có vẻ như quản lý đã đi nghỉ và không bao giờ quay trở lại. Đây là những điều mà thực sự là khá cơ bản cho bất kỳ cửa hàng. nền tảng của mã tốt bắt đầu với các tiêu chuẩn tốt để ra lệnh cho mã đội và cách viết. Chỉ là suy nghĩ của tôi. Gần đây tôi đã bước vào một tình huống tương tự tại công việc mới của tôi và tôi đã nói chuyện với sếp của tôi. Giải thích cho anh ta, chúng ta cần XYZ hoàn thành vì nó ảnh hưởng đến ABC. Hai tuần sau tôi đã viết một danh sách các tiêu chuẩn mã để theo dõi và trình bày nó. Tiếp theo là các đồng nghiệp của tôi đưa ra đầu vào và khoảng 2 tháng sau chúng tôi đã có các tiêu chuẩn để giải quyết hàng tấn vấn đề.