Chiến lược phân nhánh và phiên bản cho các thư viện dùng chung

Những bài đăng này có vẻ liên quan, nhưng bộ não của tôi bắt đầu tan chảy, cố gắng nghĩ điều này thông qua: P

Chủ nhân của tôi mới bắt đầu sử dụng kiểm soát nguồn, chủ yếu vì trước khi họ thuê thêm nhà phát triển, "kho lưu trữ" là ổ cứng của nhà phát triển đơn độc, người làm việc chủ yếu ở nhà. Tất cả các mã .NET mà anh ấy đã viết đã được kiểm tra trong en masse và có rất nhiều chức năng trùng lặp (đọc: sao chép-dán). Ngay bây giờ, hệ thống SCM của chúng tôi được sao lưu vinh quang.

Tôi muốn kéo một số mã trùng lặp vào các thư viện dùng chung. Tôi đang để lại repo ban đầu một mình để chúng tôi không phá vỡ bất cứ thứ gì mà chúng tôi có thể di chuyển và / hoặc cấu trúc lại mã hiện có khi cần. Vì vậy, tôi đã thiết lập một repo chỉ cho mã mới, bao gồm các thư viện.

Vấn đề của tôi xoay quanh việc phiên bản các thư viện mà không làm chúng tôi ngạc nhiên trong quá trình: thừa nhận rằng chúng tôi cần một cách tiếp cận mạch lạc hơn, với nhiều nhà phát triển hơn viết mã rất giống nhau, quản lý và các nhà phát triển khác mở để sắp xếp lại mọi thứ, nhưng có lẽ sẽ không đi xuống tốt nếu giải pháp bắt đầu ảnh hưởng đến năng suất.

Giải pháp lý tưởng trong tâm trí ám ảnh của tôi là xây dựng các thư viện riêng biệt, với mỗi dự án phụ thuộc được xây dựng dựa trên các phiên bản tương thích được lựa chọn có chủ ý của chúng. Bằng cách đó, chúng tôi biết chính xác khách hàng nào có phiên bản thư viện nào, có thể tái tạo các lỗi một cách đáng tin cậy hơn, duy trì các nhánh phát hành độc lập cho các sản phẩm và thư viện và không phá vỡ các dự án của nhau khi thay đổi mã chia sẻ.

Điều này làm cho việc cập nhật các thư viện trở nên cồng kềnh, đặc biệt là đối với các nhà phát triển làm việc tại nhà. Tôi hy vọng các thư viện sẽ thay đổi nhanh chóng, ít nhất là ban đầu khi chúng tôi (cuối cùng) kéo các bit chung lại với nhau. Hoàn toàn có thể là tôi đã hoàn toàn đánh giá cao điều này và chúng tôi sẽ ổn khi xây dựng mọi thứ dựa trên các cam kết thư viện gần đây nhất, nhưng ít nhất tôi muốn chuẩn bị cho ngày chúng tôi quyết định rằng một số thành phần phải được phiên bản độc lập và phân phối. Việc một số thư viện sẽ phải được cài đặt trong GAC làm cho phiên bản trở nên đặc biệt quan trọng.

Vì vậy, câu hỏi của tôi là: tôi đang thiếu gì? Tôi cảm thấy như tôi đã sửa chữa một giải pháp và hiện đang cố gắng tìm các biến thể trên đó sẽ giúp thay đổi mượt mà hơn. Những loại chiến lược nào bạn đã sử dụng để giải quyết loại vấn đề này trước đây? Tôi nhận ra câu hỏi này ở khắp mọi nơi; Tôi sẽ làm hết sức mình để dọn dẹp và làm rõ bất kỳ điểm không chắc chắn nào.

Và cũng như tôi rất thích sử dụng Mercurial, chúng tôi đã chi tiền cho một SCM thương mại tập trung (Vault) và chuyển đổi không phải là một lựa chọn. Bên cạnh đó, tôi nghĩ vấn đề ở đây đi sâu hơn sự lựa chọn công cụ kiểm soát phiên bản.

Tôi khen ngợi sáng kiến ​​của bạn. Điều này sẽ mang lại một số lợi ích cho tổ chức khi bạn thực hiện điều này. Tôi sẽ di chuyển mã chứ không phải sao chép nó. Có bản sao sẽ có khả năng dẫn đến những thay đổi không tương thích sẽ cần phải được giải quyết.

