Chu kỳ phát hành công ty kỳ quặc: Kiểm soát nguồn phân tán?


13

Xin lỗi về bài viết dài này, nhưng tôi nghĩ rằng nó là giá trị nó.

Tôi mới bắt đầu với một cửa hàng .NET nhỏ hoạt động khá khác biệt so với những nơi khác mà tôi đã làm việc. Không giống như bất kỳ vị trí nào trước đây của tôi, phần mềm được viết ở đây được nhắm mục tiêu đến nhiều khách hàng và không phải mọi khách hàng đều nhận được bản phát hành phần mềm mới nhất cùng một lúc. Như vậy, không có "phiên bản sản xuất hiện tại." Khi một khách hàng nhận được bản cập nhật, họ cũng nhận được tất cả các tính năng được thêm vào phần mềm kể từ lần cập nhật cuối cùng của họ, có thể là một thời gian dài trước đây. Phần mềm có cấu hình cao và các tính năng có thể được bật và tắt: được gọi là "tính năng bật tắt". Các chu kỳ phát hành rất chặt chẽ ở đây, trên thực tế chúng không theo lịch trình: khi một tính năng hoàn tất, phần mềm được triển khai cho khách hàng có liên quan.

Nhóm chỉ mới năm ngoái đã chuyển từ Visual Source Safe sang Team Foundation Server. Vấn đề là họ vẫn sử dụng TFS như thể đó là VSS và thực thi các khóa Checkout trên một nhánh mã. Bất cứ khi nào sửa lỗi được đưa ra hiện trường (ngay cả đối với một khách hàng), họ chỉ cần xây dựng bất cứ thứ gì có trong TFS, kiểm tra lỗi đã được sửa và triển khai cho khách hàng! (Bản thân tôi đến từ một nền tảng phần mềm dược phẩm và thiết bị y tế, điều này là không thể tin được!). Kết quả là một nửa mã dev nướng được đưa vào sản xuất mà không được kiểm tra. Lỗi luôn rơi vào các bản dựng phát hành, nhưng thường thì một khách hàng mới có bản dựng sẽ không thấy các lỗi này nếu họ không sử dụng tính năng của lỗi. Giám đốc biết đây là một vấn đề vì công ty đang bắt đầu phát triển bất ngờ với một số khách hàng lớn đến trên tàu và những khách hàng nhỏ hơn.

Tôi đã được yêu cầu xem xét các tùy chọn kiểm soát nguồn để loại bỏ việc triển khai mã lỗi hoặc chưa hoàn thành nhưng không hy sinh bản chất có phần không đồng bộ của các bản phát hành nhóm. Tôi đã sử dụng VSS, TFS, SVN và Bazaar trong sự nghiệp của mình, nhưng TFS là nơi mà hầu hết kinh nghiệm của tôi đã có.

Trước đây, hầu hết các nhóm tôi đã làm việc với việc sử dụng giải pháp hai hoặc ba nhánh của Dev-Test-Prod, trong đó một tháng các nhà phát triển làm việc trực tiếp trong Dev và sau đó các thay đổi được hợp nhất với Test rồi Prod hoặc quảng bá "khi hoàn thành" thay vì trên một chu kỳ cố định. Các bản dựng tự động đã được sử dụng, sử dụng Cruise Control hoặc Team Build. Trong công việc trước đây của tôi, Bazaar đã được sử dụng ngồi trên SVN: các nhà phát triển làm việc trong các nhánh tính năng nhỏ của riêng họ sau đó đẩy các thay đổi của họ sang SVN (được gắn vào TeamCity). Điều này thật tuyệt khi dễ dàng tách biệt các thay đổi và chia sẻ chúng với các chi nhánh của người khác.

