Tích hợp liên tục: làm thế nào để bạn liên kết các bản dựng của mình với các yêu cầu/nhiệm vụ/lỗi?

Question

Làm cách nào để bạn trả lời các câu hỏi sau đây từ người quản lý, người kiểm tra và những người khác trong nhóm của bạn:

Lỗi xây dựng là gì? Những công việc nào đã được hoàn thành trong bản dựng thử nghiệm hiện tại của chúng tôi?

Vì vậy, chỉ cần đặt, làm thế nào để bạn đạt được truy xuất nguồn gốc của các yêu cầu, nhiệm vụ và lỗi của bạn ngay từ khi chúng được báo cáo thông qua báo cáo để triển khai? Bạn đang sử dụng quy trình, công cụ và kỹ thuật nào để đạt được điều này?

Answer 1

Chúng tôi sử dụng TRAC với SVN trong Công ty của chúng tôi và thực hiện các bản dựng hàng ngày cho DEV/STAGING & Môi trường ổn định với triển khai theo lịch thường xuyên (mỗi tháng một lần ... ish) vào môi trường sản xuất.

Khi một lỗi được báo cáo, nó tham gia vào TRAC và đưa ra một số vé (ví dụ # 1001)

Khi lỗi được cố định, các mã được kiểm tra lại vào SVN với số lượng vé (# 1001) trong SVN Checkin ghi chú.

Nhà phát triển ghi chú số SVN Changeset (ví dụ: [5000]) và mở trang TRAC web ui. Khi đóng vé, họ đặt số changeset trong các ghi chú của vé.

Bằng cách này, SVN checkin tham khảo vé ... và vé tham khảo SVN Checkin.

Các bản dựng hàng ngày của chúng tôi được thực hiện dựa trên Thay đổi SVN (ví dụ: xây dựng ngày hôm nay là mọi thứ thay đổi [5050]) và ghi chú được thực hiện trong thông báo triển khai của chúng tôi.

Deployed On | Environment   | Changeset 
--------------+-------------------------+-------------------------- 
10-01-2008 | DEV     | 5100 
10-01-2008 | STAGING    | 5080 
10-01-2008 | STABLE     | 5050 
01-01-2008 | PRODUCTION    | 5000 

Bằng cách đó, người thử nghiệm khi xem xét các bản sửa lỗi để kiểm tra biết bởi changeset trong nhận xét về vé nếu bản dựng họ đang xem bao gồm bản sửa lỗi.

Answer 2

Chúng tôi đang gắn thẻ kiểm tra nguồn kiểm tra với số lỗi đã được sửa hoặc số nâng cao đã được triển khai.

Bằng cách truy xuất nhật ký đăng ký giữa hai bản dựng, bạn có thể xác định những gì đã được triển khai hoặc cố định.

Answer 3

Chúng tôi sử dụng TFS cùng với TeamCity của JetBrains cho CI.

Khi liên kết đăng ký với các tác vụ, chính sách đăng ký tùy chỉnh của chúng tôi sẽ thêm các tác vụ và lỗi liên quan với ID và tiêu đề của chúng vào nhận xét đăng ký.

Các nhận xét này sau đó được sử dụng để tạo ghi chú phát hành, được tạo tự động cho mỗi bản dựng.

Answer 4

Chúng tôi sử dụng dịch vụ SVN được quản lý có tên Beanstalk (http://www.beanstalkapp.com/) cho phép bạn dễ dàng kết hợp với một số hệ thống quản lý lỗi/tính năng. Trong trường hợp của chúng ta, chúng ta sử dụng FogBugz của Fog Creek để kết thúc mọi thứ. SVN/Beanstalk cho phép bạn ghi chú khi bạn kiểm tra trong một bản dựng, điều này sẽ ảnh hưởng đến trạng thái của một hoặc nhiều trường hợp FogBugz. Trên máy khách, chúng tôi sử dụng Tortoise SVN và Visual SVN để quản lý sự tương tác của máy khách cục bộ và máy chủ Beanstalk SVN (Tortoise cung cấp dịch vụ thực, Visual SVN cung cấp sự tích hợp giữa Tortoise SVN và MS Visual Studio).

Tôi khuyên bạn nên sử dụng cả dịch vụ và ứng dụng khách Rùa/Visual SVN.

Answer 5

Chúng tôi đang sử dụng Fogbugz có tích hợp lật đổ tích hợp. Về cơ bản có một plugin cho Fogbugz để kiểm tra SVN check-in ở chế độ nền. Vì vậy, nếu bạn cung cấp một id Fogbugz-case tại check-in của bạn, nó sẽ được tự động liên kết với check-in này.

Theo như tôi biết bạn không cần bất kỳ ứng dụng đặc biệt nào (ví dụ như Cây đậu).

Vòng xoay vòng khác ít phức tạp. Trong công ty của chúng tôi có một quy ước cho mỗi (tương lai hoặc quá khứ) xây dựng có một "phát hành" trong Fogbugz. Nếu bạn sửa lỗi hoặc triển khai tính năng, bạn chỉ định trường hợp đó cho bản phát hành phù hợp.

Sau đó, thật dễ dàng để có được danh sách tất cả các tính năng được triển khai của bản dựng X.