Làm thế nào để bạn duy trì mã phát triển và mã sản xuất? [đóng cửa]

Các thực tiễn và quy tắc tốt nhất để tuân theo trong khi duy trì mã là gì? Có phải là thông lệ tốt khi chỉ có mã sẵn sàng sản xuất trong nhánh phát triển hoặc mã chưa được kiểm tra mới nhất có sẵn trong nhánh phát triển không?

Làm thế nào để các bạn duy trì mã phát triển và mã sản xuất của bạn?

Chỉnh sửa - Câu hỏi bổ sung - Nhóm phát triển của bạn có tuân theo giao thức "cam kết càng sớm càng tốt và thường xuyên ngay cả khi mã-chứa-lỗi-lỗi-hoặc-không hoàn chỉnh" hoặc "cam kết không Giao thức CHỈ-perfect-code "trong khi cam kết mã cho chi nhánh PHÁT TRIỂN?

Cập nhật 2019:

Ngày nay, câu hỏi sẽ được nhìn thấy trong bối cảnh sử dụng Git và 10 năm sử dụng quy trình phát triển phân tán đó (cộng tác chủ yếu thông qua GitHub ) cho thấy các thực tiễn tốt nhất chung:

• masterlà nhánh sẵn sàng để được triển khai vào sản xuất bất cứ lúc nào: phiên bản tiếp theo, với một tập hợp các nhánh tính năng được chọn được hợp nhất master.
• dev(hoặc nhánh tích hợp hoặc ' next') là nhánh mà nhánh tính năng được chọn cho phiên bản tiếp theo được thử nghiệm cùng nhau
• maintenance(hoặc hot-fix) nhánh là một trong những bản sửa lỗi phát triển / sửa lỗi phát hành hiện tại, với khả năng hợp nhất trở lại devvà hoặcmaster

Loại quy trình công việc đó (nơi bạn không hợp nhất devvới master, nhưng nơi bạn chỉ hợp nhất nhánh tính năng dev, sau đó nếu được chọn, để mastercó thể thả dễ dàng các tính năng không sẵn sàng cho bản phát hành tiếp theo) được triển khai trong Git repo chính nó, với gitworkflow (một từ, minh họa ở đây ).
Xem thêm tại rocketraman/gitworkflow. Lịch sử của việc làm này so với Trunk-Dựa-Development được ghi nhận trong các bình luận và thảo luận về bài viết này của Adam Dymitruk .

^{(nguồn: Gitworkflow: Primer định hướng nhiệm vụ )}

Lưu ý: trong quy trình công việc phân tán đó, bạn có thể cam kết bất cứ khi nào bạn muốn và chuyển sang chi nhánh cá nhân một số WIP (Work In Progress) mà không gặp sự cố: bạn sẽ có thể sắp xếp lại (git rebase) các cam kết của mình trước khi biến chúng thành một nhánh của tính năng.

Câu trả lời gốc (tháng 10 năm 2008, hơn 10 năm trước)

Tất cả phụ thuộc vào bản chất tuần tự của quản lý phát hành của bạn

Đầu tiên, là tất cả mọi thứ trong thân cây của bạn thực sự cho phiên bản tiếp theo ? Bạn có thể thấy rằng một số chức năng hiện đang được phát triển là:

• quá phức tạp và vẫn cần phải được tinh chế
• chưa sẵn sàng kịp
• thú vị nhưng không phải cho phiên bản tiếp theo này

Trong trường hợp này, thân cây nên chứa bất kỳ nỗ lực phát triển hiện tại nào, nhưng một nhánh phát hành được xác định sớm trước khi phát hành tiếp theo có thể đóng vai trò là nhánh hợp nhất trong đó chỉ có mã thích hợp (được xác thực cho phiên bản tiếp theo) được hợp nhất, sau đó được cố định trong giai đoạn tương đồng, và cuối cùng bị đóng băng khi đi vào sản xuất.

Khi nói đến mã sản xuất, bạn cũng cần quản lý các nhánh vá của mình , trong khi ghi nhớ rằng:

• bộ bản vá đầu tiên thực sự có thể bắt đầu trước khi phát hành đầu tiên vào sản xuất (có nghĩa là bạn biết bạn sẽ đi vào sản xuất với một số lỗi bạn không thể sửa kịp thời, nhưng bạn có thể bắt đầu công việc cho những lỗi đó trong một nhánh riêng)
• các nhánh vá khác sẽ có sự sang trọng để bắt đầu từ một nhãn sản xuất được xác định rõ

Khi nói đến nhánh dev, bạn có thể có một thân cây, trừ khi bạn có những nỗ lực phát triển khác mà bạn cần thực hiện song song như:

