Làm thế nào để duy trì hiệu quả khi một bản dựng hầu như luôn bị hỏng


25

Tôi làm việc trong một nhóm có quy mô trung bình chia sẻ cùng một mã nguồn và trong khi vẫn tiếp tục tích hợp, nhưng vì tất cả chúng tôi phải làm việc trong cùng một chi nhánh, việc xây dựng hầu như luôn bị phá vỡ.

Vì chúng tôi cũng có một quy tắc, đã được đưa ra gần đây để giảm bớt các bản dựng bị hỏng, trong đó tuyên bố rằng không ai được phép đăng ký trong khi bản dựng có màu đỏ.

Phải nói rằng, trong một ngày mọi người đều có một số ít cửa sổ 10 - 15 phút nơi chúng tôi được phép nhận phòng.

Và khi đội ngũ đang phát triển, các cửa sổ cơ hội nhận phòng càng bị thu hẹp hơn nữa. Điều đó buộc các nhà phát triển phải tích lũy các thay đổi của họ cục bộ, điều này dẫn đến một tập hợp thay đổi lớn hơn, điều thậm chí còn khó khăn hơn để đảm bảo rằng các thay đổi đó không phá vỡ bất cứ điều gì. Bạn có thể thấy vòng luẩn quẩn.

Bạn có thể đề nghị gì để cho phép tôi duy trì hiệu quả làm việc trong môi trường như thế này. Ngoài ra, xin lưu ý rằng tôi là nhà phát triển, không phải người quản lý và không thể thay đổi quy trình hoặc hành vi của người khác nhiều.


8
Tại sao bạn không thể có chi nhánh?
Zavior

6
Giải pháp rõ ràng sẽ là thiết lập chi nhánh "cá nhân" của bạn và cam kết với nó, sau đó tích hợp chi nhánh đó với một nhóm mà nhóm làm việc trong
gnat

@Zavior có một nhánh ngụ ý một sự phức tạp thêm và do đó làm thêm - sáp nhập từ một nhánh vào thân cây. Và nó cũng tăng đến mức phức tạp - không chỉ tôi sẽ cần phải giữ cho thân cây được nâng cao, tôi cũng sẽ phải làm điều tương tự cho chi nhánh của mình.

6
@Andrew tích lũy thay đổi tại máy cục bộ là điều đầu tiên để loại bỏ, không có vấn đề gì. Các vấn đề khác bạn cũng đề cập là có thật, nhưng vấn đề này là lần đầu tiên giải quyết
gnat

6
Tôi thực sự không hiểu làm thế nào họ có thể thúc đẩy các thay đổi nếu chúng không được cập nhật cục bộ và tại sao họ lại đẩy các bản dựng bị hỏng ở tất cả các tbh
Vô dụng

Câu trả lời:


54

Để bắt đầu, nhận xét này:

... có một nhánh ngụ ý thêm một sự phức tạp và do đó làm thêm ...

là hoàn toàn sai. Tôi thường nghe nó từ những người không quen với việc phân nhánh, nhưng nó vẫn sai.

Nếu bạn có nhiều nhà phát triển tích lũy các thay đổi cục bộ, các thay đổi cục bộ của họ tạo thành một nhánh thực tế của kho lưu trữ chính.

Khi cuối cùng họ đẩy, đây là một sự hợp nhất thực tế .

Thực tế là các chi nhánh và sáp nhập của bạn là ẩn không loại bỏ sự phức tạp thêm mà bạn quan tâm, nó chỉ che giấu nó. Sự thật là làm cho quá trình này rõ ràng có thể giúp bạn (số nhiều = toàn đội) học cách quản lý nó.


Bây giờ, bạn nói

không ai được phép đăng ký trong khi xây dựng là màu đỏ

nhưng trong trường hợp này, bản dựng không bao giờ có thể được sửa, vì vậy nó không thể chính xác được.

Nói chung, nếu hợp lý để xây dựng cục bộ (nghĩa là bản dựng không quá lớn hoặc chậm), các nhà phát triển nên làm điều đó trước khi đẩy.

Tôi cho rằng đây không phải là trường hợp, bởi vì sau đó họ sẽ không đẩy các bản dựng bị hỏng ngay từ đầu, nhưng sẽ thật tuyệt nếu bạn có thể làm rõ điểm này.

Nói chung câu trả lời cho

Làm thế nào để duy trì hiệu quả khi một bản dựng hầu như luôn bị hỏng

là: ngừng phá vỡ bản dựng .


23
+9000 cho "Dừng phá vỡ bản dựng." Nghiêm túc. Toàn bộ, toàn bộ điểm tích hợp liên tục là ngừng phá vỡ bản dựng và, nếu bị hỏng, hãy sửa nó càng nhanh và càng gần chỗ phá vỡ càng tốt.
Patrick Hughes