Với cả hai mô hình này, có một nhánh trung tâm và prod (và đôi khi là thử nghiệm) thông qua đó mã được đẩy (và các nhãn được sử dụng để đánh dấu các bản dựng trong prod từ đó phát hành ... và chúng được tạo thành các nhánh để sửa lỗi để phát hành và sáp nhập trở lại dev). Điều này không thực sự phù hợp với cách làm việc ở đây, tuy nhiên: không có thứ tự nào khi các tính năng khác nhau được phát hành, chúng sẽ được đẩy khi chúng hoàn thành.

Với yêu cầu này, cách tiếp cận "tích hợp liên tục" như tôi thấy nó bị phá vỡ. Để có được một tính năng mới với sự tích hợp liên tục, nó phải được đẩy qua dev-test-prod và điều đó sẽ nắm bắt bất kỳ công việc còn dang dở nào trong dev.

Tôi nghĩ rằng để khắc phục điều này, chúng ta nên đi xuống một mô hình phân nhánh nhiều tính năng với các nhánh KHÔNG-test-prod, thay vào đó, nguồn nên tồn tại dưới dạng một loạt các nhánh tính năng mà khi công việc phát triển hoàn tất bị khóa, kiểm tra, sửa chữa, khóa , thử nghiệm và sau đó phát hành. Các nhánh tính năng khác có thể lấy các thay đổi từ các nhánh khác khi chúng cần / muốn, vì vậy cuối cùng tất cả các thay đổi sẽ được hấp thụ vào mọi người. Điều này rất phù hợp với mô hình Bazaar thuần túy từ những gì tôi đã trải nghiệm ở công việc cuối cùng.

Linh hoạt như điều này nghe có vẻ kỳ quặc khi không có nhánh dev hoặc nhánh prod ở đâu đó và tôi lo lắng về việc các chi nhánh không bao giờ được tích hợp lại, hoặc những thay đổi nhỏ đã khiến không bao giờ bị kéo sang các chi nhánh và nhà phát triển khác phàn nàn về hợp nhất thảm họa ...

Suy nghĩ của mọi người về điều này là gì?

Câu hỏi cuối cùng thứ hai: Tôi hơi bối rối về định nghĩa chính xác của kiểm soát nguồn phân tán: một số người dường như cho rằng đó là về việc không có kho lưu trữ trung tâm như TFS hoặc SVN, một số người nói rằng nó bị ngắt kết nối (SVN bị ngắt kết nối 90% và TFS có chế độ ngoại tuyến hoàn hảo về chức năng) và những người khác nói rằng đó là về Phân nhánh tính năng và dễ dàng hợp nhất giữa các nhánh không có mối quan hệ cha-con (TFS cũng có sự hợp nhất vô căn cứ!). Có lẽ đây là một câu hỏi thứ hai!


Câu trả lời:


5

Điều gì định nghĩa một DVCS?

Các phân phối trong DVCS phương tiện mà mỗi bản sao của một kho lưu trữ có tất cả các thông tin cần thiết để thực hiện, cập nhật, chi nhánh, hợp nhất hoặc tìm kiếm bất kỳ sửa đổi trong kho đó, mà không bao giờ chạm vào một máy chủ . Điều duy nhất bạn có thể thực hiện ngoại tuyến svnlà thực sự chỉnh sửa các tệp - bạn cần quyền truy cập máy chủ cho hầu hết tất cả svncác lệnh, bao gồm thực hiện một thao tác đơn giản như grepping svn log, vì vậy nó thực sự gần với 0% hơn 90%!

Bất kỳ kho lưu trữ trung tâm có thẩm quyền nào mà bạn có thể thiết lập trong quy trình DVCS chỉ là một bản sao khác và lần duy nhất bạn cần tương tác với nó là khi bạn gỡ xuống các bản cập nhật của người khác hoặc khi bạn đẩy các thay đổi của chính mình để người khác có thể thấy chúng , hầu hết mọi thứ khác có thể được thực hiện ngoại tuyến.

Mô hình phân nhánh nào là phù hợp?

