Kiểm soát nguồn: Vai trò và trách nhiệm - Thực tiễn tốt nhất

Tôi đang tìm kiếm "Thực tiễn tốt nhất" liên quan đến vai trò và trách nhiệm, cụ thể là người chịu trách nhiệm sáp nhập từ các nhánh phát triển đến trung kế (hoặc chính). Về cơ bản tôi đang tìm kiếm đạn dược để giúp tôi.

Hãy để tôi mô tả những gì tôi phải đối mặt. Tôi là nhà phát triển chính (chủ sở hữu) của một ứng dụng cụ thể. Công ty của chúng tôi gần đây đã chuyển từ VSS (nơi tôi là quản trị viên của cơ sở dữ liệu VSS nơi ứng dụng của tôi được lưu trữ) sang TFS (nơi tôi chỉ có quyền trên các nhánh phát triển được tạo bởi nhóm "hoạt động" của chúng tôi). Trong các công việc trước đây, tôi là Quản trị viên TFS, vì vậy tôi biết cách của mình xung quanh TFS và MSBuild.

Tôi không có vấn đề gì với chiến lược phân nhánh và hợp nhất đang được sử dụng (nhánh chính, với các nhánh phát triển dự án / lỗi được tạo khi cần thiết, sáp nhập trở lại chính sau đó được thăng cấp thành nhánh phát hành). Các vấn đề tôi có là:

1. Tôi không thể tạo chi nhánh của riêng mình. Tôi phải tạo một nhiệm vụ TFS để có một thành viên nhóm "hoạt động" tạo chi nhánh cho tôi.

2. Tôi không thể hợp nhất từ ​​Main vào nhánh phát triển của mình. Tôi phải tạo một nhiệm vụ TFS để thành viên nhóm "hoạt động" thực hiện hợp nhất và sau đó hy vọng anh ta không "bước lên" bất kỳ thay đổi nào trong nhóm của tôi vì "anh chàng ops" có thể hoặc không phải là nhà phát triển và chắc chắn có ít để không có kiến ​​thức về mã anh ta đang hợp nhất.

3. Tôi không thể hợp nhất từ ​​phát triển thành Chính. Một lần nữa tôi phải tạo một nhiệm vụ TFS để "anh chàng ops" thực hiện việc hợp nhất, hy vọng rằng anh ta thực hiện đúng. Sau đó, tôi phải tạo một tác vụ TFS khác để hợp nhất trở lại chi nhánh của mình để tôi có thể giải quyết mọi vấn đề xảy ra bằng cách hợp nhất không phải nhà phát triển với Main.

4. Tôi không thể tạo hoặc chỉnh sửa tập lệnh MSBuild. Một lần nữa tôi phải làm việc với nhóm "ops" mới đối với MSBuild để chỉ có thể thực hiện các tác vụ xây dựng cơ bản nhất. (Quên bất cứ điều gì phức tạp, hoặc trời cấm một nhiệm vụ tùy chỉnh).

5. Tôi không thể thực thi tập lệnh MSBuild. Một lần nữa chỉ có nhóm "ops" có thể làm điều này.

6. Trên hết, thông thường đó là tài nguyên "ngoài khơi" thực hiện các nhiệm vụ được yêu cầu, vì vậy ngay cả khi tôi tạo nhiệm vụ (chi nhánh / hợp nhất / xây dựng) vào sáng sớm, có thể nó sẽ không được hoàn thành Cho đến tối hôm đó.

Bây giờ tôi không có vấn đề gì với nhóm "hoạt động" duy trì các nhánh phát hành. Vì tất cả những gì họ đang làm là (về cơ bản) lấy phiên bản mới nhất từ ​​Main và quảng bá nó cho chi nhánh phát hành; Vì vậy, miễn là "Chính" ổn định và sẵn sàng, nhánh phát hành sẽ tốt.

Ý kiến ​​của tôi là các lãnh đạo kỹ thuật (như tôi) phải chịu trách nhiệm duy trì trung kế ("Chính") và bất kỳ sự hợp nhất nào đến / từ các nhánh phát triển. Trưởng nhóm cũng cần có khả năng tạo các tập lệnh MS Build để xây dựng và triển khai vào môi trường thử nghiệm Tích hợp.

Bất cứ ai cũng có thể hướng dẫn tôi đến một tài liệu Thực tiễn Tốt nhất sẽ giúp tôi chứng minh trường hợp của mình? Tất cả các tìm kiếm của tôi chỉ xuất hiện các Thực tiễn Tốt nhất liên quan đến các kỹ thuật phân nhánh và sáp nhập, và không đề cập đến việc WHO nên thực hiện phân nhánh / sáp nhập nói trên.

Tổng quát của tôi về các thực tiễn tốt nhất là bất kỳ thành viên nào trong nhóm phát triển sẽ có thể thực hiện bất kỳ hành động nào trên cây giả định rằng những hành động đó không làm những việc như khởi động triển khai sản xuất. Trong trường hợp một chi nhánh / thẻ / kho lưu trữ cụ thể hoạt động như một nguồn để triển khai tự động đưa vào một số kiểm soát thay đổi hợp lý hoặc các rào cản đối với mục nhập, thì nhiều hơn từ việc giữ sai lầm chỉ là quan điểm sai lầm so với góc độ kiểm soát. Tôi sẽ khuyến khích các nhà phát triển tạo các nhánh và cải thiện các tập lệnh xây dựng. Tôi sẽ tìm cách để các nhà phát triển truy cập vào sản xuất nếu cần. Một phần của điểm kiểm soát nguồn là nó là một công cụ xóa lỗi hiệu quả - những điều tồi tệ nhất bạn cần làm là quay trở lại một hoặc hai vòng quay và tách ra khỏi đó.