Sẽ có một số đau đớn khi các thư viện được phát triển và ổn định. Một khi điều đó được thực hiện, lợi ích sẽ đến. Hãy nhớ rằng các giao diện đến thư viện về cơ bản là một hợp đồng với các dự án làm việc với hợp đồng. Bạn có thể có lợi thế trong việc loại bỏ các giao diện cũ vì bạn có thể xác định xem chúng có được sử dụng không.

Trong khi các thư viện đang ổn định, việc nhận các thư viện mới có lẽ là một phần của quá trình cập nhật mã. Bạn có thể muốn lên lịch cam kết thay đổi thư viện. Thông báo mã được di chuyển có thể giúp giảm các thay đổi xung đột.

Các thư viện nên được coi là các dự án riêng biệt và ổn định càng sớm càng tốt. Khi chúng được ổn định (đặc biệt là các giao diện), việc tích hợp các thay đổi với các dự án khác sẽ dễ dàng hơn. Thư viện mới nên làm việc với mã cũ. Tag phát hành thư viện ổn định với id phát hành riêng của họ. Cố gắng đối xử với các thư viện như thư viện của bên thứ ba.

Mã được chia sẻ giữa các dự án phải được coi là dự án trên chính chúng. Chúng phải được đối xử với sự kỹ lưỡng giống như các thư viện của bên thứ ba. Không có cách nào khác.

Nếu bạn không thể khiến nhóm của mình áp dụng chiến lược cho mã được chia sẻ, bạn có thể tự mình áp dụng một chiến lược với sự trợ giúp của các công cụ quản lý mã nguồn hiện đại như Mercurial hoặc GIT, ngay cả khi SCM của công ty bạn sẽ không sử dụng chính thức. Với một chút cẩn thận, hai SCM có thể sử dụng cùng một thư mục công việc chỉ bằng cách yêu cầu một người bỏ qua các tệp bên trong của người kia. Bạn sẽ sử dụng một SCM để đối phó với công việc hàng ngày và công ty để tích hợp.

Ở bất kỳ giá nào, bạn phải chịu trách nhiệm khi cập nhật thư mục làm việc của mình với các sửa đổi mà các dự án khác đã thực hiện đối với mã được chia sẻ. Những điều đó chỉ xảy ra khi bạn sẵn sàng đối phó với sự không tương thích có thể phát sinh; nếu không, công việc của bạn có thể trở nên không ổn định ngoài khả năng.

Nếu bạn có khả năng chia chúng thành các dự án "mô-đun" riêng biệt, tôi sẽ thực hiện phương pháp đó. Một điều cần quan tâm là ghép mã. Bạn sẽ tạo ra một sự tách biệt các mối quan tâm bằng cách phá vỡ chúng, đó là một thực hành tốt.

Một số lợi ích:

1. Gỡ lỗi đơn giản hơn của mỗi mô-đun.
2. Chu kỳ xây dựng nhanh hơn (không xây dựng lại các thư viện không thay đổi)
3. Khi một cái gì đó hoạt động, bạn ít có khả năng phá vỡ nó bằng cách thay đổi một khu vực khác bên ngoài mô-đun đó (không phải 100%, nhưng bạn giảm cơ hội).
4. Dễ dàng hơn để phá vỡ các bài tập công việc nếu nó không phải là một mớ hỗn độn phụ thuộc lớn.
5. Phân phối nhanh hơn các phần nhỏ hơn khi bạn sửa một thư viện (một lý do lớn tại sao bạn có tệp dll / .so).

Tôi có một câu hỏi về phần này:

"Giải pháp lý tưởng trong tâm trí ám ảnh của tôi là xây dựng các thư viện riêng biệt, với mỗi dự án phụ thuộc được xây dựng dựa trên các phiên bản tương thích được lựa chọn có chủ ý của chúng."

Bạn có liên kết tĩnh toàn bộ dự án? Nếu vậy, điều này sẽ dẫn đến: 6. Giảm sự phình mã không cần thiết.

Một số tiêu cực:

1. Nếu dự án nhỏ, thì bạn chỉ cần thêm độ phức tạp vào nơi không cần thiết.
2. Việc phân nhánh nhiều mô-đun có thể biến thành vấn đề bảo trì cho các dự án thực sự lớn. Tôi không biết "Vault", vì vậy tôi không chắc hoạt động phân nhánh của họ là tốt hay xấu.

Ngay bây giờ, có vẻ như bạn có một cơ sở mã được xây dựng cùng một lúc vào một mục tiêu. Bạn có thể có không quá năm nhà phát triển. Tôi thực sự không thấy tiện ích của việc tách các thư viện quá nhiều. Bạn sẽ thay đổi quy trình làm việc của mình từ mã -> biên dịch -> chạy sang mã -> biên dịch -> sao chép DLL -> biên dịch -> chạy ... ick.

