Là scrum và một sự phát triển ổn định xây dựng một mâu thuẫn?

Tôi là thành viên của một nhóm phát triển với 5 nhóm, tổng cộng có khoảng 40 nhà phát triển. Chúng tôi đang theo phương pháp Scrum, với nước rút 3 tuần. Chúng tôi có một thiết lập tích hợp liên tục (Jenkins), với một đường ống xây dựng mất vài giờ (do các thử nghiệm tự động mở rộng). Về cơ bản, quá trình phát triển hoạt động tốt.

Tuy nhiên, chúng tôi quan sát thấy rằng sau một vài ngày vào giai đoạn nước rút mới, bản dựng của chúng tôi thường trở nên không ổn định và vẫn bị rung lắc cho đến khi "chấm dứt" chạy nước rút. Tác động bất lợi của việc này là các bước xây dựng ở xa đường ống, đặc biệt là UI- / Webtests không thực thi trong vài ngày (vì chỉ được kích hoạt trên bản dựng 'xanh'). Do đó, các lỗi mới được giới thiệu thường chỉ được phát hiện rất muộn trong giai đoạn nước rút.

• Mỗi cam kết được xác minh đối với một bộ thử nghiệm cơ bản. Sau khi được xác minh, thay đổi được đẩy thành chủ sau khi xem xét mã (Gerrit)
• Kiểm tra đơn vị cơ bản chạy cứ sau 30 phút, thời lượng dưới 10 phút
• Kiểm tra tích hợp chạy cứ sau 2h, thời gian 1h
• UI- / Webtests chạy trên các bài kiểm tra tích hợp thành công, thời lượng vài giờ

Tùy thuộc vào người chịu trách nhiệm cho sự ổn định của công trình trong giai đoạn nước rút (trách nhiệm đó được chuyển qua mỗi lần chạy nước rút), có thể có các "điểm dừng cam kết" trung gian để đưa công trình trở lại ổn định.

Vì vậy, chúng tôi muốn:

1. Các nhóm phát triển của chúng tôi để phát triển và cam kết thay đổi trong giai đoạn nước rút không bị cản trở
2. Quá trình xây dựng của chúng tôi phải từ bỏ nếu một bước xây dựng thất bại, vì các kết quả xây dựng tiếp theo có rất ít ý nghĩa
3. Quá trình xây dựng của chúng tôi để cung cấp cho các nhà phát triển phản hồi chất lượng một cách kịp thời

Cho (2), các điểm (1) và (3) dường như mâu thuẫn với nhau. Có ai có một thực hành tốt làm thế nào để đối phó với điều này?

( Chúng tôi hiện đang nới lỏng điểm (2) và đang cho phép tiếp tục xây dựng ngay cả trên các bước xây dựng không thành công. Tôi không có bất kỳ phản hồi nào về việc điều đó ảnh hưởng đến chất lượng của chúng tôi như thế nào )

Cảm ơn, Simon

Trước tiên, một vài nguyên tắc cơ bản: - Các thay đổi chính phải luôn nằm trên một nhánh tính năng trong VCS của bạn - Các nhánh tính năng phải vượt qua tất cả các thử nghiệm trước khi hợp nhất vào thân cây. Đã thêm - Các cam kết phải luôn được xây dựng - Một bản dựng bị hỏng đòi hỏi phải có hành động ngay lập tức từ người đi làm & / hoặc phần còn lại của nhóm. - Một bài kiểm tra thất bại chỉ nên hủy bỏ các bài kiểm tra còn lại nếu đó là một bài kiểm tra quan trọng .

Nếu bạn, với tư cách là một nhóm, hãy làm theo các thực tiễn này và thực thi chúng, ví dụ: "tên & sự xấu hổ" khi bản dựng bị hỏng thì bạn nên đi vì mọi cam kết có thể phá vỡ bản dựng sẽ nằm trên nhánh tính năng. Các cam kết khác phá vỡ bản dựng sẽ phải được xử lý ngay lập tức và sau đó bạn sẽ nhận được kết quả kiểm tra xuôi dòng của mình.

