Giới thiệu chính sách phân nhánh kiểm soát phiên bản cho một nhóm nhỏ


17

Tôi là một nhà thầu gần đây đã bắt đầu với một công ty.

Nhóm là 3 nhà phát triển bao gồm 2 nhà phát triển từ trung cấp đến trung cấp, với một nhà phát triển khác ở cùng cấp độ bắt đầu sớm và bản thân tôi (6 Năm xp). Đối với cả các nhà phát triển hiện tại, đây là công việc đầu tiên của họ ngoài đại học / cao đẳng và họ chưa bao giờ có một nhà phát triển cao cấp nào giám sát công việc của họ trước đây.

Không có chính sách kiểm soát Phiên bản rõ ràng. Các nhà phát triển thực hiện tất cả các phát triển trên thân cây và sau đó triển khai để sản xuất trực tiếp từ các máy phát triển của họ. Nhóm hiện tại không quen thuộc với việc phân nhánh.

Tôi đang thay đổi tất cả điều này và giới thiệu các máy chủ thử nghiệm / dàn dựng / sản xuất CI, TDD, v.v., cùng với chính sách kiểm soát phiên bản để khen ngợi điều này.

Hệ thống kiểm soát nguồn là TFS, cái mà tôi chưa từng sử dụng trước đây. Nó được cấu hình như một kho lưu trữ khổng lồ.

Tôi đã viết ra một vài gợi ý cho họ, nhưng liệu còn điều gì khác tôi nên thêm / sửa đổi, ghi nhớ kinh nghiệm của đội không?

Chính sách kiểm soát phiên bản

Phát triển được thực hiện trên thân cây

Nếu một thay đổi được ước tính mất hơn một tuần thì nên thực hiện trên một nhánh, với sự hợp nhất thường xuyên từ thân cây vào nhánh để ngăn chặn cả hai không đồng bộ.

Phát hành chi nhánh được tạo cho mã sản xuất. Chi nhánh đó chỉ nên chứa mã ổn định. Chúng tôi có thể có một nhánh phát hành được cập nhật từ trung kế một lần mỗi lần chạy nước rút hoặc chúng tôi có thể tạo một nhánh phát hành riêng cho mỗi tuần.

Nếu một sửa lỗi khẩn cấp ảnh hưởng đến mã sản xuất cần phải được thực hiện, thì nó sẽ được thực hiện trên nhánh phát hành và sáp nhập trở lại vào thân cây.

Nếu chúng ta áp dụng chiến lược một nhánh phát hành thì thân cây sẽ được sáp nhập vào nhánh phát hành một lần cho mỗi lần chạy nước rút vào cuối giai đoạn nước rút.

Nếu chúng tôi áp dụng nhánh riêng cho mỗi chiến lược phát hành, thì thân cây KHÔNG BAO GIỜ được sáp nhập vào nhánh Phát hành

Trong một số trường hợp, có thể cần phải sửa lỗi hai lần trên các nhánh khác nhau, nếu các nhánh đã chuyển hướng quá nhiều. Nếu chúng ta đang chạy nước rút ngắn thì điều này không nên xảy ra quá thường xuyên.


Tôi dự định có ba máy chủ. Kiểm tra môi trường luôn chạy mã mới nhất trong repo. Một môi trường dàn dựng đang chạy ứng cử viên phát hành mới nhất để dàn dựng / thử nghiệm Mã ứng viên phát hành và các mục đích UAT, và môi trường sản xuất.

Lý do tại sao tôi dự định làm điều này là cho đến nay khách hàng chỉ mới thực hiện phần mềm nội bộ. Dự án mới nhất dành cho một khách hàng truyền thông có cấu hình cao và cảm giác của tôi là nhóm cần áp dụng một mô hình phát triển chuyên nghiệp hơn so với những gì họ làm vào lúc này.

Ví dụ tại thời điểm này, một người dùng có thể gọi điện cho nhóm với báo cáo lỗi. Các nhà phát triển xác định vị trí và sửa lỗi, thực hiện kiểm tra nhanh nhãn cầu trên máy của chính họ và sau đó triển khai thẳng vào sản xuất. Không có thử nghiệm tự động hoặc bất cứ điều gì.


Nhìn nhận lại tôi nghĩ nhánh tính năng là một bước quá xa và tôi sẽ loại bỏ nó.

Vì vậy, về cơ bản, nó đi xuống a) không phân nhánh nào cả) b) một nhánh phát hành và thân cây, và c) một nhánh phát hành trên mỗi bản phát hành và thân cây.

