Mẹo về quản lý phụ thuộc cho bản phát hành?

Question

Hệ thống của chúng tôi bao gồm nhiều trang web .NET, thư viện lớp và cơ sở dữ liệu MSSQL. Chúng tôi sử dụng SVN để kiểm soát nguồn và TeamCity để tự động xây dựng đến một máy chủ thử nghiệm.

Nhóm của chúng tôi thường làm việc trên 4 hoặc 5 dự án cùng một lúc. Chúng tôi cố gắng thực hiện nhiều thay đổi trong một bản giới thiệu khổng lồ mỗi 2-4 tuần.

Vấn đề của tôi là theo dõi tất cả các phụ thuộc cho giới thiệu. Ví dụ:

Trang web A không thể phát trực tiếp cho đến khi chúng tôi triển khai Thư viện X của lớp B, được xây dựng dựa vào thư viện Trunk of Class C, cần cập nhật Config Y và Z và Database Update D, cần Migration Script E ...

Nó trở nên phức tạp hơn - như đảm bảo dự án của mỗi nhà phát triển thực sự tương thích với những người khác và đang xây dựng dựa trên cùng một phiên bản. Vâng, đây là vấn đề về quản lý cũng như vấn đề kỹ thuật.

Hiện nay giải pháp không tối ưu của chúng tôi là:

• một Bảng tính năng danh sách chưa đi vào vận hành chưa
• dựa vào bộ nhớ và trực giác của chúng tôi khi lập kế hoạch việc triển khai, cho đến khi chúng tôi khá chắc chắn chúng tôi đã nghĩ về mọi thứ ...
• sự kiện chạy khô trên môi trường Dàn dựng của chúng tôi. Đó là một dấu hiệu tốt nhưng chúng tôi thường không chắc liệu Staging có đồng bộ 100% với Live - một phần của vấn đề mà tôi hy vọng sẽ giải quyết hay không.
• một số tiền được trang trí vào ngày phát hành.

Cho đến giờ rất tốt, trừ đi một số cuộc gọi gần. Nhưng khi hệ thống của chúng tôi phát triển, tôi muốn một hệ thống quản lý phát hành khoa học hơn cho phép linh hoạt hơn, như có thể triển khai một sự thay đổi hoặc sửa lỗi đơn lẻ, an toàn trong kiến ​​thức rằng nó sẽ không làm hỏng bất cứ thứ gì khác.

Tôi đoán giải pháp tốt nhất liên quan đến một số loại hệ thống đánh số phiên bản và có thể sử dụng công cụ quản lý dự án. Chúng tôi là một khởi nghiệp, vì vậy chúng tôi không quá nóng về tôn giáo gắn bó với các quá trình cứng nhắc, nhưng chúng tôi rất vui để bắt đầu, cung cấp nó không thêm chi phí nhiều hơn giá trị của nó.

Tôi rất muốn nghe lời khuyên từ các nhóm khác đã giải quyết vấn đề này.

Answer 1

Có vẻ như bạn đã có Máy chủ tích hợp Continuos tại chỗ, nhưng không sử dụng đúng cách. Một phần của vấn đề là bạn không biết những thay đổi nào sẽ kết thúc trong bản phát hành và điều này sẽ không xảy ra.

Tôi cho rằng tất cả các dự án của bạn là một phần của dự án bao trùm, nơi tồn tại kho kiểm soát nguồn. Như là một biện pháp đầu tiên, bạn nên cố gắng tách mã của bạn theo phát triển so với mã được phát hành ổn định/được phát hành trong các chi nhánh. Thiết lập Teamcity để tạo toàn bộ chi nhánh ổn định thường xuyên. Nếu một tập hợp các thay đổi đã sẵn sàng để phát hành, người tạo ra thay đổi phải chịu trách nhiệm sáp nhập chúng, cùng với tất cả các phụ thuộc, trong nhánh ổn định. CI sẽ cho bạn biết nếu mọi thứ suôn sẻ hay không. Đó là ý tưởng của CI rằng bạn "luôn sẵn sàng cho việc phát hành".

Bạn đã đề cập rằng có một số dự án nhóm của bạn liên tục làm việc và họ có một số phụ thuộc lẫn nhau nhất định.Điều này khiến tôi hơi nghi ngờ:

• Nếu các dự án là phụ thuộc lẫn nhau, tại sao chúng lại tách biệt? Ngay cả khi chúng phát triển ở các tốc độ khác nhau, chúng có thực sự cần phải tách biệt không?
• Do đó, bạn có các kho lưu trữ khác nhau cho từng dự án không? Điều này sẽ làm cho việc phát hành thực sự khó khăn.
• Phụ thuộc có thể được quản lý ở cấp nhị phân không? Hoặc có phụ thuộc thời gian biên dịch?

Theo kinh nghiệm của tôi, việc quản lý phụ thuộc ở cấp nhị phân luôn dễ dàng hơn (chỉ cần nâng cấp thư viện trong dự án của bạn). Mặt khác, tôi đã không bao giờ có tình huống mà các dự án không liên quan phụ thuộc vào cùng một dll (mà là một ứng dụng trong chính nó và không chỉ là một thư viện tiện ích hoặc một cái gì đó). Trong trường hợp này, việc quản lý các phụ thuộc ở cấp nguồn dễ dàng hơn.

Cuối cùng, một ý nghĩ ngẫu nhiên: Nếu bạn sử dụng hệ thống điều khiển phiên bản phân tán (như git hoặc mercurial), có tất cả mã trong cùng một kho lưu trữ sẽ rất dễ dàng. Mỗi dự án có thể có nhánh riêng, được cập nhật thường xuyên với những thay đổi mới nhất từ ​​nhánh chính (tích hợp chuyển tiếp). Khi thay đổi hoàn tất, nhánh dự án được sáp nhập trở lại vào nhánh chính (tích hợp ngược). Nhóm Windows tại Microsoft đã đưa ra quy trình làm việc này.