Có điều gì đó sai với cách chúng tôi đang kiểm soát phiên bản?

Tôi làm việc với một nhóm lập trình viên là nhà phân tích kinh doanh. Chúng tôi vừa phát hành phiên bản 2.0 của sản phẩm và đang làm việc trên phiên bản tiếp theo sẽ được phát hành sau 3 tháng nữa (đó là một sản phẩm phần mềm nội bộ). Thật không may, phiên bản 2.0 có một số vấn đề mà họ đã phải sửa và chúng tôi sẽ triển khai các bản sửa lỗi đó trong một vài tuần. Vấn đề là chúng tôi cũng không muốn triển khai các thay đổi vẫn đang được thực hiện và dự kiến ​​sẽ không được phát hành thêm 3 tháng nữa.

Các lập trình viên quyết định rằng cách quản lý này là chỉ có mã cho các lỗi được kiểm tra và mã cho các cải tiến mới sẽ được giữ trên các máy cục bộ của nhà phát triển cho đến khi chúng được thực hiện. Tôi sẽ phải kiểm tra các bản dựng cục bộ từ máy của họ để kiểm tra vì nếu họ kiểm tra mã và chúng tôi phải đưa ra một bản vá khác để sửa lỗi, chúng tôi chưa muốn đưa vào những cải tiến đó. Ngoài ra còn có vấn đề trong đó cùng một tệp mã chứa cả sửa lỗi và cải tiến, do đó họ phải sao chép tệp mã cục bộ, sau đó thực hiện thay đổi để sửa lỗi và kiểm tra xem có lỗi nào không, sau đó tiếp tục làm việc với các cải tiến bằng cách thực hiện bản sao địa phương họ đã thực hiện.

Có vẻ như khá phức tạp - có cách nào tốt hơn để xử lý loại kịch bản này không? Chúng tôi đang sử dụng Team Foundation Server và Visual Studio 2010.

V2.0 nên có cái mà chúng ta đã sử dụng gọi là 'nhánh trạng thái ổn định' (chúng ta đã sử dụng Perforce chứ không phải TFS) được tạo ra cho nó khi nó được phát hành. Bất kỳ bản sửa lỗi nào cho v2 sẽ được thực hiện cho nhánh này và sau đó được truyền trở lại vào nhánh phát triển v3 trong khi các tính năng của v3 cũng đang được xử lý, tức là một lỗi trên v2 cũng sẽ dẫn đến lỗi trên v3.

Có những thay đổi nằm trong máy của nhà phát triển trong một thời gian dài có thể sẽ dẫn đến một cơn ác mộng tích hợp.

Vâng, có nhiều cách để giải quyết các vấn đề như vậy, thường được bao phủ bởi thẻ 'phân nhánh' , mỗi cách đều có lợi ích và nhược điểm riêng.

Nhưng cách tiếp cận được lựa chọn bởi các nhà phát triển của bạn ... tôi sẽ trích dẫn bằng lời nói để đảm bảo rằng tôi đã không đọc sai ...

mã ... sẽ được giữ trên các máy cục bộ của nhà phát triển cho đến khi hoàn thành ...

... Cách như trên có lẽ là cách duy nhất hoàn toàn sai lầm!

Điều khiến nó trở thành tội phạm đối với tôi là đối với TFS, có một Hướng dẫn phân nhánh máy chủ Microsoft Team Foundation tuyệt vời - tài liệu khổng lồ và chi tiết với các đề xuất chiến lược phân nhánh được thiết kế cẩn thận và giải thích cho tất cả các loại dự án khác nhau ( phiên bản HTML đây )

1. Nhà phát triển của bạn có một sự hiểu lầm cơ bản về cách sử dụng kiểm soát phiên bản.
2. Không được thảo luận về phần mềm kiểm soát phiên bản "đúng". Đây không phải là vấn đề.
3. Mỗi chỉnh sửa mã đang làm cho vấn đề khó khắc phục hơn.
4. Khi bạn quyết định làm điều đúng đắn, bạn không thể tiếp tục thay đổi mã trong khi bạn sửa chữa mọi thứ. Bạn PHẢI dừng tất cả sự phát triển và đưa mã vào kiểm soát phiên bản.
5. Các nhà phát triển phải cảm thấy đau đủ để ít nhất ngồi xuống và nói về nó.
6. Tất cả các phần mềm kiểm soát phiên bản đều hỗ trợ các khái niệm cơ bản:
   • TẤT CẢ mã đi vào kho điều khiển phiên bản.
   • Tất cả các tệp mã có số phiên bản. Những con số này tự động tăng lên khi mã được kiểm tra lại.
   • TAG đánh dấu tất cả các tệp mã của một (và tại một) phiên bản cụ thể. Vì vậy, chúng ta có thể TAG phiên bản phần mềm 1 phát hành, ví dụ.
   • CHI NHÁNH là một "quay lưng" từ thân cây chính .
     • Bất kỳ và tất cả các thay đổi được thực hiện cho một nhánh không ảnh hưởng đến thân cây.
     • Bạn có thể tùy ý hợp nhất các thay đổi nhánh trở lại vào thân chính tại một số điểm.
     • Do đó, chúng tôi có thể thử nghiệm mà không sợ làm hỏng "những thứ tốt".