@ Vô dụng, tôi thích bạn trả lời chung chung, nhưng tôi nghĩ tôi nên sửa câu hỏi của mình. Cá nhân tôi không phá vỡ công trình, đồng thời tôi không muốn tạo ra những đợt sóng đẩy người khác nhiều để họ có thể ngừng phá vỡ công trình. Tôi muốn biết - có bất cứ điều gì tôi có thể làm MYSELF, để duy trì MYSELF hiệu quả hơn, trong một môi trường mà công trình thường bị phá vỡ và tôi không hy vọng rằng trạng thái bị hỏng sẽ sớm được thay đổi. Muốn đầu vào của bạn về điều này. Chúc mừng.

6
Chà, bạn có thể làm việc trên nhánh riêng của mình và chọn lọc về những thay đổi ngược dòng mà bạn hợp nhất vào nhánh đó (nghĩa là chỉ có thể hợp nhất khi bản dựng có màu xanh). Nhưng, điều này thực sự làm giảm sự tương tác với các thành viên còn lại trong nhóm, khi đó sẽ là tổng thể tốt hơn để sửa chữa nhóm để bạn có thể tương tác hoàn toàn.
Vô dụng

14

nhà phát triển ... tích lũy các thay đổi của họ tại địa phương ... Bạn có thể thấy chu kỳ luẩn quẩn.

Thật là xấu xa. Tích lũy thay đổi cục bộ là một lá cờ đỏ lớn cho thấy rằng một cái gì đó đang bị thối rữa nghiêm trọng trong quá trình phát triển. Nó sắp xếp toàn bộ mục đích của việc có một hệ thống kiểm soát phiên bản .

Miễn là bạn muốn tránh xa việc thay đổi quy trình hoặc hành vi của người khác, giải pháp tự nhiên nhất là thành lập chi nhánh của riêng bạn và sử dụng nó để "tích lũy" các thay đổi của bạn (để được tích hợp thêm với chi nhánh nhóm khi bạn nhận được cơ hội).

Trên thực tế, nếu có nhiều người như bạn, bạn thậm chí có thể hợp tác và thành lập chi nhánh phát triển được chia sẻ để tự do trao đổi các cập nhật của mình mà không bị can thiệp vào các ý tưởng quản lý không đủ năng lực. Sự phân nhánh cho phép nhiều cách khác nhau để đơn giản hóa tinh thần đồng đội.

  • Lưu ý bên lề, mỗi khi người quản lý làm hoặc nói điều gì đó buộc bạn phải tránh các cam kết, để giữ mã cục bộ, hãy dịch từ của họ thành chữ in đậm và đơn giản "Tôi không đủ năng lực" .

xin lưu ý rằng tôi là nhà phát triển, không phải người quản lý và không thể thay đổi quy trình hoặc hành vi của người khác nhiều ...

Vì mục đích chính xác, bạn thực sự có thể , đây là những vấn đề ảnh hưởng và kỹ năng giao tiếp và người ta không thực sự cần có quyền lực để thay đổi mọi thứ theo ý thích của họ (tìm kiếm trên web để tìm thứ gì đó như "quản lý" nếu bạn 'quan tâm đến nhiều chi tiết hơn).

Tuy nhiên, điều đó khá cồng kềnh và tốn nhiều công sức và tôi hoàn toàn có thể hiểu nếu một người chỉ đơn giản thích tập trung vào tiền mã hóa, ít tham gia vào chính trị - vì vậy nếu bạn không muốn (mặc dù về lý thuyết bạn có thể ), điều đó có thể hiểu được. :)


7

Tôi nhạy cảm với khái niệm rằng bạn cảm thấy bất lực trong việc thay đổi môi trường, nhưng tôi nghĩ tình huống này là một thách thức nghiêm trọng đối với sự chuyên nghiệp của bạn với tư cách là một lập trình viên.

Điều gì sẽ xảy ra nếu một bác sĩ phẫu thuật lưu trữ dao mổ bẩn với những cái sạch? Điều gì sẽ xảy ra nếu một thợ sửa ống nước không kiểm tra các đường ống anh ta lắp đặt? Điều gì sẽ xảy ra nếu một nghệ sĩ violin luôn chơi hết mình với dàn nhạc?

Tại sao các lập trình viên nên được miễn làm việc theo nhóm và phép lịch sự thông thường? Là thành viên của nhóm đó, bạn chia sẻ trách nhiệm về kết quả. Thật vô trách nhiệm khi bỏ qua đội vì nó phá hoại những nỗ lực của chính nó.