Bạn cũng có thể thêm một bài kiểm tra tự động về bản dựng "thành công" mới nhất, (không nhất thiết phải vượt qua các bài kiểm tra tích hợp), cho các bài kiểm tra UI / Web dưới dạng báo cáo chạy qua đêm vào buổi sáng.

Không có gì để làm với Scrum. Bản dựng của bạn phải liên tục ổn định, bất kể

Không ai nên kiểm tra bất cứ điều gì trừ khi họ đã thực hiện một bản dựng cục bộ và chạy thử nghiệm đơn vị cục bộ (tất nhiên cả hai đều được thông qua). Quá trình xây dựng và kiểm tra cục bộ của bạn phải nhạy cảm với các sửa đổi và có thể bỏ qua các kiểm tra cho mã chưa được thay đổi.

Bất cứ ai giới thiệu thứ gì đó khiến bản dựng bị lỗi hoặc bài kiểm tra đơn vị bị lỗi đều phải được công khai xấu hổ . Nếu bản dựng bị hỏng thì phải sửa ngay lập tức.

Vấn đề của bạn dường như là các bài kiểm tra mất quá nhiều thời gian để chạy. May mắn thay, luật của Moore đã cung cấp cho chúng tôi một giải pháp cho vấn đề đó. Ngày nay, CPU máy chủ cao cấp có thể dễ dàng có hơn 10 lõi (và hơn 10 HyperThread). Có thể có nhiều CPU như vậy trong một máy tính.

Nếu tôi có các bài kiểm tra mất nhiều thời gian như vậy, tôi sẽ giải quyết vấn đề với phần cứng nhiều hơn. Tôi sẽ mua một máy chủ cao cấp và sau đó song song hóa các thử nghiệm để các thử nghiệm tận dụng tối đa tất cả các lõi CPU. Nếu các bài kiểm tra của bạn ngày hôm nay là một luồng đơn, việc tận dụng 10 lõi và 10 HyperThred có thể giúp các bài kiểm tra chạy nhanh hơn 15 lần. Tất nhiên, điều này có nghĩa là họ cũng sử dụng bộ nhớ gấp 15 lần, vì vậy máy tính phải có đủ RAM.

Vì vậy, vài giờ sẽ biến thành 10-30 phút.

Bạn đã không nói việc xây dựng mất bao nhiêu thời gian, nhưng các công cụ xây dựng tiêu chuẩn như cho phép song song cả quá trình xây dựng. Nếu bạn song song các bài kiểm tra đơn vị của mình và máy tính dành cho nhà phát triển thông thường có 4 lõi và 4 HyperThread, thì các bài kiểm tra đơn vị dưới 10 phút sẽ biến thành dưới 2 phút. Vì vậy, có lẽ bạn có thể thực thi một chính sách mà mọi người nên chạy thử nghiệm đơn vị trước khi cam kết?

Về lỗi thử nghiệm dừng các thử nghiệm tiếp theo: không làm điều đó trên máy chủ xây dựng! Bạn muốn càng nhiều thông tin càng tốt về sự thất bại, và các bài kiểm tra thêm có thể tiết lộ điều gì đó quan trọng. Tất nhiên, nếu bản thân bản dựng bị lỗi, bạn không thể chạy thử nghiệm đơn vị. Nếu nhà phát triển chạy thử nghiệm đơn vị trên máy của chính mình, thì bạn có thể muốn hủy bỏ ở lần thất bại đầu tiên.

Tôi không thấy bất kỳ kết nối nào giữa Scrum và các vấn đề của bạn. Các vấn đề thực sự có thể xảy ra với bất kỳ quá trình phát triển.

Có phải không có nhiều cài đặt Jenkins hơn và để các nhà phát triển kiểm tra một phiên bản Jenkins riêng biệt?

Tôi nghĩ rằng giải pháp tốt nhất ở đây là để mã vượt qua tất cả các bài kiểm tra trước khi nó được kiểm tra vào nhánh chính và được biên dịch / kiểm tra bởi thể hiện chính của Jenkins. Đừng để mọi người kiểm tra mã phá vỡ bản dựng.