• tái cấu trúc lớn
• thử nghiệm thư viện kỹ thuật mới có thể thay đổi cách bạn gọi mọi thứ trong các lớp khác
• bắt đầu một chu kỳ phát hành mới, nơi những thay đổi kiến ​​trúc quan trọng cần được kết hợp.

Bây giờ, nếu chu trình phát hành-phát triển của bạn rất tuần tự, bạn có thể đi như các câu trả lời khác gợi ý: một thân cây và một số nhánh phát hành. Điều đó làm việc cho các dự án nhỏ, nơi tất cả sự phát triển chắc chắn sẽ đi vào phiên bản tiếp theo, và có thể bị đóng băng và đóng vai trò là điểm khởi đầu cho chi nhánh phát hành, nơi các bản vá có thể diễn ra. Đó là quá trình danh nghĩa, nhưng ngay khi bạn có một dự án phức tạp hơn ... nó không còn đủ nữa.

Để trả lời bình luận của Ville M .:

• Hãy nhớ rằng nhánh dev không có nghĩa là 'một nhánh cho mỗi nhà phát triển' (sẽ kích hoạt 'sự điên rồ hợp nhất', trong đó mỗi nhà phát triển sẽ phải hợp nhất công việc của người khác để xem / nhận công việc của họ), nhưng một nhánh dev cho mỗi phát triển cố gắng.
• Khi những nỗ lực đó cần được sáp nhập trở lại vào thân cây (hoặc bất kỳ nhánh "chính" hoặc phát hành nào khác mà bạn xác định), đây là công việc của nhà phát triển, không - tôi nhắc lại, KHÔNG - Trình quản lý SC (người không biết cách giải quyết bất kỳ sự hợp nhất xung đột). Người lãnh đạo dự án có thể giám sát việc hợp nhất, nghĩa là đảm bảo nó bắt đầu / kết thúc đúng hạn.
• bất cứ ai bạn chọn để thực sự hợp nhất, điều quan trọng nhất là:
  • để có các bài kiểm tra đơn vị và / hoặc môi trường lắp ráp trong đó bạn có thể triển khai / kiểm tra kết quả của việc hợp nhất.
  • đã xác định một thẻ trước khi bắt đầu hợp nhất để có thể quay lại trạng thái trước đó nếu việc hợp nhất được nói chứng tỏ bản thân quá phức tạp hoặc khá lâu để giải quyết.

Chúng tôi sử dụng:

• chi nhánh phát triển

cho đến khi dự án gần hoàn thành hoặc chúng tôi đang tạo một phiên bản quan trọng (ví dụ: bản giới thiệu sản phẩm, phiên bản trình bày), sau đó chúng tôi (thường xuyên) phân nhánh khỏi nhánh phát triển hiện tại của chúng tôi vào:

• chi nhánh phát hành

Không có tính năng mới đi vào chi nhánh phát hành. Chỉ các lỗi quan trọng được sửa trong nhánh phát hành và mã để sửa các lỗi này được tái hòa nhập vào nhánh phát triển.

Quá trình gồm hai phần với sự phát triển và chi nhánh (phát hành) ổn định giúp cuộc sống của chúng tôi dễ dàng hơn rất nhiều và tôi không tin rằng chúng tôi có thể cải thiện bất kỳ phần nào của nó bằng cách giới thiệu nhiều chi nhánh hơn. Mỗi chi nhánh cũng có quy trình xây dựng riêng, nghĩa là cứ sau vài phút, một quy trình xây dựng mới được sinh ra và vì vậy sau khi kiểm tra mã, chúng tôi có một bản thực thi mới của tất cả các phiên bản và chi nhánh xây dựng trong khoảng nửa giờ.

Thỉnh thoảng, chúng tôi cũng có các chi nhánh cho một nhà phát triển làm việc trên một công nghệ mới và chưa được chứng minh, hoặc tạo ra một bằng chứng về khái niệm. Nhưng nhìn chung nó chỉ được thực hiện nếu những thay đổi ảnh hưởng đến nhiều phần của cơ sở mã. Điều này xảy ra trung bình cứ sau 3-4 tháng và một chi nhánh như vậy thường được tái hòa nhập (hoặc bị loại bỏ) trong vòng một hoặc hai tháng.

Nói chung tôi không thích ý tưởng của mọi nhà phát triển làm việc trong chi nhánh của mình, bởi vì bạn "bỏ qua và chuyển trực tiếp đến địa ngục tích hợp". Tôi sẽ khuyên mạnh mẽ chống lại nó. Nếu bạn có một cơ sở mã chung, tất cả bạn nên làm việc với nó. Điều này làm cho các nhà phát triển cảnh giác hơn về việc đăng ký của họ và với kinh nghiệm, mọi lập trình viên đều biết những thay đổi nào có khả năng phá vỡ bản dựng và vì vậy việc kiểm tra sẽ nghiêm ngặt hơn trong những trường hợp như vậy.

