Bao nhiêu nỗ lực để duy trì một hệ thống xây dựng?

9

Trong StackExchange Podcast # 09, nó được nhận xét:

Một nghiên cứu khác gần đây đã xem xét có bao nhiêu nỗ lực để duy trì hệ thống xây dựng: 5 đến 30% của tất cả nỗ lực phát triển được dành cho việc duy trì hệ thống xây dựng. Với các biến thể là rất lớn ngay cả khi làm việc trên các dự án tương tự.

Tên của nghiên cứu được tham chiếu là gì, và nó có thể được tìm thấy ở đâu? Âm thanh của podcast không chứa thêm chi tiết.

Ngoài ra, có ai có bất kỳ liên kết đến các nghiên cứu khác trong cùng một chủ đề.

commandline-build-tool

— Neil
nguồn

3

Ồ Không bao giờ nghĩ rằng một cửa hàng có thể dành nhiều thời gian cho hệ thống xây dựng. Chúng tôi có một hệ thống xây dựng được xây dựng tùy chỉnh bằng tay, xây dựng hàng đêm tất cả (20 một số) bản phát hành và (50 một số) nhánh phát triển (nếu các thay đổi đã được cam kết), bắt đầu kiểm tra đơn vị và dừng và khởi động máy chủ thử nghiệm (một hoặc nhiều hơn cho mỗi lần phát hành và một hoặc nhiều hơn cho nhiều nhánh phát triển), kết quả thư, v.v. Tuy nhiên, trong 4 năm tôi làm việc ở nhà tuyển dụng này, tôi không nghĩ rằng chúng tôi đã dành nhiều hơn một vài tuần cho nó và điều đó bao gồm mở rộng các tính năng của giải pháp được xây dựng tùy chỉnh của chúng tôi!

— Marjan Venema

Đó là những gì xảy ra khi mọi người đề cập đến một cái gì đó / ai đó và quên thêm các tài liệu tham khảo ...

— wleao

Không biết nghiên cứu, nhưng kết quả có thể khác nhau tùy thuộc vào những gì bạn xác định bằng cách "duy trì hệ thống xây dựng". "Là thêm hoặc thay đổi tập tin" một phần của điều đó? Là thiết lập một phần cài đặt của "bảo trì hệ thống xây dựng"?

— Doc Brown

1

Tôi chưa nghe thấy podcast, nhưng nghiên cứu này có lẽ là một bài báo từ ICSE gần đây nhất , được gọi là "Một nghiên cứu thực nghiệm về nỗ lực bảo trì xây dựng" của Shane McIntosh et al. Kiểm tra liên kết Trực tiếp (hoặc trang DOI chính thức nếu bạn muốn siêu dữ liệu).

Nghiên cứu của họ tập trung chủ yếu vào tần suất thay đổi mã nguồn ảnh hưởng đến bản dựng và số lượng nhà phát triển trong một nhóm thường quan tâm đến việc duy trì bản dựng. Tôi nhớ rằng đó là một nghiên cứu thú vị, nhưng tôi thấy các con số hơi khó diễn giải, như thường thấy với các nghiên cứu thực nghiệm cố gắng tìm mối liên hệ giữa mọi thứ :)

— Boong
nguồn

2

Tôi không có liên kết cho bạn, nhưng nói từ kinh nghiệm cá nhân, tỷ lệ phần trăm đó thay đổi theo 2 điểm chính: 1) thiết kế hệ thống và độ phức tạp 2) và tổ chức cá nhân

Một hệ thống được thiết kế tốt sẽ đòi hỏi nỗ lực tối thiểu để duy trì ngay cả khi nó khá phức tạp. Nhưng nếu nhân viên của bạn không được đào tạo và tổ chức đúng cách để xử lý mã, có lẽ bạn sẽ mất nhiều thời gian để sửa các bản dựng xấu hoặc các cam kết sai và các lượt thích ...

Tuy nhiên, khi bạn có môi trường phát triển, hỏi đáp, RC và sản xuất ... Tất cả đều phải trả giá cho quá trình đi từ phát triển đến sản xuất thực tế.

Tôi muốn nói rằng tỷ lệ phần trăm là chính xác, nghiêng về gần với mức 30% hơn 5%. Nếu tất cả những gì bạn đang đầu tư là 5%, bạn đang làm một công việc tốt. (Điều này bao gồm các lỗi được tìm thấy trong Q & A hoặc RC hoặc thậm chí Sản xuất do quản lý sai của Hệ thống Xây dựng, có thể gây ra sự chậm trễ lớn).

— AJC
nguồn

Nếu tất cả những gì bạn đang đầu tư là 5%, tôi sẽ đề nghị bạn không đo lường mọi thứ hoặc chính xác.

— mattnz

không mờ Bạn đang sử dụng một định nghĩa khác. Hầu hết các công ty tôi từng làm việc đều KHÔNG có hệ thống xây dựng, vì không có máy chủ xây dựng tự động, tích hợp VCS (thường không có VCS nào ngoại trừ chính các dự án có thể tự thiết lập, kết thúc dưới radar), v.v. Trong bất kỳ "nghiên cứu" nào về tỷ lệ phần trăm tài nguyên được sử dụng để duy trì "hệ thống xây dựng", cuối cùng họ sẽ được liệt kê là chi tiêu không có gì, trừ khi nó bị phá vỡ để bao gồm nỗ lực dành cho việc duy trì tất cả các tập lệnh ANT và Maven, một cái gì đó hiếm khi được thực hiện.

— jwenting