Tôi tò mò rằng quy tắc "không ai được phép đăng ký trong khi xây dựng là màu đỏ" đến từ đâu? Đó là một quy tắc tốt nếu sau đó tập trung mọi người vào việc sửa chữa bản dựng. Tôi sẽ cố gắng dẫn dắt bằng ví dụ và giúp sửa chữa bản dựng bất cứ khi nào nó bị hỏng. Hãy đối mặt với nó, dù sao bạn cũng không làm gì khác. Nếu điều này làm bạn khó chịu, thì tôi sẽ đề nghị nói lên những lo lắng đó. Giọng nói của một người tích cực cố gắng cải thiện một tình huống có ảnh hưởng nhiều hơn anh chàng càu nhàu trong góc.


5

Tôi nghĩ rằng miễn là bạn nghĩ rằng bạn "chỉ là một nhà phát triển" và do đó bạn không thể thay đổi những điều bạn sẽ phải chịu từ vấn đề này.

Điều bạn cần làm là bạn cần hoàn nguyên mọi cam kết từ kho lưu trữ mỗi khi ai đó phá vỡ bản dựng và sau đó nói với anh ta rằng anh ta vừa phá vỡ bản dựng và điều đó cần phải dừng lại. Bạn cũng cần giải thích tình huống này cho người quản lý và nói với anh ta rằng năng suất của nhóm bạn đang bị ảnh hưởng vì vấn đề này.

Bạn cần làm bất cứ điều gì có thể để thay đổi quy trình tốt hơn và nói rằng bạn xin lỗi sau đó thay vì xin phép.

Tôi nghĩ rằng bạn và nhóm của bạn đang ở trong tình huống cần thay đổi quy trình và bạn không thể làm việc hiệu quả với mô hình bị hỏng đó. Tôi cũng nghĩ rằng trách nhiệm của bạn là phải làm gì đó về vấn đề đó khi bạn đã nhận ra nó. Nếu không có ai khác sẽ làm bất cứ điều gì về vấn đề này, bạn là người phải!


-2 và không ai muốn chia sẻ lý do tại sao .. heh heh.
hequ

1
Bạn không thể làm món trứng tráng mà không làm vỡ một số trứng.
William Payne

2

Tôi có thể liên quan đến hoàn cảnh của bạn, tôi đã phải đối mặt với một tình huống tương tự với dự án gần đây nhất của tôi tại nơi làm việc. Chúng tôi đã kết thúc việc triển khai một hệ thống "khoai tây nóng" trong đó nhà phát triển gần đây nhất đã phá vỡ bản dựng phải trông trẻ / bảo mẫu / giám sát nó cho đến khi nó được sửa chữa vượt qua tất cả các thử nghiệm xác minh của chúng tôi.

Điều này đã thành công vì các thử nghiệm xây dựng và xác minh thường xuyên mất ~ 4 giờ, do đó, việc phá vỡ bản dựng có nghĩa là bạn mất nửa ngày để thực hiện công việc thực tế. Không cần phải nói điều này dẫn đến việc các nhà phát triển sử dụng các nhánh hiệu quả hơn trước khi hợp nhất chúng vào thân cây. Đối với hầu hết các nhà phát triển, suy nghĩ trước đó là "Tôi sẽ chỉ để hệ thống xây dựng CI thông báo cho tôi nếu mã của tôi bị hỏng."


1

Một thay đổi đơn giản đối với hệ thống CI sẽ thực hiện điều đó: mọi thay đổi phá vỡ bản dựng sẽ được khôi phục tự động. Thậm chí tốt hơn, hãy để kho CI trở thành khu vực tổ chức, nơi các thay đổi chỉ được đẩy qua kho lưu trữ có thẩm quyền khi bản dựng có màu xanh. Các công cụ như Gerrit có thể giúp đỡ ở đây.


3
Nhưng để thực hiện nhiệm vụ này là không thể "... hãy nhớ rằng tôi là nhà phát triển, không phải người quản lý và không thể thay đổi quy trình ..."
SChepurin

@SChepuriyour quá trình của bạn không hiệu quả, bạn có thể thay đổi quy trình, thời gian. Là một nhà phát triển, bạn có thể không chấp thuận thay đổi, nhưng bạn luôn có thể làm việc theo hướng cải tiến quy trình.
oefe

1

Hai điều khác có thể giúp ở đây:

  • nhóm của bạn có thể kiểm tra khói CI xây dựng tại địa phương không? Nếu bạn kiểm tra xem bạn không phá vỡ bản dựng - hay ít nhất là không phá vỡ bản dựng theo những cách thông thường mà không phải cam kết và kích hoạt quản lý và nhóm.
  • có nhiều cách để xác định các bản dựng bị hỏng tùy thuộc vào cách bạn kiến ​​trúc sư CI. Điều này bao gồm xác định bị hỏng - dưới sự phát triển nặng nề, chúng tôi không coi việc thử nghiệm thất bại là phá vỡ mà là một mục tiêu khác để hướng tới.

Nhưng bạn nên thực sự nhìn vào các chi nhánh.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.