Tôi đã nghiêng về phía sau. Suy nghĩ ban đầu của tôi là tôi sẽ có cả một ứng cử viên phát hành và một bản phát hành để tồn tại trên các máy chủ riêng biệt (UAT / Sản xuất) cùng một lúc, nhưng chính xác thì thân cây là ứng cử viên phát hành tại bất kỳ thời điểm nào, do đó, một chi nhánh phát hành đang nghiêng về phía điên rồ. Suy nghĩ duy nhất của tôi là nếu chúng tôi không muốn các bên liên quan của mình thấy mã phát triển thì chúng tôi có thể cần một nhánh ứng viên phát hành riêng biệt, nhưng YAGNI và tất cả những thứ đó .....


3
bạn đã xem xét thêm một lời giải thích tại sao bạn chọn cách này? nói, tương tự như cách nó được thực hiện ở đây . Ngoài ra, bạn có kiểm tra "Hướng dẫn phân nhánh máy chủ Microsoft Team Foundation" (ví dụ: ở đây ) không?
gnat

3
Hãy thử cái này
gbjbaanb

1
Hãy nhớ rằng tôi đang sử dụng TFS chứ không phải DVCS như GIT. Điều đó có vẻ hơi cụ thể.
MrBliz

2
Phần cuối của liên kết đó có nội dung: "Mọi người đều hoạt động trong thân cây. Chi nhánh khi bạn phát hành mã. Chi nhánh tắt một bản phát hành khi bạn cần tạo một bản sửa lỗi cho mã đã được phát hành. Chi nhánh cho các nguyên mẫu." Tôi sẽ đề nghị rằng để bắt đầu đơn giản, bạn chỉ cần gắn thẻ phát hành khi bạn chắc chắn chắc chắn rằng chúng đã được thực hiện. Trừ khi bạn có nhiều nhà phát triển làm việc trên nhiều tính năng, không cần nhiều hơn 1 chi nhánh. Mọi người thêm tính năng, mọi người sửa lỗi ứng viên phát hành, mọi người đồng ý khi nó sẵn sàng gắn thẻ. Điều đó có nghĩa là bạn chỉ phải trao các nhánh để sửa lỗi sau này.
TafT

1
Tôi không thoải mái khi đặt câu hỏi này làm câu trả lời, vì nó quá dựa trên ý kiến, nhưng tôi đã thành công lớn khi thuyết phục mọi người sử dụng thẻ "được biết đến cuối cùng" (LKG), là thẻ di chuyển trên thân cây xác định "may mắn cuối cùng" "Phiên bản (CCB, thử nghiệm, v.v.). Các nhà phát triển được thông báo rằng các bản phát hành sẽ được thực hiện từ thẻ LKG này, chứ không phải phần đầu của thân cây, và hơn thế nữa, họ có thể tự do sử dụng bất kỳ cách tiếp cận nào có ý nghĩa với họ tại thời điểm đó. Tôi đã tìm thấy mô hình này để tạo các nhánh tính năng một cách tự nhiên khi thời gian phù hợp, mà không cần bất kỳ nỗ lực trước hoặc công việc bổ sung nào trên các bộ phận của nhà phát triển.
Cort Ammon - Hồi phục lại

Câu trả lời:


16

Đối với một nhóm 3-4 nhà phát triển, bạn đang đề xuất CÁCH quá nhiều chi nhánh.

Mỗi chi nhánh bạn tạo là chi phí bổ sung đi kèm với chi phí (thời gian hợp nhất, theo dõi những gì ở đâu, v.v.). Bạn cần chắc chắn rằng lợi ích bạn nhận được từ việc có chi nhánh lớn hơn chi phí.

Hãy nhớ rằng lợi ích thực sự duy nhất cho một chi nhánh là cách ly mã. Điều đó có nghĩa là bạn cần một lý do cụ thể để muốn tách mã.

Có một nhánh phát hành riêng cho mỗi lần chạy nước rút là điên rồ. Tại sao bạn cần mã từ một lần chạy nước rút được phân lập từ mã cho lần tiếp theo? Tại sao không chỉ có một nhánh phát hành ổn định duy nhất được chuyển tiếp với mỗi lần chạy nước rút?

Nếu một thay đổi được ước tính mất hơn một tuần thì nên thực hiện trên một nhánh, với sự hợp nhất thường xuyên từ thân cây vào nhánh để ngăn chặn cả hai không đồng bộ.

Hầu như bất kỳ tính năng mới không tầm thường nào sẽ mất ít nhất một tuần trong thời gian thực sau khi bạn tính đến việc phát triển, thử nghiệm cho nhà phát triển, gián đoạn hàng ngày và các hoạt động khác, v.v.

