Quy trình triển khai phát triển nhanh. QA và Chủ doanh nghiệp kiểm tra ở đâu?


9

Gần đây tôi đã đọc rất nhiều về các quy trình triển khai ứng dụng web khác nhau bằng SVN hoặc GIT, với mục đích thiết kế lại cách chúng tôi hiện đang triển khai ở nơi tôi làm việc.

Giống như nhiều hương vị của Agile, người ta cho rằng mọi thứ cam kết với chủ hoặc thân cây đều sẵn sàng sản xuất. Cả GitHub và Etsy, http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/ đều nói rằng họ làm việc trên cơ sở này (mặc dù Etsy thực sự có môi trường dàn dựng).

Quá trình này giả định tất cả các bài kiểm tra đơn vị và kiểm tra CI đã được chạy. Bạn chạy thử nghiệm cục bộ và trên CI và sau đó cam kết trung kế. Vì vậy, tại thời điểm này mã của bạn là kỹ thuật âm thanh.

Mã của bạn có thể đúng về mặt kỹ thuật, nhưng kiểm tra người dùng / chức năng có thể phát hiện ra nhiều lỗi hơn, đặc biệt là khi kiểm tra giao diện người dùng.

Câu hỏi của tôi là này. Các chủ sở hữu QA và Business kiểm tra các thay đổi tính năng bạn đã triển khai ở đâu? Trên máy phát triển cục bộ của bạn trước khi bạn cam kết trung kế hoặc trên máy QA / dàn?

Nếu bạn có một máy dàn chạy hết thân cây và bạn cho rằng tất cả các mã được cam kết với thân cây đã sẵn sàng sản xuất ... eh .. thì tại thời điểm nào thì mã được ký tắt và tốt để đi vào sản xuất từ ​​cả kỹ thuật và kinh doanh Góc nhìn cá nhân? Nếu bạn chỉ có một máy dàn, nhiều nhà phát triển và đó là nơi mã sẽ là QA, thì làm thế nào bạn có thể triển khai từ trung kế vì nhiều thay đổi của nhà phát triển có thể đang chờ đăng nhập.

Tôi có muốn nghe làm thế nào những người khác đã tiếp cận điều này?

Câu trả lời:


6

Để tốt hơn hoặc tồi tệ hơn, tôi thường thấy điều này được thực hiện trong đó thử nghiệm được thực hiện đối với cơ sở chi nhánh và dấu hiệu kinh doanh là điểm kiểm tra để hợp nhất với chính triển khai.

Tôi đã thấy điều này được thực hiện cả khi phát triển trên "chính" với một nhánh "được triển khai" riêng biệt hoặc một nhánh "tính năng" phát triển với một chính là "được triển khai".

quy trình làm việc kết thúc giống như thế này:

  • mã cái gì đó
  • chạy thử nghiệm cục bộ
  • kiểm tra chi nhánh làm việc
  • (tùy chọn) xây dựng máy chủ xây dựng các bài kiểm tra kiến
  • QA / Thử nghiệm kinh doanh
  • sửa lỗi (lặp lại từ đầu đến đầu)
  • hợp nhất để triển khai chi nhánh
  • triển khai

Một số người làm việc trong một chi nhánh duy nhất, nhưng nếu bạn sẽ có bài kiểm tra thủ công gặp khó khăn. Hầu hết những người tôi gặp phải đều cho rằng mọi thứ có thể được triển khai theo cam kết cũng hoạt động trong một thân cây đang làm một việc gì đó nhỏ hoặc có số lượng thử nghiệm tự động rất lớn, HOẶC họ xem xét "triển khai" trong cuộc trò chuyện này là bản dựng cho máy chủ thử nghiệm và quá trình QA xảy ra giữa máy chủ thử nghiệm và sản xuất được xử lý riêng.


Cảm ơn Bill. Chúng tôi làm việc trong một môi trường nơi các nhà phát triển liên tục cam kết và triển khai các phần chức năng riêng biệt cho trang web. Nếu làm việc trên một nhánh tính năng, sau khi kiểm tra trong nhánh làm việc, bạn thấy kiểm tra QA / Business ở đâu? Nếu bạn chỉ có một máy QA mà nhà phát triển cam kết chi nhánh, thì thực tế chỉ có một tính năng có thể được kiểm tra tại một thời điểm, trừ khi bạn có thể có một trang web và phiên bản riêng của máy chủ ứng dụng được thiết lập cho mỗi nhà phát triển trên máy QA, vì vậy những thay đổi có thể được kiểm tra trong sự cô lập trước khi cam kết thân cây.
Bazza

Theo kinh nghiệm của tôi, điều này thường là chúng tôi đã không tạo một nhánh tính năng riêng cho từng nhà phát triển, giống như một nhóm cho mỗi nhóm và chúng tôi đã thiết lập một máy chủ qa cho mỗi người ngay cả khi đó chỉ là một máy phát triển thêm.
Hóa đơn

Đánh giá cao các ý kiến. Đã cho tôi một số ý tưởng.
Bazza

2

Chúng tôi có các bài kiểm tra chấp nhận tự động trên cùng một nhánh tính năng. Khi bạn tạo một ứng cử viên phát hành, nó bao gồm các bài kiểm tra tự động mà bạn đã chạy để xem tính năng này có vượt qua không. Bạn cũng kiểm tra các ứng cử viên phát hành. Khi mọi thứ trôi qua, bạn thúc đẩy nó sau đó bằng cách hợp nhất thành chủ.

Thêm về quá trình này ở đây:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

Hãy kiểm tra các ý kiến ​​là tốt.

Hi vọng điêu nay co ich,

Ađam


@Adam - Cảm ơn vì điều đó, và liên kết. Các cuộc thảo luận ở đó là thú vị. Thức ăn cho suy nghĩ.
Bazza

0

Theo nguyên tắc chung, chờ đợi để cam kết trước khi mã hoàn hảo là một nửa thời gian lấy lại những lợi thế của hệ thống kiểm soát phiên bản. (Không cần giải thích nhiều, tôi sẽ nói rằng trừ khi một người được phép đăng ký nhiều lần vào VCS, thì người ta không có cách nào để hoàn nguyên công việc của riêng tôi!) hoặc nó có thể là các cam kết cục bộ trong trường hợp GIT) nhiều như họ muốn. Trong thực tế càng nhiều càng tốt.

Tuy nhiên, khi điểm đến nơi mọi thứ dường như được thực hiện và kiểm tra - chúng tôi gọi đó là một bản phát hành và sau đó nó được hợp nhất với thân cây. Về cơ bản, QA có thể chứng nhận RC bằng cách kiểm tra mới trên HEADchi nhánh và nếu anh ấy / cô ấy là Okey, điều tương tự sẽ được hợp nhất trở lại với thân cây.

Vì vậy, về cơ bản chúng tôi sử dụng khái niệm về nhánh nhiệm vụ hoặc nhánh riêng để mọi người có thể tự do thực hiện đăng ký nhiều như họ cần. Đồng thời, thân cây là tương đối miễn phí từ bất kỳ đăng ký bị hỏng .

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.