7. Bạn sẽ phải kiểm soát phiên bản "bước nhảy đức tin" như tôi gọi. TRUST rằng theo các quy tắc cơ bản sẽ giữ cho mọi thứ thẳng. Thiếu kinh nghiệm làm cho chúng ta nghĩ khác, tin tưởng tôi.
8. Đây là một hướng dẫn phong nha. Nói chung và đầy đủ là bạn không cần phải tìm kiếm nhiều nguồn khác
   • Kiểm soát phiên bản, giải thích tốt hơn

biên tập

• Đặt kiểm soát phiên bản trên máy tính làm việc của bạn.
  • Bạn có thể làm điều này ngay bây giờ với sự phối hợp nhóm
  • Ngay cả với kiểm soát phiên bản nhóm, tôi rất khuyến khích điều này
  • Nếu nhóm của bạn sử dụng Git hoặc Mercurial, bạn đang sử dụng kho lưu trữ cục bộ, độc lập. Đó là cách kiểm soát phiên bản phân phối hoạt động.
  • Bạn có thể sử dụng phần mềm VC khác nhau từ nhóm của bạn. Nhóm chúng tôi sử dụng Subversion, tôi sử dụng Mercurial tại địa phương. Các siêu tệp phần mềm VC (".svn", ".mg", các thư mục ẩn) không xung đột.

Bạn không hoạt động như một kho lưu trữ nhóm thực tế. Đó là để quản lý công việc của riêng bạn, tái cấu trúc các nỗ lực, v.v. và CYAing chính mình khi nhóm tiếp tục FUBAR cơ sở mã.

kết thúc chỉnh sửa

Những gì bạn đang mô tả là một cách khủng khiếp để sử dụng kiểm soát phiên bản. Nên có một nhánh được tạo ra để phát hành 2.0, hoặc một thẻ hoặc một số định danh. Bằng cách đó, các sửa đổi cho bản phát hành đó có thể được bao gồm và sự phát triển hơn có thể tiếp tục xảy ra.

Bài viết này có thể cung cấp cho bạn một số ý tưởng. Nó được viết với gitý nghĩ, nhưng không có lý do gì mà nó không thể làm việc mercurialtốt như vậy. Tôi nhận ra rằng bạn đang sử dụng cả hai thứ này, nhưng đó cũng là một vấn đề mà bạn nên xem xét khắc phục.

Trả lời nhanh: Nhóm phát triển nên có một nhánh Sản xuất riêng biệt để giữ cho mã cơ sở V2.0 được triển khai tách biệt khỏi thân chính .

Tất cả các sửa lỗi cần phải được thực hiện trong nhánh đó trước rồi sau đó thử nghiệm và triển khai đến các nhánh khác, để giữ cho mã được đồng bộ .

Dự án của bạn cũng cần có một số môi trường for health developmentnhư Prod, Staging, QA và Dev (đôi khi là UAT). Các môi trường này nên được thiết lập trước khi phát hành Sản xuất.

Nói chung, sẵn sàng cho các lỗi và sửa đổi là cách để hỗ trợ một ứng dụng được phát hành.

Vì TFS đã được đề cập như một điều khiển phiên bản, tôi cũng đã tổng hợp danh sách các bài viết sẽ hữu ích để thiết lập (các) môi trường phát triển sức khỏe:

• Triển khai Team Foundation Server với một nhóm phát triển nhỏ
• Chào mừng bạn đến với Nền tảng tích hợp TFS!
• Phát triển nhóm với Hướng dẫn TFS
• Thiết lập môi trường phát triển

Không, bởi vì trong khi bạn đang sử dụng VCS, bạn không thực hiện kiểm soát phiên bản.

Khái niệm trung tâm cho kiểm soát phiên bản là theo dõi sự khác biệt theo thời gian, bạn đang QUY HOẠCH ghi lại một số khác biệt, nhưng tại thời điểm này, hầu hết các thay đổi của bạn không được ghi nhận.

Như những người khác đã nói, bạn nên sử dụng các chi nhánh. Khi bạn đã thiết lập xong, bạn nên kiểm tra tất cả các thay đổi chức năng (nghĩa là không phải mỗi lần nhấn phím, nhưng bất cứ khi nào bạn sửa lỗi, thêm một tính năng, xóa một tính năng hoặc hoàn thành một thay đổi để nó vẫn xây dựng và hoạt động).

Tôi là nhà phát triển và chúng tôi được cung cấp mã nhánh và db khác nhau cho các bản sửa lỗi của phiên bản hiện tại và khác nhau cho các cải tiến và cho phiên bản liên tiếp sau này.

Khi các bản sửa lỗi của chúng tôi được thực hiện, chúng được hợp nhất với sản xuất và được triển khai, chúng tôi sẽ nhận được chi nhánh mới để hoạt động trở lại với các cải tiến.

Ngoài ra, chúng tôi tuân theo một thực tiễn như nếu tôi có 10 bản sửa lỗi cho phiên bản hiện tại của mình

Tôi viết như

//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"

Tương tự như vậy đối với các bản sửa lỗi khác, tôi chỉ thực hiện việc này cho từng dòng tôi thay đổi hoặc thêm để sửa. Và chỉ cần so sánh và cam kết. Tương tự nếu họ đang làm song song trên cùng một nhánh họ có thể sử dụng

//Start Enhancement -1, Branch No-"ABC" 
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC" 

Ctrl+Shift+Flệnh và loại //Start Iteration 2, Fix No-1, Branch No-"ABC" để tìm kiếm trong toàn bộ giải pháp giúp rất nhiều để tìm ra vị trí chính xác, các tệp nơi mã được thay đổi và chỉ lấy mã mới mà phần đó có thể được sử dụng để cam kết.