Tôi kiểm tra mã của mình vào nhánh phát triển, xem nó có vượt qua các bài kiểm tra và tạo một yêu cầu kéo không. Nhưng rõ ràng bạn có thể có jenkins kéo một nhánh tính năng và kiểm tra cái đó.

Điểm (2) dường như là điểm đau đớn nhất, vì vậy tôi sẽ tập trung vào đó.

Có lẽ đã đến lúc chia dự án thành nhiều mô-đun.

https://en.wikipedia.org/wiki/Dependency_inversion_principl

A. Các mô-đun cấp cao không nên phụ thuộc vào các mô-đun cấp thấp. Cả hai nên phụ thuộc vào trừu tượng.

B. Trừu tượng không nên phụ thuộc vào chi tiết. Chi tiết nên phụ thuộc vào trừu tượng.

Nếu một mô-đun không thể xây dựng, quá trình xây dựng cho các mô-đun khác sẽ có thể tiếp tục, miễn là các mô-đun khác có thể phụ thuộc vào giao diện và mã tạo nên giao diện đó đã được xây dựng thành công.

Điều này sẽ cung cấp cho bạn thông tin phản hồi về những lỗi xây dựng khác có thể xảy ra, để bạn có thời gian khắc phục nhiều hơn một mô-đun bị hỏng trước khi quá trình xây dựng tiếp theo xảy ra.

Nói chung, các nguyên tắc RẮN được hình thành để đối phó với các thư viện và xây dựng các vấn đề. Nói cách khác - bộ nguyên tắc này được hình thành để giải quyết loại vấn đề chính xác mà bạn đang gặp phải.

Là một ghi chú bên lề (xem câu trả lời của juhist), bạn không thể làm cho bản dựng chạy nhanh hơn (bằng cách song song hóa) nếu bạn không phân vùng bản dựng thành các mô-đun riêng biệt.

Tôi nghĩ rằng nhóm của bạn đang thiếu một trong những nguyên lý chính của scrum: đã hoàn thành, phần mềm hoạt động. PBI không nên được đánh dấu là đã hoàn thành cho đến khi vượt qua Định nghĩa Hoàn thành mà nhóm của bạn đã thiết lập. Định nghĩa Xong là khác nhau đối với mỗi nhóm, nhưng có thể sẽ bao gồm những thứ như:

• Mã có bài kiểm tra đơn vị
• Kiểm tra đơn vị vượt qua như là một phần của bản dựng tự động
• Mã đã được hợp nhất thành chính (và xung đột đã được giải quyết)
• Vân vân.

Vì vậy, về cơ bản, những gì đang xảy ra là nhóm của bạn đang đánh dấu những thứ được thực hiện mà thực tế là không được thực hiện. Đó là một vấn đề trong chính nó.

Ngoài ra, nó có khả năng quản lý kiểm soát phiên bản phù hợp. Nếu bạn đang sử dụng Git, thì tất cả công việc được thực hiện trong kho lưu trữ cục bộ của nhà phát triển và họ không nên đẩy bất cứ thứ gì lên điều khiển từ xa trừ khi nó "hoàn thành" và có khả năng giải phóng được. Công việc chưa hoàn thành không nên được đẩy đến kho lưu trữ chính của bạn. Nếu nhà phát triển cần làm việc trên một nhánh tính năng tồn tại lâu hơn và muốn đẩy ra điều khiển từ xa để đảm bảo rằng họ không bị mất công việc, thì họ nên làm việc với một ngã ba, và sau đó bạn sẽ hợp nhất ngã ba đó vào chính khi tính năng được "thực hiện" và có khả năng giải phóng - không phải trước đây.

Đối với TFVC, nó phức tạp hơn một chút vì mọi thứ xảy ra trên "remote". Điều đó có nghĩa là các nhà phát triển nên luôn luôn làm việc ngoài các chi nhánh, trừ khi đó là cách khắc phục nhanh. Các quy tắc tương tự được áp dụng ở đây như với Git, mặc dù: phần mềm chưa hoàn thành không được cam kết. Giai đoạn = Stage. Trong kiểm soát phiên bản được quản lý đúng cách, "chính" phải luôn luôn có thể giải phóng được. Nếu một cam kết đã được thực hiện mà bork "chính", thì bạn đã không làm đúng.