Ngoài ra, "hợp nhất thường xuyên" là gì? Hằng ngày? Hàng tuần? Mỗi hợp nhất bạn thực hiện đều mất thời gian - bạn cần đảm bảo rằng nhánh hợp nhất đích sẽ xây dựng & chạy sau các thay đổi của bạn. Trên một nhóm nhỏ, việc sáp nhập thường xuyên là rất nhiều chi phí.

Chúng tôi có một nhóm gồm 4 nhà phát triển làm việc trên một cơ sở mã hơn 1 triệu dòng và đây là cách chúng tôi vận hành:

  • Chi nhánh chính nơi tất cả sự phát triển được thực hiện
  • Một chi nhánh cho mỗi bản phát hành chính (được thực hiện khoảng một lần mỗi năm)

Một nguyên tắc chính là: không kiểm tra mã không xây dựng.

Đó là nó. Đơn giản, dễ hiểu, có được sự cô lập mà chúng ta cần (bất cứ lúc nào chúng ta có thể tạo bản dựng phát hành cho bất kỳ phiên bản nào).

Những mặt tích cực để có tất cả các công việc phát triển được thực hiện trên một nhánh:

  1. Các nhà phát triển luôn không đồng bộ với nhau. Không có sự hợp nhất đau đớn vì hai nhà phát triển đã tắt các chi nhánh của họ trong nhiều tuần để tạo ra những thay đổi không tương thích.
  2. Các bản dựng bị hỏng được tìm thấy trong cùng một ngày. Chúng tôi có một bản dựng hàng đêm chạy mã mới nhất trên main. Nếu ai đó kiểm tra mã không xây dựng vì một số lý do, chúng tôi sẽ biết ngay.
  3. Với tất cả mọi người luôn làm việc trên cùng một mã, làm tăng khả năng lỗi được phát hiện sớm hơn là muộn hơn.
  4. Không có chi phí hợp nhất ngoài các bản sửa lỗi được nhắm mục tiêu để phát hành các chi nhánh. Trên một đội nhỏ, đây là một đội lớn.

10
"Hãy nhớ rằng lợi ích thực sự duy nhất cho một chi nhánh là cách ly mã. Điều đó có nghĩa là bạn cần một lý do cụ thể để muốn có mã bị cô lập." - Làm thế nào về đánh giá mã? Tôi nghĩ đó là một lý do tốt, thậm chí chỉ có hai nhà phát triển.
BlueRaja - Daniel Pflughoeft

2
Đánh giá mã và phân nhánh không thực sự liên quan. Bạn có nói rằng bạn không muốn mã được đăng ký vào một chi nhánh cụ thể trước khi nó được xem xét?
17 trên 26

5
@ 17of26, vâng. Đánh giá mã thường được sử dụng như một điều kiện tiên quyết để có trên dòng chính. Do đó, bạn phải hiển thị mã theo một cách nào đó trước đó: trên màn hình của bạn, trong email hoặc - trong nhiều thiết lập - trên một nhánh. Điều này hoạt động tốt nhất với một công cụ quản lý repo như GitHub hoặc gerrit.
Paul Draper

3
TFS hỗ trợ đánh giá mã thông qua các kệ, là các khu vực tạm thời trong kiểm soát nguồn. Mã có thể sống ở đó cho đến khi được xem xét và sau đó đăng ký.
17 trên 26

2
Tôi đoán vấn đề là, các chi nhánh không thực sự là cơ chế phù hợp để sử dụng để đánh giá mã.
17 trên 26

31

Bạn đã viết ra một vài gợi ý cho họ, nhưng bạn chưa giải thích được tại sao cách tiếp cận của bạn tốt hơn phương pháp họ đã sử dụng . Điều này có thể có vấn đề. Nếu bạn là người có tinh thần, chúng tôi sẽ làm theo cách của tôi, vì tôi có sáu năm kinh nghiệm chuyên môn và bạn không phải (và đọc câu hỏi của bạn, nó trông giống hệt như vậy), hãy sẵn sàng để bị ghét các thành viên trong nhóm của bạn, những người sẽ cố gắng làm bất cứ điều gì họ không thể áp dụng các khái niệm của bạn.

Họ có một vấn đề cần được giải quyết? Điều quan trọng là phải trả lời câu hỏi này trước tiên, bởi vì họ thực sự có vấn đề và sẽ hoan nghênh đề xuất của bạn, hoặc họ hoàn toàn làm việc tốt như họ hiện đang làm, và bạn chỉ đang thúc đẩy họ cách làm việc của bạn , chỉ vì bạn thích làm việc theo cách này