Một số công ty (Google và Amazon) có đủ cơ sở hạ tầng để phát triển mà không có nhiều thư viện riêng biệt được xây dựng riêng. Cơ sở hạ tầng để làm cho nó không đau đớn liên quan đến cách chỉ định các phiên bản thư viện sống trong SCM của bạn (mà bạn có thể có), một cách để chỉ định các phiên bản phụ thuộc sống trong SCM của bạn, một máy chủ xây dựng có thể hiểu ý nghĩa của nó và biên dịch mọi thứ chính xác và một cách để lấy các tạo phẩm xây dựng phù hợp từ máy chủ xây dựng của bạn và từ không gian làm việc cục bộ của bạn. Tôi nghi ngờ bạn có điều đó.

Không có cơ sở hạ tầng đó, tôi sẽ tách dự án khi một trong những điều sau đây được áp dụng:

• Bạn có nhiều sản phẩm hoặc ứng dụng riêng biệt tùy thuộc vào thư viện này
• Bạn làm việc độc quyền trên các thư viện này trong nhiều ngày
• Chức năng của thư viện cực kỳ tách biệt với mọi thứ liên quan đến kinh doanh (ví dụ: trình bao bọc xung quanh API dành riêng cho nền tảng)
• Thời gian xây dựng cho dự án kết hợp tăng quá lớn

Tôi lo lắng về việc xây dựng cơ sở hạ tầng đó khi bạn có nhiều dự án và một số có nhà phát triển chuyên dụng và chu kỳ phát hành độc lập.

Những gì bạn có thể và nên làm bây giờ là thiết lập một máy chủ xây dựng cho các bản dựng đáng tin cậy, có thể lặp lại và đảm bảo rằng bạn có thể tìm thấy bản sửa đổi nguồn từ một tệp thực thi nhất định. Bạn dường như đang sử dụng .NET; Thật đơn giản để thiết lập CruiseControl.NET để chèn một chuỗi phiên bản, bao gồm cả số sửa đổi.

Khi bạn có một máy chủ xây dựng, việc tách ra một thư viện sẽ là vấn đề di chuyển nó trong Vault, thêm một mục tiêu khác trong CC.NET và sao chép DLL kết quả vào thư mục thư viện của dự án chính của bạn và cam kết nó. Về phía SCM dễ dàng hơn so với phát triển hàng ngày.

Mercurial có một tính năng gọi là tiểu khu. Gần đây tôi đã đọc blog này từ Kiln giải thích cách họ làm việc.

Về cơ bản, bạn liên kết dự án của bạn với một phiên bản cụ thể của kho lưu trữ thư viện. Bạn có thể cập nhật thư viện nhiều như bạn muốn mà không phá vỡ các dự án phụ thuộc. Khi bạn đã sẵn sàng, bạn có thể đưa các tính năng mới của thư viện vào dự án của bạn và xử lý mọi sự cố. Các dự án khác nhau có thể liên kết đến các phiên bản khác nhau của thư viện, vì vậy tất cả chúng không phải đồng bộ hóa và sử dụng cùng một phiên bản thư viện.

Có lẽ Vault có một tính năng tương tự.

Chúng tôi đã thêm một tệp siêu dữ liệu vào mỗi mô-đun trong SC cho biết tên của tất cả các mô-đun khác mà nó phụ thuộc. Một sản phẩm sẽ có tệp siêu dữ liệu thứ hai cho biết phiên bản nào của mỗi mô-đun phụ thuộc được yêu cầu cho sản phẩm. Trên hết, đây là một công cụ để phân tích các tệp siêu dữ liệu, kiểm tra tất cả các mô-đun cần thiết và tạo một dự án cho IDE của chúng tôi.

Điều này đảm bảo các bản dựng của chúng tôi luôn có thể tái tạo và các tệp tiêu đề chính xác luôn được chia sẻ giữa các thành phần. Sự phức tạp khác có thể được xếp lớp khi nhu cầu phát triển. Chúng tôi có các công cụ hiện có thể tạo báo cáo về sự khác biệt giữa bất kỳ hai bản dựng sản phẩm nào, chỉ định các tệp nguồn đã thay đổi, nhận xét đăng ký, nhận xét phiên bản, tác giả, trên tất cả các mô-đun độc lập trong SC. Chúng tôi nhận được một lượng tái sử dụng phi thường từ cơ sở mã của chúng tôi.