Về câu hỏi sớm khi nhận phòng:

Nếu bạn chỉ yêu cầu MÃ HOÀN HẢO để được kiểm tra, thì thực tế không có gì nên được kiểm tra. Không có mã nào là hoàn hảo và để QA xác minh và kiểm tra nó, nó cần phải nằm trong nhánh phát triển để có thể xây dựng một tệp thực thi mới.

Đối với chúng tôi điều đó có nghĩa là một khi tính năng được nhà phát triển hoàn thành và kiểm tra thì nó đã được kiểm tra. Nó thậm chí có thể được kiểm tra nếu có lỗi (không gây tử vong), nhưng trong trường hợp đó, những người sẽ bị ảnh hưởng bởi lỗi này thường được thông báo. Mã không đầy đủ và đang thực hiện cũng có thể được kiểm tra nhưng chỉ khi nó không gây ra bất kỳ tác động tiêu cực rõ ràng nào, như sự cố hoặc phá vỡ chức năng hiện có.

Thỉnh thoảng việc kiểm tra dữ liệu & mã kết hợp không thể tránh khỏi sẽ khiến chương trình không thể sử dụng được cho đến khi mã mới được xây dựng. Việc tối thiểu chúng tôi làm là thêm "WAIT FOR BUILD" trong bình luận đăng ký và / hoặc gửi e-mail.

Đối với những gì nó có giá trị, đây là cách chúng tôi làm điều đó.

Hầu hết sự phát triển được thực hiện trong thân cây, mặc dù các tính năng thử nghiệm hoặc những thứ có thể phá vỡ hệ thống có xu hướng đáng kể để có được nhánh riêng của chúng. Điều này hoạt động khá tốt vì nó có nghĩa là mọi nhà phát triển luôn có phiên bản mới nhất của mọi thứ trong bản sao làm việc của họ.

Điều đó có nghĩa là điều quan trọng là giữ thân cây trong tình trạng hoạt động mơ hồ, vì hoàn toàn có thể phá vỡ nó. Trong thực tế điều đó không xảy ra thường xuyên, và hiếm khi là một vấn đề quan trọng.

Để phát hành sản xuất, chúng tôi phân nhánh thân cây, ngừng thêm các tính năng mới và làm việc với sửa lỗi và kiểm tra nhánh (thường xuyên hợp nhất trở lại vào thân cây) cho đến khi nó sẵn sàng để phát hành. Tại thời điểm đó chúng tôi thực hiện hợp nhất cuối cùng vào thân cây để đảm bảo mọi thứ đều ở đó, và sau đó phát hành.

Bảo trì sau đó có thể được thực hiện trên nhánh phát hành khi cần thiết và những sửa lỗi đó có thể dễ dàng được hợp nhất trở lại vào thân cây.

Tôi không khẳng định đây là một hệ thống hoàn hảo (và nó vẫn còn một số lỗ hổng - tôi không nghĩ quản lý phát hành của chúng tôi là một quy trình đủ chặt chẽ), nhưng nó hoạt động đủ tốt.

Tại sao không ai còn đề cập đến điều này? Một mô hình phân nhánh Git thành công .

Đó là cho tôi mô hình phân nhánh cuối cùng!

Nếu dự án của bạn nhỏ, đừng sử dụng tất cả các nhánh khác nhau (có lẽ bạn có thể bỏ qua các nhánh tính năng cho các tính năng nhỏ). Nhưng nếu không, đó là cách để làm điều đó!

Mã phát triển trên các nhánh, Mã trực tiếp được gắn thẻ trên Trunk.

Không cần phải có quy tắc "chỉ cam kết mã hoàn hảo" - mọi thứ mà nhà phát triển bỏ lỡ sẽ được chọn ở bốn nơi: đánh giá mã, kiểm tra chi nhánh, kiểm tra hồi quy, kiểm tra QA cuối cùng.

Dưới đây là giải thích từng bước chi tiết hơn:

1. Làm tất cả phát triển trên một chi nhánh, cam kết thường xuyên khi bạn đi.
2. Đánh giá mã độc lập về các thay đổi khi tất cả sự phát triển hoàn tất.
3. Sau đó chuyển chi nhánh qua Kiểm tra.
4. Khi kiểm tra chi nhánh hoàn tất, hợp nhất mã vào nhánh Ứng viên phát hành.
5. Phát hành nhánh Ứng viên là hồi quy được kiểm tra sau mỗi hợp nhất riêng lẻ.
6. Kiểm tra QA và UA cuối cùng được thực hiện trên RC sau khi tất cả các nhánh dev được hợp nhất.
7. Khi QA và UAT được thông qua, hợp nhất nhánh phát hành vào nhánh MAIN / TRUNK.
8. Cuối cùng, gắn thẻ Trunk tại thời điểm đó và triển khai thẻ đó thành Live.