Cuối cùng, việc buộc họ sử dụng các nhánh có thể có tác động cực kỳ tiêu cực . Làm việc với một thân cây rất dễ dàng, đặc biệt là trong môi trường Agile. Một nhà phát triển cam kết các thay đổi đối với trung kế, cuối cùng xử lý các xung đột nhỏ và những thay đổi đó ngay lập tức được sử dụng bởi nền tảng Tích hợp liên tục. Với các chi nhánh:

  • Một nhà phát triển phải suy nghĩ nên thay đổi ở đâu,

  • Ai đó phải quản lý các chi nhánh và sáp nhập từ các chi nhánh vào thân cây,

  • Việc hợp nhất giữa các chi nhánh được thực hiện ít thường xuyên hơn so với các cam kết, điều đó có nghĩa là ai đó phải giải quyết các xung đột lớn hơn và khó xử lý hơn so với xung đột giữa hai cam kết,

  • Mọi cam kết không nhất thiết phải đi vào Tích hợp liên tục, điều này làm trì hoãn thông tin mà các nhà phát triển nhận được về các hiệu ứng mà một cam kết có thể có (đặc biệt là hồi quy).

Thực tế là:

Nhóm hiện tại không quen thuộc với việc phân nhánh

làm cho mọi thứ thậm chí còn tồi tệ hơn Tôi đã làm việc trong một nhóm lập trình viên thiếu kinh nghiệm, nơi một người quản lý thiếu kinh nghiệm quyết định chơi với các chi nhánh. Điều này dẫn đến rất nhiều ( rất nhiều ) thời gian lãng phí và chính xác là điều bạn muốn tránh cho một dự án có thời hạn.


3
Trong mô hình này, làm thế nào bạn có thể ngăn chặn mã không ổn định được đưa vào sản xuất mà không cần phân nhánh?
MrBliz

2
@MrBliz: thông qua các công tắc. Bạn có thể kích hoạt một tính năng cho nhà phát triển, nhưng tắt nó cho người dùng cuối nếu nó chưa sẵn sàng cho RTM.
Arseni Mourzenko

3
Ghi nhớ kinh nghiệm của các nhà phát triển mà tôi đang làm việc và thiếu kiểm tra tự động hiện tại, tôi không nghĩ rằng đó sẽ là một ý tưởng tốt cho tình huống của chúng tôi.
MrBliz

4
@MrBliz bạn dừng mã không ổn định được đưa vào sản xuất bằng cách cách ly nó trong các nhánh phát hành (đó chính xác là mục đích của chúng) và bằng cách thử nghiệm nó. Chi nhánh tính năng không giúp đỡ trong đó; trong thực tế, những điều này mang đến rủi ro cao hơn trong việc giới thiệu sự mất ổn định bởi các sự hợp nhất lớn, không tích hợp, khó kiểm soát
gnat

1
@MrBliz yeah Tôi nhận thấy điều đó (và tôi nghĩ rằng bạn đã hiểu đúng, nếu chỉ bỏ lỡ để giải thích lý do để hỗ trợ điều đó). Chỉ là bình luận của bạn và câu trả lời này không đề cập rõ ràng cho dù đó là về phát hành hay các nhánh tính năng (hoặc cả hai?), Vì vậy tôi đã nhận xét để nhấn mạnh sự khác biệt . FWIW mơ hồ về điều này có lẽ là điều duy nhất mà tôi không thích về câu trả lời này
gnat

3

Giống như Mainma nói, hãy cẩn thận với sự phân nhánh. Bạn đề cập đến việc phân nhánh vài tuần một lần, có thực sự cần thiết phải có nhiều chi nhánh không?

Ngoài ra, bạn cũng có thể có mô hình 'kéo' thay vì mô hình đẩy. Nếu bạn đang sử dụng Git hoặc Mercurial, bạn có thể có một máy chủ tích hợp xác thực các thay đổi của chúng trước khi chuyển sang máy chủ trung tâm. Trong TFS, bạn có thể thực hiện một số thứ tương tự bằng cách sử dụng đăng ký có kiểm soát . Bằng cách này, bạn có thể xác nhận và tránh sự phức tạp của các nhánh.


Thực tế, sẽ chỉ có ba nhánh hoạt động (phát hành, phát hành ứng cử viên và thân cây) tại bất kỳ thời điểm nào và hầu hết thời gian chỉ là nhánh phát hành và thân cây.
MrBliz

Các nhánh cũ sẽ bị xóa trong TFS, hoặc ẩn chính xác hơn.
MrBliz
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.