2010-02-23 10 views
6

Tôi hiện đang làm việc trên một dự án khá lớn với một nhóm được phân phối trên khắp Hoa Kỳ. Nhà phát triển thường xuyên cam kết mã vào kho lưu trữ nguồn. Chúng tôi có các ứng dụng sau xây dựng (tất cả được quản lý bởi một ứng dụng, không có quy trình thủ công):câu hỏi về quản lý cá thể ứng dụng

  1. Tích hợp liên tục: một màn hình kiểm tra xem nếu kho mã đã được cập nhật, nếu có thì nó hoạt động xây dựng và chạy của chúng tôi bộ kiểm tra đơn vị. Nếu có lỗi, nhóm sẽ nhận được thông báo qua email
  2. Xây dựng hàng ngày: Nhà phát triển sử dụng công cụ này để xác minh bản sửa lỗi hoặc mã mới trên máy chủ ứng dụng thực và nếu "mọi thứ" thành công, nhà phát triển có thể giải quyết tác vụ.
  3. Xây dựng hàng tuần: Người thử nghiệm xác minh hàng đợi vấn đề đã giải quyết trong bản dựng này. Nó là một môi trường thử nghiệm ổn định hơn.
  4. Bản dựng hiện tại: được sử dụng để giới thiệu và nền tảng thử nghiệm mở dành cho người dùng mới tiềm năng.

Mỗi bản dựng sẽ làm mới cơ sở dữ liệu được liên kết với nó. Một vấn đề mà tôi nghe từ những người kiểm thử là chúng ta cần điền trước dữ liệu thử nghiệm hàng tuần với một số dữ liệu thử nghiệm dự kiến, trái ngược với dữ liệu chung chung hơn. các nhà phát triển làm việc cùng. Điều này có vẻ như một mối quan tâm/nhu cầu chính đáng và là điều chúng tôi đang làm việc.

Tôi đang ném những gì chúng tôi đang làm để xem cộng đồng SO có thấy bất kỳ khoảng trống nào với những gì chúng tôi đang làm hay không có bất kỳ mối lo ngại nào. Mọi thứ dường như hoạt động tốt, nhưng nó FEELS như nó có thể tốt hơn. Suy nghĩ của bạn?

Trả lời

1

Một bước bổ sung được theo sau là khi phiên bản phát hành vượt qua các kiểm tra (s) ay smoke test) sau đó nó đủ điều kiện để xây dựng tốt (nói một bản xây dựng vàng) và bạn sử dụng một số cơ chế ghi nhãn để gắn nhãn tất cả các đồ tạo tác (mã, cài đặt tập lệnh, makefiles, có thể cài đặt, v.v.) hình ảnh vàng. Việc xây dựng vàng có thể trở thành một ứng cử viên phát hành sau này hay không.

Có thể bạn đã làm điều này, vì bạn không đề cập đến tôi đã thêm những gì tôi đã quan sát.

+0

có điểm tốt, quá trình xây dựng thực hiện các phiên bản TAG trong kho lưu trữ. – Jay

1

đây là cách chúng tôi thực hiện. DB của người kiểm tra sẽ chỉ được đặt lại theo yêu cầu. Nếu chúng tôi sẽ tự động làm mới điều này mỗi tuần thì

  1. chúng tôi sẽ mất tham chiếu đến các triệu chứng lỗi; nếu một lỗi được tìm thấy nhưng một nhà phát triển chỉ nhìn vào nó một vài tuần sau đó (hoặc đơn giản là sau cuối tuần) thì tất cả các thông báo lỗi đó có thể đã biến mất
  2. người thử nghiệm có thể đang ở giữa một trường hợp thử nghiệm lớn (lấy nhiều hơn 1 ngày chẳng hạn)
  3. chúng tôi có tấn kiểm tra đơn vị đó đang chạy chống lại một DB mà được làm mới (tự động tất nhiên) mỗi lần một hội nhập xây dựng được thực hiện

regards,
Stijn

+0

Hi Stijn, Vậy ứng dụng của người thử nghiệm được xây dựng lại thường xuyên như thế nào? Làm thế nào để bạn tự động quản lý các thay đổi cơ sở dữ liệu mà không làm mới DB? Chức năng loại "khác"? – Jay

+0

Không có tần số cố định; thường được thực hiện khi một ứng cử viên sản xuất đã được xây dựng và có một đoạn mã bị cắt. Ứng cử viên này sau đó được cài đặt trên một môi trường tích hợp hoặc QA mà DB sau đó được làm mới. Chúng tôi có một môi trường tham chiếu DB có chứa tất cả các cấu hình cần thiết và mới nhất. DB này được sử dụng một nguồn làm mới. –

0

Tôi nghĩ rằng bạn có một quy trình tốt, toàn diện, miễn là nó phù hợp với thời điểm khách hàng của bạn muốn xem nội dung cập nhật. Một khoảng trống có thể tôi thấy là có vẻ như bạn sẽ không thể sửa lỗi khách hàng quan trọng trong sản xuất trong vòng chưa đầy một tuần, vì các bản dựng thử của bạn là hàng tuần và sau đó bạn cần thời gian để người kiểm tra xác minh sửa chữa.

Nếu bạn ưa thích suy nghĩ về mọi thứ theo một cách khác, hãy xem bài viết này trên continuous deployment - có thể hơi khó để chấp nhận khái niệm lúc đầu, nhưng chắc chắn có một số tiềm năng.