Chính sách sửa lỗi hàng đêm bị hỏng

Question

Tôi đoán mọi người đồng ý rằng việc xây dựng liên tục và tích hợp liên tục có lợi cho chất lượng của sản phẩm phần mềm. Lỗi được tìm thấy sớm để chúng có thể được khắc phục ASAP. Đối với các bản dựng liên tục, mất vài phút, thường dễ dàng tìm ra người gây ra lỗi. Tuy nhiên, đối với các thử nghiệm tích hợp hàng đêm, mất nhiều thời gian để chạy, đây có thể là một thách thức. Dưới đây là các chi tiết cụ thể về tình huống, mà tôi đang tìm một giải pháp tối ưu:

• Chạy thử nghiệm tích hợp mất hơn 1 giờ. Do đó chúng được chạy qua đêm. Nhiều lần đăng ký diễn ra hàng ngày (nhóm khoảng 15 nhà phát triển) nên đôi khi rất khó tìm ra "thủ phạm" (nếu có).
• Môi trường thử nghiệm tích hợp phụ thuộc vào các môi trường khác (dịch vụ web và cơ sở dữ liệu), đôi khi có thể không thành công. Điều này làm cho các thử nghiệm tích hợp thất bại.

Vậy cách tổ chức nhóm để những lỗi này được khắc phục sớm? Theo ý kiến ​​của tôi, cần có người được chỉ định để DIAGNOSE (các) khiếm khuyết. Đây sẽ là nhiệm vụ đầu tiên vào buổi sáng. Nếu anh ta cần chuyên môn của người khác, họ nên sẵn sàng. Khi nguồn (thành phần, cơ sở dữ liệu, dịch vụ web) của lỗi được xác định, chủ sở hữu nên bắt đầu sửa chữa nó (hoặc một nhóm khác sẽ được thông báo).

Làm cách nào để chỉ định người chẩn đoán lỗi? Lý tưởng nhất, một người nào đó sẽ tình nguyện (ha ha). Điều này sẽ không xảy ra thường xuyên, tôi sợ. Tôi đã nghe tùy chọn khác - bất cứ ai đến trước văn phòng nên kiểm tra kết quả của các bản dựng hàng đêm. Điều này là OK, nếu cả nhóm đồng ý. Tuy nhiên, điều này phần thưởng cho những người đến trễ. Tôi cho rằng vai trò này nên luân phiên trong đội. Lý do "Tôi không biết nhiều về xây dựng" không nên được chấp nhận. Chẩn đoán nguồn gốc của sự thất bại nên khá đơn giản. Nếu không, sau đó thêm nhiều ghi nhật ký chẩn đoán vào mã sẽ cải thiện khả năng hiển thị thành lỗi kiểm tra tích hợp.

Bất kỳ trải nghiệm nào trong lĩnh vực này hoặc đề xuất cải thiện phương pháp trên?

Answer 1

Tôi thường làm (Tôi đã thực hiện nó cho một nhóm từ 8 đến 10 người) là hai người có một người kiểm tra công trình xây dựng, như điều đầu tiên anh làm vào buổi sáng - một số sẽ nói anh ta chịu trách nhiệm về QA, tôi cho là vậy.

Nếu có sự cố, anh ấy chịu trách nhiệm tìm hiểu xem/làm thế nào - tất nhiên, anh ấy có thể yêu cầu trợ giúp từ các thành viên khác trong nhóm, nếu cần. Điều này có nghĩa là có ít nhất một thành viên của nhóm phải có kiến ​​thức tuyệt vời về toàn bộ ứng dụng - nhưng đó không phải là điều xấu: nó sẽ giúp chẩn đoán các vấn đề trong ngày ứng dụng được sử dụng trong sản xuất và bị thất bại.

Và thay vì có người làm điều đó, tôi thích khi có hai: một cho một tuần, người kia cho tuần thứ hai - ví dụ; theo cách này, có nhiều cơ hội luôn luôn có người có thể chẩn đoán vấn đề, ngay cả khi một người trong số họ đang trong kỳ nghỉ.

Là một sidenote: càng hữu ích điều bạn đăng nhập trong thời gian xây dựng, càng dễ dàng để tìm hiểu những gì đã xảy ra - và tại sao.

Tại sao không để mọi người trong nhóm kiểm tra bản dựng mỗi sáng?

• Vâng, không phải mọi ai muốn, trước hết - và điều đó sẽ được thực hiện tốt hơn nếu một trong những làm nó thích những gì anh ấy làm
• Và bạn không muốn 10 người dành nửa giờ mỗi vào ngày đó ^^

Answer 2

Trong trường hợp của bạn, tôi muốn đề nghị người phụ trách CM. Nếu đó là người quản lý hoặc người lãnh đạo kỹ thuật có quá nhiều trách nhiệm thì tại sao không đưa nó cho một nhà phát triển cơ sở? Tôi ước một người nào đó đã ép tôi sớm trong sự nghiệp của mình để tìm hiểu kỹ hơn về kiểm soát nguồn. Không chỉ vậy, nhưng nhìn vào mã của người khác để theo dõi một nguồn lỗi là một kỹ năng thực sự xây dựng hoặc tập thể dục học tập. Họ nói rằng bạn thu được nhiều nhất từ ​​việc xem xét mã của người khác và tôi là một người tin tưởng mạnh mẽ về điều này.

Answer 3