Tôi đã ở trong tình huống bạn đang ở ngay bây giờ. Những hệ thống như vậy có thể là một nỗi đau thực sự nhưng bạn phải hiểu những lý do thực tế mà chúng trở nên như thế này và nhận ra rằng chúng không vượt quá sự cứu chuộc . Nhiều công cụ đã được phát triển có thể giúp quản lý loại phức tạp này .

Trước hết, dù bạn làm gì, đừng cho mọi người thấy mô hình phân nhánh git thành công , nó sẽ chỉ khiến họ bối rối và tắt chúng đi. Thay vào đó, hãy phát triển mô hình của riêng bạn phản ánh quy trình công việc hiện tại của bạn , nhưng giải quyết các vấn đề với quy trình công việc hiện tại của bạn .

Một số tài nguyên mà bạn có thể muốn xem xét bao gồm những thứ như mô đun con git sẽ cho phép các bản phát hành khách hàng khác nhau chỉ định các kết hợp khác nhau của cấu hình khách hàng, mô-đun ứng dụng và thư viện. Một lựa chọn khác là sử dụng hệ thống quản lý bản vá để áp dụng hàng đợi bản vá cụ thể của khách hàng / sản phẩm.

Cả hai tùy chọn này sẽ cung cấp tính linh hoạt, minh bạch và an toàn cao hơn nhiều so với quy trình làm việc hiện tại của bạn và có thể dễ sử dụng hơn so với chiến lược chỉ chi nhánh phức tạp hơn. Tôi chắc chắn muốn tôi có quyền truy cập vào các công cụ này khi tôi ở trong tình huống của bạn.

Để biết thêm thông tin về các tùy chọn này, hãy xem câu trả lời của tôi về Chiến lược để sử dụng kiểm soát phiên bản trên hệ thống mô-đun , Cách sử dụng Kho lưu trữ Subversion bên trong Kho lưu trữ Git? Kiểm soát nguồn / phiên bản cho ứng dụng được sử dụng bởi nhiều công ty .

Cuối cùng, đây thực sự là thứ bạn sẽ phải phát triển với phần còn lại của đội. Nếu bạn có tầm nhìn để đề xuất một cái gì đó hoạt động tốt hơn những gì bạn đã có và có thể mua lại các nhà phát triển đồng nghiệp của bạn, thì bạn sẽ có thời gian dễ dàng hơn nhiều.

Điều quan trọng nhất là cho các đồng nghiệp của bạn thấy những gì bạn đề xuất sẽ giúp cuộc sống của họ dễ dàng hơn . Một khi họ bị thuyết phục, bạn sẽ có cơ hội tốt hơn để quản lý vứt bỏ khoản đầu tư của họ vào TFS và bắt đầu sử dụng một mô hình phù hợp hơn với phương pháp làm việc của bạn.


1
+1 để tìm mô hình phân nhánh git thành công phù hợp với bạn
jcmeloni

1
+1 cho "làm cho cuộc sống của họ dễ dàng hơn". Đây là động lực chính.

5

Thứ nhất, DVCS là một cá nhân đỏ cho các vấn đề bạn gặp phải - công cụ kiểm soát phiên bản đang sử dụng không phải là gốc rễ của các vấn đề phải giải quyết. Có thể có những khía cạnh của các giải pháp DVCS "tốt hơn" so với TFS nhưng không phải là những gì cần phải sửa chữa vào thời điểm này.

Bạn đã xác định rằng bạn cần một cấu trúc phân nhánh hoàn toàn phù hợp với tổ chức của mình - Tôi nghĩ bạn sẽ thấy bạn vẫn còn một thân cây, khi một tính năng hoàn thành, nó sẽ được hợp nhất trở lại vào thân cây và bị đóng lại. Có một số suy nghĩ tốt đẹp về cách bạn thực hiện các phụ thuộc phổ biến quá.