Thật không may, điều này không giống như cách tiếp cận họ đã thực hiện ở đây. Để đánh bại điều này tôi nghĩ bạn cần phải bao quát một vài góc độ:

a) Chứng minh rằng các chính sách này gây bất lợi cho việc phát triển mọi thứ. Ghi nhật ký tất cả thời gian bạn chờ đợi vào ops để làm việc trên một cái gì đó. Điều này một mình nên bán quản lý hợp lý về lý do tại sao đây là một chính sách tồi.

b) Kết bạn với Ops - có lẽ có lý do cho chính sách này. Có lẽ lý do đó có thể được giải quyết theo cách hiệu quả hơn.

Hi vọng điêu nay co ich.

Thực tiễn tôi đã thấy là:

1. Bất cứ ai cũng có thể tạo ra các nhánh công việc theo nội dung trái tim của họ. Một nhà phát triển phải có khả năng tạo một nhánh tính năng trong lần thứ hai họ thấy có một điểm trong việc lưu trữ công việc hiện tại của họ đang diễn ra. Bởi vì họ muốn / nên sao lưu nó vào cuối ngày, muốn chia sẻ nó với một thành viên khác trong nhóm, cần được bảo vệ khỏi những thay đổi trong chính hoặc bất cứ điều gì.

2. Bất cứ ai cũng có thể làm bất cứ điều gì hoàn toàn để phát triển các ngành. Nhà phát triển phải có khả năng hợp nhất từ ​​chính ngay khi nhà phát triển khác nói với họ điều gì đó họ cần đã được tích hợp vào chính.

3. Để hợp nhất thành chính (tích hợp), có ba tùy chọn:

   • Các nhà phát triển tự làm điều này. Họ chỉ thảo luận về các rủi ro với nhà phát triển chính và kiểm tra các tính năng một cách thích hợp. Điều đó ngụ ý bất kỳ ai cũng có quyền; nếu ai đó phá vỡ các quy tắc, họ sẽ bị mắng và thay đổi sai được hoàn nguyên.
   • Một nhà phát triển khác làm điều đó sau khi xem xét các thay đổi. Nó vẫn yêu cầu mọi người có quyền để làm điều đó; các quy tắc vẫn được thi hành bởi nhà phát triển chính.
   • Có nhà tích hợp được chỉ định người xem xét và sáp nhập vào chính. Nhưng nhà tích hợp là một phần của nhóm và cần hiểu mã. Trong nhóm nhỏ hơn, nó sẽ là cùng một người với kiến ​​trúc sư, về nhóm lớn hơn họ sẽ tách biệt, nhưng sẽ cần phải hợp tác chặt chẽ.

4. Bất cứ ai chuẩn bị một tính năng nên điều chỉnh kịch bản xây dựng. Nhưng tôi không chắc nó hoạt động như thế nào với TFS; trong các hệ thống tôi đã sử dụng tập lệnh xây dựng luôn chỉ là một tệp được phiên bản, vì vậy các nhà phát triển đã chỉnh sửa nó giống như mọi tập tin khác và nó được tích hợp cùng với mọi thứ khác.

5. Nếu có một nhà tích hợp được chỉ định, họ thường đảm nhiệm việc xác định (kịch bản nào sẽ chạy) và bắt đầu các bản dựng. Mặt khác, trưởng nhóm thực hiện việc đó, thành viên nhóm được chỉ định thực hiện hoặc bất kỳ ai cũng có quyền và các đại biểu trưởng nhóm thiết lập và bắt đầu xây dựng cụ thể trên cơ sở từng trường hợp cụ thể.

6. Trong mọi trường hợp, các hoạt động trên nên yêu cầu người vận hành bên ngoài nhóm. Toán tử chỉ cần thiết để thiết lập quyền, tạo bản sao và như vậy.

Đừng bận tâm "thực hành tốt nhất" (chịu đựng với tôi) đây là một vấn đề quản lý - về cơ bản, bạn không thể thực hiện công việc của mình đúng cách vì những ràng buộc đặt ra cho bạn.

Nó thực sự không quan trọng "thực tiễn tốt nhất" là gì - đây là một vấn đề đơn giản, có thể chứng minh được, nó sẽ ảnh hưởng đến năng suất của bạn và nhóm của bạn và bạn cần phải xử lý vấn đề này trên cơ sở đó.

Tôi có thể thấy rằng vung một tài liệu thực hành tốt nhất có thể (nhưng chỉ có thể ) là một sự trợ giúp trong việc cố gắng thuyết phục họ nhưng tốt hơn nhiều là khái niệm rằng bạn sẽ phải có các thành viên nhóm dev ngồi trên tay trong khi chờ đợi ai đó ở múi giờ khác để có được hành động của họ với nhau trừ khi các quy trình được cải thiện / hợp lý hóa.

Và đừng quá đối đầu - nhiều như bất cứ điều gì bạn muốn biết tại sao lại có những hạn chế, lý do là gì ...