dev đi trong thân cây (kiểu svn) và phát hành (mã sản xuất) có được các nhánh của riêng họ

Đó là "Mô hình phân nhánh theo mục đích" (hình 3 trong Tầm quan trọng của các mô hình phân nhánh /! \ Pdf)

Chúng tôi giải quyết vấn đề này bằng cách tách hoàn toàn mã sản xuất (thân chính) khỏi mã phát triển (nơi mọi nhà phát triển có chi nhánh riêng).

Không có mã nào được phép vào mã sản xuất trước khi nó được kiểm tra kỹ lưỡng (bởi QA và người đánh giá mã).

Cách này không có sự nhầm lẫn về mã nào hoạt động, nó luôn luôn là nhánh chính.

Ồ vâng - một điều khác - chúng tôi giữ mã phi sản xuất (nghĩa là sẽ KHÔNG BAO GIỜ được phát hành - ví dụ: tập lệnh công cụ, tiện ích thử nghiệm) trong cvs HEAD. Thông thường nó cần được đánh dấu rõ ràng để không ai "vô tình" phát hành nó.

Chúng tôi phát triển trên thân cây sau đó được phân nhánh hai tuần một lần và đưa vào sản xuất. Chỉ các lỗi nghiêm trọng được cố định trong chi nhánh, phần còn lại có thể đợi thêm hai tuần nữa.

Đối với thân cây, quy tắc duy nhất là một cam kết không nên phá vỡ bất cứ điều gì. Để quản lý mã wip và mã chưa được kiểm tra, chúng tôi chỉ cần thêm thích hợp nếu các số liệu thống kê để dễ dàng bật và tắt.

Về cơ bản, nó có thể phân nhánh bất cứ lúc nào và đưa nó vào sản xuất.

Tôi sử dụng git và tôi có 2 chi nhánh: thạc sĩ và Maint

• thạc sĩ - mã phát triển
• duy trì - mã sản xuất

khi tôi phát hành mã để sản xuất, tôi khóa nó và tôi kết hợp tổng thể để nhập Maint chi nhánh. Tôi luôn luôn triển khai từ Maint chi nhánh. Các bản vá từ nhánh phát triển Tôi chọn chúng để duy trì chi nhánh và triển khai các bản vá.

Chúng tôi có một chi nhánh "phát hành" chứa những gì hiện đang được sản xuất hoặc sẽ được triển khai trong thời gian ngắn (đã qua hầu hết QA)

Mỗi dự án, hoặc trong một số trường hợp, đơn vị khác, có chi nhánh riêng được phân nhánh từ phát hành.

Các thay đổi được cam kết, bởi các nhà phát triển trong dự án, vào chi nhánh riêng của dự án của họ. Theo định kỳ, phát hành được sáp nhập trở lại vào một nhánh phát triển.

Khi các gói công việc trên nhánh là tất cả QA'd (kiểm tra đơn vị, kiểm tra hệ thống, đánh giá mã, đánh giá QA, v.v.), nhánh được hợp nhất vào nhánh phát hành. Bản dựng mới được xây dựng từ nhánh phát hành và xác thực cuối cùng xảy ra trên phiên bản đó.

Quá trình về cơ bản là ổn cho đến khi một vấn đề được phát hiện sau khi hợp nhất được thực hiện. Nếu một WP bị "kẹt" sau khi nó được hợp nhất, nó sẽ giữ mọi thứ sau khi nó được sửa chữa (chúng ta không thể thực hiện một bản phát hành khác cho đến khi bản bị kẹt được phát hành).

Nó cũng hơi linh hoạt - một thay đổi rất nhỏ có thể xảy ra trực tiếp trên nhánh phát hành nếu nó được phát hành ở quy mô thời gian rất ngắn (như 1-2 ngày hoặc lâu hơn).

Nếu một số thay đổi được đưa trực tiếp vào sản xuất vì một lý do nào đó (vấn đề sản xuất ảnh hưởng đến khách hàng quan trọng cần phải thay đổi mã ngay lập tức để khắc phục), những thay đổi đó sẽ được đưa trở lại vào BRANCH_RELEASE. Điều đó hầu như không bao giờ xảy ra.

Nó phụ thuộc vào dự án. Mã web của chúng tôi được kiểm tra khá nhất quán, trong khi mã ứng dụng của chúng tôi chỉ được kiểm tra nếu nó biên dịch. Tôi đã nhận thấy rằng điều này khá giống với cách chúng tôi phát hành mọi thứ. Công cụ web tăng lên bất cứ khi nào có thể trong khi các ứng dụng đạt đến thời hạn cuối cùng. Tôi chưa thấy giảm chất lượng trong cả hai phương pháp.