Bạn cũng cần phải làm việc tích hợp liên tục (không có lý do gì để không xây dựng tự động cho từng chi nhánh đang hoạt động để giúp bạn tự tin rằng bạn có thể xây dựng chi nhánh đó và nó vượt qua các bài kiểm tra có liên quan). Tôi không thoải mái khi một cam kết (hoặc ít nhất là "đẩy") không kích hoạt bản dựng cho tôi.

Và bạn cần bắt đầu thử nghiệm tự động ở tất cả các cấp, đặc biệt là kiểm tra đơn vị và kiểm tra tích hợp để bắt đầu giảm khả năng các lỗi mới thoát ra ngoài tự nhiên. Điều cuối cùng này là rất lớn và một cái gì đó tôi vẫn đang vật lộn với nhưng rõ ràng rằng một khi bạn biết bạn có thể xây dựng mọi thứ thì điều này sẽ có giá trị nhất.

Bạn cần kết hợp điều này với việc đảm bảo rằng các gói triển khai của bạn đến từ máy chủ xây dựng của bạn và việc triển khai đó được tự động hóa càng nhiều càng tốt (bạn có thể chuyển từ tạo bản dựng máy chủ sang mã được triển khai trực tiếp với nỗ lực tối thiểu và căng thẳng tối thiểu).

Hmm, tôi giả định rằng có một thiết lập theo dõi vấn đề được sắp xếp tốt ... bạn cũng cần điều đó và để tự tin rằng nó đang được sử dụng đúng cách. Lý tưởng nhất là bạn muốn các ứng dụng trực tiếp của mình phản hồi lại lỗi cho hệ thống này (hoặc để xử lý) tự động.

Cuối cùng, đừng cố gắng giải quyết tất cả các vấn đề của bạn cùng một lúc - xây dựng và kiểm tra dường như là nơi bạn nên tập trung đầu tiên.


Có một phần của tôi đồng ý rằng DVCS cũng có thể là cá trích đỏ: Tôi chắc chắn đồng ý vấn đề là với quy trình nhiều hơn bất cứ điều gì khác. Tôi nghĩ rằng việc tích hợp liên tục có thể là một sự kéo dài ở đây và việc kiểm tra đơn vị sẽ không xảy ra vì nó sẽ được coi là quá nhiều công việc. Codebase dù sao cũng không thể kiểm tra được vì đây là một hệ thống nguyên khối được liên kết chặt chẽ và mọi thứ đều dựa trên các loại rời rạc: không có giao diện.
MrLane

@MrLane - Tôi biết sẽ rất khó để giải thích điều này với mọi người, nhưng kể từ khi tôi bắt đầu phát triển theo cách TDD , tôi ngày càng tin rằng tôi không có thời gian để không viết bài kiểm tra.
Đánh dấu gian hàng

1

Câu hỏi thứ hai dễ hơn và ngắn hơn, vì vậy tôi sẽ cố gắng bắt đầu từ nó

DVCS là hệ thống, trong đó không có nguồn mã "có thẩm quyền" nào (ngoại trừ "theo thỏa thuận", khi được sử dụng) và trao đổi dữ liệu P2P là có thể mà không cần thêm các cấp (định nghĩa cá nhân, không chính tắc)

Về chủ đề câu hỏi đầu tiên

Tôi sợ, công ty phải xây dựng lại quy trình làm việc và suy nghĩ lại về phong cách để có được "mã được quản lý và dự đoán bằng cách nào đó". Tôi không thể nói về TFS (ngoại trừ ý kiến ​​và cảm nhận cá nhân, đó là hệ thống yếu trong Phần kiểm soát phiên bản / hợp nhất vô căn cứ là xấu /), nhưng đối với bất kỳ VCS nào trong tình huống của bạn ("Sản phẩm" được đặt là "Mô-đun" độc lập, mỗi "Khách hàng" nhận được "Sản phẩm" khác nhau - giả định này có đúng không?) Tôi sẽ thích phát triển các mô-đun thành các nhánh riêng biệt, có Sản phẩm là "Siêu mẫu" (cũng là chi nhánh?), có mỗi mô-đun được gắn với sửa đổi cụ thể của mô-đun- nhánh, phát triển mô-đun sử dụng mô hình chi nhánh cho mỗi nhiệm vụ (và mô-đun nhánh chỉ bao gồm từ các phép hợp nhất).

