Phương pháp phát triển khi hàng trăm nhà phát triển đang làm việc trên một giải pháp duy nhất?

Chúng tôi là một tổ chức bao gồm khoảng 200 nhà phát triển đang làm việc liên tục trên một sản phẩm duy nhất (sử dụng Git kiểm soát sửa đổi) dự kiến ​​sẽ được phát hành vào một ngày nhất định.

Do số lượng lớn các nhà phát triển, chúng tôi đang cố gắng tạo các nhóm "đa chức năng" với khoảng 10 nhà phát triển trong mỗi nhóm, dẫn đến khoảng 20 nhóm phát triển trong tổ chức.

Vì chúng tôi muốn duy trì "tiêu chuẩn cao" liên tục (có nghĩa là khi nhà phát triển thực hiện thao tác kéo, ít nhất sản phẩm phải có thể biên dịch được, v.v.) của sản phẩm trong kho lưu trữ chính, chúng tôi muốn sử dụng một số loại cổng chất lượng.

Tôi hơi không chắc chắn làm thế nào để diễn đạt câu hỏi, nhưng tôi tự hỏi liệu tôi có thể nhận được một số lời khuyên về phương pháp phát triển cho một nhóm lớn các nhà phát triển làm việc trên một sản phẩm không.

Theo chúng tôi, một đầu của phổ là cho phép mỗi nhà phát triển cam kết trực tiếp với kho lưu trữ chính, tuy nhiên chúng tôi lo ngại rằng do số lượng lớn các nhà phát triển / cam kết rằng "kho lưu trữ chính" có thể liên tục bị phá vỡ, do để chúng tôi không thể có một "cổng chất lượng" đòi hỏi cho mỗi cam kết.

Đầu kia của quang phổ có thể giống như (chúng tôi nghĩ Linus Torvalds / Linux làm điều đó) một cấu trúc cây hoặc kim tự tháp, trong đó "kho lưu trữ chính" chỉ có ba nguồn kéo, ba nguồn này chỉ có một số nguồn kéo đáng tin cậy, v.v. Tuy nhiên, chúng tôi cảm thấy rằng với một cấu trúc như vậy, những thay đổi đó có một chuỗi dài để leo lên để đi vào "kho lưu trữ chính". Thêm vào đó, nếu xảy ra xung đột hợp nhất, vấn đề sẽ thuộc về nhà phát triển khác ngoài "nhà phát triển ban đầu".

Với tất cả thông tin cơ bản và ý kiến ​​đã nêu, làm thế nào chúng ta có thể tìm hiểu và đọc các phương pháp phát triển được đề xuất cho rất nhiều nhà phát triển? Làm thế nào để các tổ chức lớn (Microsoft, Facebook, Ubuntu, v.v.) cấu trúc sự phát triển của họ?

Bạn chắc chắn nên xem xét việc chia sản phẩm thành các mô-đun với (các) nhóm giao diện để đưa các mô-đun cấu thành đó lại với nhau thành một sản phẩm. Đến lượt điều này có nghĩa là chia các kho lưu trữ để phù hợp với phân vùng và phân cấp mô-đun. Nếu có vẻ như bạn không thể làm điều này thì dự án có thể sẽ bị đình trệ do hợp nhất khi xem xét số lượng nhà phát triển đóng góp.

Nếu bạn đang dự định sử dụng Git để kiểm soát phiên bản thì tôi khuyên bạn nên sử dụng hệ thống đánh giá mã (như Gerrit ) để cải thiện tính minh bạch và đảm bảo chất lượng cho từng kho lưu trữ. Bằng cách đó, tất cả các công việc sẽ phải được phê duyệt trước khi được sáp nhập vào bất kỳ kho lưu trữ có thẩm quyền. Trong kịch bản này, sẽ hợp lý khi cấp một số quyền cá nhân đáng tin cậy để chuyển từ repo theo hệ thống đánh giá mã sang kho lưu trữ khác (cũng có thể theo hệ thống đánh giá mã). Nếu được sử dụng đúng cách, đây sẽ là một quá trình nhanh chóng và có lợi rất nhiều, không cản trở quá trình phát triển.

Về xác minh bản dựng, bạn sẽ cần một máy chủ tích hợp liên tục (CI) với mục đích là tự động xây dựng và xác minh mã. Bằng cách xác minh mã, tôi có nghĩa là mã biên dịch thành công và kiểm tra vượt qua. Infact Jenkins (CI Server) có thể được liên kết với hệ thống đánh giá mã Gerrit như một phần của giai đoạn xác minh Gerrit , tự động hóa hoàn toàn quy trình.

