Thiết lập SVN cho phù hợp nhất với Dev -> QA -> Prod

Question

Tôi xin lỗi nếu điều này đã được yêu cầu, nhưng tôi không thể tìm thấy câu trả lời cụ thể cho trường hợp này:

Đối với trang web của chúng tôi ứng dụng, chúng tôi có 3 hệ thống: dev, QA và sản xuất. Ngay bây giờ, một bên thứ ba đang duy trì mã, nhưng chẳng bao lâu nó sẽ nằm trong tay chúng tôi. Chúng tôi sẽ có môi trường xây dựng riêng biệt cho từng giai đoạn. Ngoài ra, chúng tôi sử dụng RAD để phát triển mã, vì vậy sẽ thực sự là bước chính, kiểm tra/sandbox. Lý tưởng nhất, chúng tôi muốn bằng cách nào đó cô lập kho lưu trữ cho từng giai đoạn, như vậy chúng tôi kiểm tra từ DEV, thực hiện một số thay đổi, kiểm tra chúng tại địa phương và kiểm tra chúng trở lại vào DEV. Nếu mọi thứ đều ổn trên Dev, chúng tôi sẽ kiểm tra vào QA, v.v.

Nếu chúng tôi có các kho lưu trữ riêng biệt cho mỗi sản phẩm, hoặc điều này sẽ nằm trong 'phân nhánh', nơi chúng tôi sẽ có chi nhánh riêng cho dev, QA và sản phẩm. Bạn có thể cung cấp phương tiện tốt nhất để triển khai bất kỳ tuyến đường lý tưởng nào không?

Hãy cho tôi biết nếu bạn có bất kỳ câu hỏi nào khác.

Cảm ơn Chris

Answer 1

sử dụng nhánh và sáp nhập

Chúng tôi thực hiện như sau:

Khi chúng tôi phát hành, chúng tôi tạo ra một nhánh phát hành hiện tại. Chúng tôi sửa lỗi ở đây giữa các bản phát hành, sau đó hợp nhất chúng lại với thân cây của chúng tôi.

Chúng tôi phát triển trên thân cây và khi chúng tôi sẵn sàng phát hành, chúng tôi tạo chi nhánh QA. Chúng tôi kiểm tra và sửa chữa nó và sau đó đẩy nó ra và nó sẽ trở thành chi nhánh phát hành hiện tại của chúng tôi.

Answer 2

Bạn nên có một kho lưu trữ duy nhất có thể được kiểm tra ra hoặc xuất khẩu trong quá trình triển khai.

Chúng tôi cũng có thiết lập tương tự. Các nhà phát triển kiểm tra một bản sao làm việc tại địa phương và phát triển trong môi trường dev của họ. Khi chúng tôi đã sẵn sàng để deloy đến sân khấu, hoặc QA như bạn gọi nó, chúng tôi làm một xuất khẩu svn đến môi trường đó (thường là đầu, nhưng chúng tôi luôn luôn theo dõi các phiên bản cụ thể).

Trong quá trình QA, chúng tôi tiếp tục phát triển trong dev và triển khai cho QA.

Cuối cùng, khi chúng tôi sẵn sàng sản xuất, chúng tôi xuất bản sửa đổi phù hợp từ kho lưu trữ vào môi trường sản xuất.

Hoạt động tuyệt vời!

[Chỉnh sửa: theo như 'nhánh này' - những gì bạn mô tả có thể giống như theo dõi các bản sửa đổi. Tuy nhiên, phân nhánh là một kỹ thuật rất quan trọng để quản lý các đường phát triển khác nhau. điều này không nên nhầm lẫn với việc có một chi nhánh khác nhau cho từng giai đoạn (dev, sân khấu, sống), nhất thiết]

Answer 3

Điều này hoạt động tốt nếu bạn đang làm việc trên một luồng phát triển đơn lẻ với các tác vụ được xác nhận dễ dàng. Nhưng nó sẽ chứng minh nhiều thách thức hơn với nhiều luồng phát triển và khả năng của các nhiệm vụ được rút ra hoặc bị trì hoãn. Sau đó bạn sẽ cần một số loại phụ thuộc thời gian trong ứng dụng của bạn. Bạn cũng có thể sử dụng một cái gì đó giống như các chi nhánh tính năng được sáp nhập trở lại vào thân cây khi tính năng được xây dựng.

Answer 4

Kiểm tra bài blog của Scott Cowan:

http://sleepoverrated.com/archive/2007/12/buildknowledgepromotingyourbuild/

Ông có một bài viết tuyệt vời về việc thúc đẩy mã của bạn để môi trường khác nhau. Nó sẽ bao gồm viết một số kịch bản xây dựng nhưng sẽ cải thiện quy trình. Nó sẽ cho phép nó cũng là một số những gì tự động.

Answer 5

Chúng tôi có sơ đồ tương tự. Trong SVN, chúng tôi có 3 chi nhánh, trunk, PREPROD và PROD. Bất cứ khi nào tính năng mới sẵn sàng để thử, nó sẽ được hợp nhất vào chi nhánh PREPROD (chỉ sử dụng số sửa đổi cụ thể và chỉ cho các tệp cụ thể), nếu nó vượt qua QA, nó được cam kết và hợp nhất thành chi nhánh PROD. Khi thay đổi được cam kết trong chi nhánh PROD, chúng sẽ tự động được triển khai trong tất cả các máy chủ sản xuất. Ngoại trừ khi thử nghiệm các tính năng mới, PREPROD và PROD bằng nhau.

Answer 6

Chúng tôi có một nhánh phát triển cho mỗi bugfix, tính năng hoặc nhiệm vụ và các dự án có liên quan có xu hướng có nhiều nhánh con.

Ban đầu, việc tạo một chi nhánh mới chỉ để sửa mã một dòng là khó khăn, nhưng nó cho phép hợp nhất thân cây vào nhánh, sau đó kiểm tra hồi quy và cuối cùng kết hợp lại vào thân cây.

Lý tưởng là điều này có nghĩa là mọi thứ được hợp nhất vào thân cây sẽ không phá vỡ bản dựng, và điều đó có nghĩa là bạn không sợ làm cho mã của bạn tạo ra một bản dựng dễ vỡ.

Tôi thường sử dụng nhiều nhánh cho một vấn đề, thử nghiệm các giải pháp khác nhau trong khi vẫn nhận được lợi ích của SCM.

Chúng tôi cũng gắn thẻ các phiên bản hoặc bản phát hành cụ thể, cho phép triển khai nhanh dựa trên mã tốt đã biết.

Rất nhiều hệ thống dựa trên web của chúng tôi sử dụng svn: externals trỏ đến các phiên bản phụ thuộc cụ thể như thư viện và mã nhà cung cấp. Triển khai được lấy từ các bên ngoài, chứ không phải thanh toán hoặc xuất trực tiếp.