Bằng cách này, bạn luôn có thể biết, "Bộ sưu tập" (nghĩa là bộ mô-đun và phiên bản tương ứng của chúng) tạo thành từng "Sản phẩm", có khả năng thực hiện CI (đối với các nhánh tác vụ đã hoàn thành và được hợp nhất ), Kiểm thử đơn vị và Xây dựng


1

Câu hỏi chính của quảng cáo: Tôi tin rằng những gì bạn đang nói là chính xác mô hình phân nhánh thành công của git (và công cụ trợ giúp git chảy để hỗ trợ nó) là gì. Có một nhánh chính, luôn ở trạng thái có thể triển khai và thực hiện tất cả các công việc trên các nhánh tính năng.

Bạn cũng có thể sử dụng quy trình được sử dụng bởi chính git, được bắt nguồn từ cùng một nguyên tắc cơ bản. Trong phát triển git-core, tất cả các công việc xảy ra trên các nhánh tính năng. Các nhánh tính năng được gửi tới nhà tích hợp, người chạy tập lệnh để hợp nhất tất cả chúng để tạo một nhánh có tên pu(các bản cập nhật được đề xuất). Nhiều người lấy chi nhánh này và làm việc với nó để kiểm tra nó.

Thay vì tích hợp, bạn có thể có máy chủ tích hợp liên tục thực hiện việc hợp nhất này khi bắt đầu xây dựng. Theo cách đó, bất cứ khi nào bất kỳ ai trong nhóm đẩy các thay đổi vào kho lưu trữ trung tâm dưới dạng một nhánh tính năng (có thể sử dụng một số quy ước đặt tên để cho biết các nhánh nào sẽ được chọn).

Trong git chi nhánh tính năng hơn so với tiền thu được để next, masterhoặc mainttùy thuộc vào giải phóng đang nhắm mục tiêu tại (Maint là dành cho sửa chữa lỗi phát hành hiện tại, tổng thể hiện nay phát hành trong việc chuẩn bị và tiếp theo cho một sau đó), nhưng bạn sẽ không phải là nhiều.

Mặc dù các tính năng nằm trong pu("nấu ăn" theo thuật ngữ của người bảo trì git), chúng được tua lại và punhánh bị loại bỏ và được tạo lại mỗi lần, điều này giúp dễ dàng xem xét hơn, nhưng không phù hợp để làm việc khác. Khi nhánh tính năng được hợp nhất vào một trong những dòng chính, nó được đóng lại để tua lại và sửa lỗi thêm được thực hiện như các cam kết mới.

Cá nhân tôi muốn giới thiệu gittốt nhất. Ban đầu khó học hơn một chút, vì nó phát triển hữu cơ hơn, nhưng cuối cùng thì nó có vẻ linh hoạt nhất. Nhưng bất kỳ một trong ba hệ thống phân tán, git, mercurial và bazaar sẽ phục vụ tốt cho bạn (và bạn thậm chí có thể trộn lẫn chúng, ví dụ: mercurial có thể kéo và đẩy đến / từ kho git và tôi tin là có thể bán chợ).

Câu hỏi thứ hai về quảng cáo: Tôi được dạy rằng "phân phối", nói chung, có nghĩa là bạn có thể di chuyển các vật thể xung quanh và chúng giữ bản sắc của chúng. Đó chính xác là những gì kiểm soát phiên bản phân tán thực hiện: bạn sao chép kho lưu trữ và nó chứa cùng một cam kết và cho phép thực hiện những điều tương tự với chúng. Sự dễ dàng của việc phân nhánh và hoạt động bị ngắt kết nối là các tính năng chính ở cấp độ người dùng tuân theo nguyên tắc di chuyển cam kết xung quanh và bố cục đồ thị có hướng cho phép nó.