Ngoài các công cụ tích hợp này, điều quan trọng là phải cố gắng tích hợp thường xuyên như một phần của phương pháp phát triển, để giảm thiểu thời gian hợp nhất.

Có thể đáng để xem xét một quy trình phát triển Agile như Scrum với mục đích là phá vỡ một sản phẩm phức tạp thành các phần có thể quản lý được của việc tăng sản phẩm (được gọi là Sprints). Chúng sẽ cung cấp cơ hội tích hợp giữa các kho lưu trữ.

Rõ ràng, với một nhóm phát triển 200 người, bạn phải có một số loại cấu trúc phân cấp. Một cá nhân hoặc một nhóm nhỏ đang đưa ra quyết định về thiết kế sản phẩm phần mềm. Quá trình phát triển của bạn sẽ phản ánh điều này: bạn cần đánh giá và kiểm tra mã để đảm bảo phần mềm được tạo thực sự phù hợp với những gì bạn muốn tạo (cũng như cho mục đích chất lượng).

Ngay cả các nhóm nhỏ cũng cần các nhà lãnh đạo để hướng dẫn các nhóm và xem xét công việc của họ khi họ phát triển các thành phần riêng lẻ. Họ cũng nên có các quy trình kiểm soát chất lượng tại chỗ ở cấp độ nhóm.

Vì vậy, có, bạn nên theo một cấu trúc phân cấp liên quan đến kho lưu trữ. Điều này là để phù hợp với cấu trúc phân cấp của tổng thể dự án.

Các thành phần riêng lẻ nên được xây dựng và thử nghiệm ở một mức độ phù hợp nhất định trước khi bạn nghĩ đến việc kết hợp tất cả chúng lại với nhau. Cho phép 200 người cam kết trực tiếp vào dự án chính sẽ là hỗn loạn. Bạn nên có các khu vực riêng cho từng nhóm nơi các cá nhân có thể cam kết thay đổi hàng ngày, mà không ảnh hưởng đến việc xây dựng chính của dự án.

Đó là một điều rất tốt nếu "các thay đổi có một chuỗi dài để leo lên để vào kho chính" bởi vì chuỗi này cho phép bạn đảm bảo chất lượng. Nó có vẻ nhanh hơn nếu tất cả các thay đổi ngay lập tức áp dụng cho kho lưu trữ chính, nhưng thực tế điều này sẽ chỉ là một vấn đề đau đầu, vì bạn sẽ có một bản dựng chính liên tục bị lỗi và không thể sử dụng được.

Một điều tốt là "nếu xảy ra xung đột hợp nhất, vấn đề sẽ xảy ra với một nhà phát triển khác" - cụ thể, một nhà phát triển cấp cao hơn sẽ là người quyết định cách giải quyết xung đột.

Khi bạn có một cái gì đó lớn và (do hậu quả) không thể quản lý được, lối thoát là chia nó thành những phần nhỏ hơn và có thể quản lý được.

Có một số bước sẽ giúp bạn duy trì nhóm và dự án tốt hơn:

1. phân chia chức năng thành các mô-đun. Các chức năng nên được chia thành các mô-đun tối đa độc lập bằng cách sử dụng các nguyên tắc đảo ngược cao, khớp nối thấp và phụ thuộc. Nguyên tắc đầu tiên sẽ giúp bạn tạo các mô-đun nhất quán hợp lý. Cái thứ hai sẽ giúp giữ cho các mô-đun này độc lập nhất có thể. Cái thứ ba sẽ giúp phát triển các mô-đun phụ thuộc đồng thời (nếu mô-đun A phụ thuộc vào mô-đun B, B sẽ cung cấp giao diện mà A có thể sử dụng ngay cả khi B chưa hoàn toàn sẵn sàng).

2. có tài liệu rõ ràng. Khi có rất nhiều người làm việc cùng nhau, mọi thứ có thể dễ dàng bị lãng quên hoặc hiểu lầm. Vì vậy, bạn cần đặc biệt chú ý đến tất cả các tài liệu từ yêu cầu đến giải pháp kiến ​​trúc.

3. người cho nhiệm vụ (không bao giờ nhiệm vụ cho người). Sau khi chia chức năng thành các bộ nhỏ hơn, hãy tạo các nhóm để làm việc trên các bộ này. Tạo nhóm sẽ dễ dàng hơn trong giai đoạn này, bởi vì bạn đã biết mỗi nhóm sẽ làm việc trên cái gì. Và các nhiệm vụ như đánh giá mã sẽ được thực hiện trong mỗi nhóm.

4. hệ thống nhiệm vụ rõ ràng. Mỗi trong số 200 nhà phát triển nên biết rõ phải làm gì. Điều này sẽ giúp bạn theo dõi những gì đã được thực hiện, mỗi người đang làm gì và còn lại bao nhiêu công việc.