Một chính sách nổi tiếng về các bản dựng hàng đêm bị hỏng, được gán cho Microsoft, là người có cam kết phá vỡ bản dựng sẽ chịu trách nhiệm duy trì các bản dựng hàng đêm cho đến khi người khác phá vỡ nó.

Điều đó làm cho ý nghĩa, vì

• tất cả mọi người làm cho sai lầm, vì vậy vòng quay cần thiết sẽ xảy ra (trao quyền với Gần đây-Sử dụng ít nhất-mẫu lựa chọn đối với trường hợp nhập nhằng)
• nó khuyến khích mọi người viết mã tốt hơn

Answer 4

tôi bị cám dỗ để đề xuất những điều tách lên bằng một trong hai cách:

• Phân chia thời gian - Giả sử rằng các thử nghiệm có thể chạy hai lần một đêm, tại sao không chạy thử nghiệm đối với mã tại 2 thời điểm khác nhau, tức là. tất cả các lần đăng ký tối đa X giờ sáng và sau đó phần còn lại, để có thể giúp thu hẹp vị trí của vấn đề.

• Chia nhóm - Mã có thể được chia thành các phần nhỏ hơn để các bài kiểm tra có thể chạy trên các máy khác nhau để giúp thu hẹp nhóm nào sẽ đào sâu vào mọi thứ?

Giả định bạn có thể chạy thử nghiệm nhiều lần và phân chia mọi thứ theo cách như vậy, đó là ý tưởng thô.

Answer 5

Pair kinh nghiệm với từng trải

Bạn có thể muốn xem xét việc có cặp các nhà phát triển chẩn đoán gãy xây dựng. Tôi đã may mắn với điều đó. Đặc biệt là nếu bạn ghép đôi các thành viên trong nhóm, những người có chút quen thuộc với hệ thống xây dựng và các thành viên trong nhóm có sự quen thuộc đáng kể. Điều này có thể làm giảm khả năng của các thành viên trong nhóm nói rằng "Tôi không biết nhiều về xây dựng" như một cách để thử và nhận ra nhiệm vụ, và nó sẽ làm giảm bus number của bạn và tăng collective ownership.

Đưa vào tình trạng lựa chọn giải pháp giao của bạn hoặc một của riêng mình làm

Bạn có thể đưa vấn đề này vào nhóm của bạn và yêu cầu họ cung cấp một giải pháp. Nói với họ rằng nếu họ không đưa ra giải pháp khả thi, bạn sẽ lập lịch biểu hàng tuần, chỉ định một cặp mỗi ngày và đảm bảo mọi người đều có cơ hội tham gia.

Answer 6

• Thực hành tích hợp liên tục, do đó bạn không cần phải thường xuyên mega-xây dựng ** bạn có thể phân phối được xây dựng giữa các máy nếu nó quá chậm đối với một máy tính để làm
• Sử dụng một màn hình xây dựng trạng thái để hầu cho hễ ai kiểm tra một cái gì đó trong có thể được thực hiện chịu trách nhiệm về thất bại xây dựng.
• Có một buổi chiều thời hạn check-in

Hoặc:

• Không ai kiểm tra-in sau 5 giờ chiều

hoặc

• Không ai kiểm tra-in sau 5 giờ chiều trừ khi họ chuẩn bị ở lại t làm việc cho đến khi xây dựng của họ đi như màu xanh lá cây - ngay cả khi đó có nghĩa là làm việc trên, cam kết một sửa chữa và chờ đợi cho một xây dựng lại.

Thực hiện dễ dàng hơn và tuân thủ biểu mẫu đầu tiên, vì vậy đó là những gì tôi muốn làm theo.

Thành viên của một nhóm trước đây của tôi thực sự đã được gọi điện thoại và yêu cầu trở lại làm việc để sửa chữa bản dựng ... và họ đã làm.

Answer 7

Chúng tôi có một cuộc họp đứng lên mỗi sáng, trước khi bắt đầu công việc. Một trong những điều trên danh sách kiểm tra là trạng thái của bản dựng hàng đêm. Hệ thống xây dựng của chúng tôi phun ra một email sau khi nó chạy, báo cáo trạng thái, vì vậy điều này rất dễ tìm - vì nó xảy ra, nó đi đến một người, nhưng thực sự nó nên đi đến tất cả mọi người, hoặc được đăng lên wiki dự án.

Nếu bản xây dựng bị hỏng, sau đó sửa nó trở thành nhiệm vụ ưu tiên hàng đầu, được xử lý giống như bất kỳ tác vụ nào khác, có nghĩa là chúng tôi sẽ quyết định tại vị trí sẽ làm việc trên đó. và làm như vậy. Chúng tôi lập trình ghép đôi và thường sẽ coi đây là tác vụ ghép đôi. Nếu chúng tôi có nhân sự ngắn, chúng tôi có thể chỉ định một người để điều tra sự cố, và sau đó ghép nối một người nào đó với anh ấy để sửa lỗi sau này.

Chúng tôi không có một cơ chế chính thức để giao nhiệm vụ: chúng tôi là một nhóm nhỏ (sáu người, thường) và có quyền sở hữu tập thể, vì vậy chúng tôi chỉ làm việc giữa chúng tôi. Nếu chúng tôi nghĩ rằng kiểm tra của một cặp cụ thể đã phá vỡ bản dựng, thường thì họ sẽ sửa chữa nó. Nếu không, nó có thể là bất cứ ai; nó thường được quyết định bằng cách nhìn thấy những người không phải là hiện đang ở giữa một số nhiệm vụ khác.