1

Thật không may, không có giải pháp được biết đến cho các lỗi trong mã :)

Vì vậy, bạn chỉ đang tìm cách ngăn chặn các đăng ký chưa hoàn thành bị cuốn vào bản phát hành chính và câu trả lời duy nhất cho điều đó là hợp nhất công việc chi nhánh cho mỗi nhà phát triển. Tôi đã làm điều này trong một công ty trước đó bằng Clearcase, nó hoạt động khá tốt (mặc dù chúng tôi phải có hàng tá quản trị viên Clearcase).

Bây giờ, tôi cũng giả sử rằng bạn thực hiện sửa lỗi trên phiên bản sản phẩm mà mỗi khách hàng hiện đang có ... vì vậy bạn gặp phải sự cố hợp nhất khi đưa lỗi từ phiên bản A đến phiên bản Z. Không có cách nào dễ dàng để xử lý này, nhưng bạn sẽ phải có một chi nhánh cho mỗi phiên bản được vận chuyển. Cách tốt nhất để giải quyết vấn đề này là chỉ giữ các nhánh tính năng trên phiên bản mới nhất và khiến khách hàng nâng cấp để có được các tính năng mới, đồng thời, thực hiện sửa lỗi trực tiếp trên nhánh phát hành và hợp nhất chúng lên tất cả các nhánh phát hành khác khi hoàn thành

Không quá đẹp, nhưng nó có thể hoạt động rất tốt. Bạn giữ mã được tổ chức và tách biệt độc đáo. Nó cũng dễ hiểu đối với các nhà phát triển khác - các lỗi nhỏ trực tiếp trên "mã", bất cứ điều gì nhiều hơn một vài dòng được thực hiện trên một nhánh chuyên dụng nơi họ có thể mất bao lâu để hoàn thành nó. (bạn sẽ phải sắp xếp các vấn đề hợp nhất và trấn an họ rằng sẽ ổn nếu 2 nhà phát triển hoạt động trên 2 tính năng cùng một lúc !!)

Sau một thời gian, bạn cũng có thể giới thiệu các nhánh tính năng trên các nhánh phát hành, trong đó các lỗi được sửa sau đó được hợp nhất, nhưng IMHO điều này thường tốn nhiều công sức hơn mức cần thiết. Nếu bạn cần thêm các tính năng cho các bản phát hành cũ, thì bạn sẽ cần tuân theo cách tiếp cận này - nhánh ff một nhánh phát hành, sau đó hợp nhất mã trở lại với bản phát hành đó và cũng hợp nhất thay đổi lên các bản phát hành sau. Điều đó sẽ làm cho nhóm thử nghiệm của bạn rất không hài lòng vì các bản phát hành sẽ bị trì hoãn rất nhiều do phải thử nghiệm nhiều phiên bản nhiều lần và nhóm nhà phát triển không hài lòng vì họ sẽ phải thực hiện nhiều việc hợp nhất trước khi họ có thể bắt đầu mã mới (trong công ty hiện tại của tôi điều này xảy ra, chủ yếu là do khối lượng công việc chúng tôi có mà luôn cần phải hoàn thành càng sớm càng tốt).

DVCS:

về cơ bản, DVCS là nơi mọi người đều có bản sao của máy chủ repo. Nó có một số lợi thế (đặc biệt là trong các nhóm phân phối có giới hạn hạn chế), nhưng cũng có một số nhược điểm vì vậy hãy kiểm tra chúng trước khi bạn chuyển sang DVCS. Nếu bạn là một cửa hàng Windows thì có lẽ bạn sẽ thấy Mercurial là DVCS tốt nhất cho bạn.

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.