5. kiểm soát nguồn. (Tôi nghĩ rằng điều này được nêu trong các câu trả lời khác khá tốt)))

Và cuối cùng, hãy cố gắng tạo ra một cấu trúc đơn giản gồm các nhóm và mô-đun càng tốt. Bạn không thể đủ khả năng phức tạp với một dự án lớn như vậy.

Ngoài các câu trả lời khác gợi ý cấu trúc phân cấp: ngụ ý rằng bạn sẽ phải lên lịch cho các điểm 'tích hợp' trong thời gian tập trung hoàn toàn vào việc di chuyển mã lên trong cấu trúc phân cấp và 'kết hợp tất cả lại với nhau'. Điều này không khác nhiều so với các dự án nhỏ hơn với giai đoạn cuối mà không có công việc nào khác được thực hiện ngoài việc kiểm tra và sửa lỗi, chỉ thường xuyên hơn. Vì bạn đang làm việc trong một nhóm lớn phấn đấu cho các tiêu chuẩn cao, hầu hết điều đó (khung của tâm trí) có thể sẽ được áp dụng.

Ngoài câu trả lời của hotpotato (trực tiếp trên nhãn IMHO), tôi cũng đề nghị thực hiện một số cổng kiểm soát nguồn, như bạn đề xuất. Khi chúng tôi chuyển một nhóm lớn và cơ sở mã sang git cho SCM, chúng tôi đã quyết định sử dụng phương pháp được gọi là "nhà độc tài nhân từ", tương tự như mô hình mà bạn mô tả.

Trong kịch bản này, có rất nhiều nhánh khác nhau của cơ sở mã đầy đủ được cập nhật thường xuyên từ nhánh nguồn của họ, nhưng trách nhiệm quảng bá mã vào các khu vực công cộng / dễ thấy hơn nằm ở một người (hoặc một nhóm nhỏ), và thường là gắn liền với một quá trình xem xét mã. Với một cấu trúc phân nhánh được tổ chức tốt, điều này có thể hoạt động thực sự tốt. Để biết thêm thông tin, hãy kiểm tra liên kết này .

Tôi đã làm việc trên một hệ thống khổng lồ có hàng trăm nhà phát triển làm việc cùng lúc với khoảng 150 triệu SLOC. Đây là trên một máy tính lớn, vì vậy chúng tôi không nói về Visual Studio, nhưng các nguyên tắc vẫn có thể được áp dụng.

Trước hết, nếu bạn đang sử dụng Java, tôi chắc chắn sẽ nói sử dụng Maven. Nếu bạn đang sử dụng VS, bạn cũng có thể sử dụng Nuget mặc dù tôi không chắc chắn liệu nó có ở đó với Maven hay không (nó cũng hơi khác một chút). Sử dụng một hệ thống như thế này sẽ cho phép bạn kéo các phụ thuộc của mình và cho phép chúng hoạt động riêng lẻ. Bạn sẽ có một tập lệnh xây dựng kéo các phụ thuộc có liên quan và xây dựng theo lô.

Cho rằng bạn không trực tiếp hỏi một câu hỏi nhưng hỏi về phương pháp luận, tôi sẽ cho bạn biết chủ nhân trước đây của tôi đã xử lý nó như thế nào.

Hệ thống được chia thành các cụm . Các cụm đại diện cho khu vực kinh doanh và khu vực cơ sở hạ tầng hệ thống. Tôi sẽ không đặt tên cho chúng, nhưng đối với một doanh nghiệp bán lẻ khổng lồ, bạn có thể nghĩ đến những thứ như tiếp thị, hoạt động bán lẻ, hoạt động trực tuyến, mua sắm, phân phối. Cơ sở hạ tầng hệ thống đại diện cho những thứ như khách hàng và bảo mật. Trong mỗi cụm, có các thành phần . Sử dụng sự tương tự trước đó, bạn có thể xem xét các thành phần bảo mật chẳng hạn - đăng nhập một lần, dịch vụ thư mục, kiểm toán, báo cáo, v.v ... Mỗi thành phần có các thói quen tương đối được lưu trữ trong đó.

Như một không gian tên hoặc gói bạn có Organisation.Security.DirectoryService chẳng hạn. Bằng cách chứa tất cả logic cho các khu vực liên quan của nó, các nhóm làm việc khá tự chủ. Rõ ràng các dự án lớn yêu cầu đầu vào từ nhiều nhóm đã xảy ra nhưng chúng chủ yếu hoạt động trơn tru.

Tôi hi vọng cái này giúp được.