Chu kỳ phát hành một tuần: làm thế nào để tôi thực hiện điều này khả thi?

Tại công ty của tôi (startup công nghiệp web 3 năm tuổi), chúng tôi thường gặp vấn đề với nhóm sản phẩm nói rằng "aaaah đây là một bản vá khủng hoảng ngay bây giờ!" (không phải mọi người sao?)

Điều này có tác động đến năng suất (và tinh thần) của nhân viên kỹ thuật, bao gồm. Ban quản lý đã dành thời gian suy nghĩ về cách giảm tần suất của các yêu cầu cùng ngày này và đưa ra giải pháp mà chúng tôi sẽ phát hành mỗi tuần. (Trước đây chúng tôi đã thực hiện hai tuần một lần, thường bị trượt trong vài ngày hoặc lâu hơn.)

Có 13 nhà phát triển và 6 người thử nghiệm địa phương / 9 thử nghiệm ngoài khơi; lý thuyết là chỉ có 4 nhà phát triển (và tất cả những người thử nghiệm) sẽ làm việc trên các bản phát hành có số chẵn, trừ khi một phần công việc xuất hiện thực sự đòi hỏi một số chuyên môn cụ thể từ một trong những nhà phát triển khác. Mỗi chu kỳ sẽ chứa hai ngày làm việc của nhà phát triển và hai ngày làm việc QA (cộng với 1 ngày phạm vi / phân chia / ...).

Câu hỏi của tôi là:

(a) Có ai có kinh nghiệm với chu kỳ phát hành dài này không?

(b) Có ai nghe nói về độ dài của chu kỳ phát hành này ngay cả khi đang cố gắng không?

(c) Nếu (a) hoặc (b), làm thế nào để bạn làm cho nó hoạt động? (Bất kỳ cạm bẫy nào cần tránh, v.v., cũng được đánh giá cao.)

(d) Làm thế nào chúng ta có thể giảm thiểu thiệt hại nếu nỗ lực này thất bại?

Bạn chắc chắn có thể giao hàng mỗi tuần - hoặc thậm chí thường xuyên hơn. Hiện tại, chúng tôi thường phát hành hai tuần một lần, nhưng không có gì bất thường khi triển khai chức năng khi có thứ gì đó đến mà không có thông báo nào từ một trong những đối tác của chúng tôi sẽ không liên quan nếu chúng tôi chờ đợi chu kỳ tiếp theo. Tại một số thời điểm trong vài tháng tới, tôi muốn chúng tôi chuyển sang giao hàng liên tục (các mặt hàng sẽ được phát hành ngay khi thực tế một khi chúng được thực hiện theo tiêu chuẩn, nhưng chúng tôi vẫn chưa đủ tự tin để thực hiện điều đó xa.

Điều quan trọng là bạn cần trang web của mình được bảo vệ mạnh mẽ bởi các thử nghiệm tự động - cả thử nghiệm đơn vị và thử nghiệm chấp nhận đầu cuối / thông số kỹ thuật thực thi. Theo ngụ ý điều này cũng có nghĩa là bản dựng của bạn hoàn toàn tự động. Ở cấp độ chấp nhận, chúng tôi sử dụng Robot Framework rất tuyệt vời để nhanh chóng xây dựng một bộ kiểm tra có thể bảo trì nhờ vào cách tiếp cận từ khóa của nó. Để xem và cảm nhận, người kiểm tra tại chỗ của chúng tôi thực hiện một số kiểm tra chữ thảo, nhưng chúng tôi cũng có một vài người ở Ấn Độ kiểm tra kỹ lưỡng hơn trên các trình duyệt khác nhau (có những trang web giúp loại điều này bằng cách chụp ảnh màn hình cho bạn, ví dụ BrowserLab ).

Chúng tôi không tự động hóa hoàn toàn việc triển khai (bước cuối cùng cần có sự can thiệp thủ công, đây là một quyết định khó hiểu đối với chúng tôi) - nhưng chúng tôi tự động hóa tất cả những điều như đảm bảo rằng các kết nối cơ sở dữ liệu chính xác đang được sử dụng, v.v., với chu kỳ triển khai ngắn thật quá dễ dàng để phạm sai lầm với loại điều này.

Có một cuốn sách gần đây khá hay về giao hàng liên tục mà bạn có thể muốn xem, tôi đã đọc lướt qua nhưng chưa đi qua chi tiết. Mặc dù vậy, những gì tôi đã đọc rất hợp với kinh nghiệm của chúng tôi: Phân phối liên tục: Phần mềm đáng tin cậy phát hành thông qua Xây dựng, Kiểm tra và Tự động triển khai

Tóm lại, bạn cần một đội ngũ có kỷ luật cao, mức độ tự động hóa cao và - quan trọng nhất trong tất cả - một mức độ tin cậy cực kỳ cao trong tự động hóa đó. Đối với tôi có vẻ như việc chuyển sang chu kỳ hàng tuần trong trường hợp của bạn có thể là một sai lầm - bản vá khủng hoảng gợi ý các vấn đề khác và bạn nên làm việc để loại bỏ những vấn đề đó. Giảm nhịp độ có thể làm cho tình hình tồi tệ hơn ...

Nếu bạn liên tục ở chế độ "phát hành khủng hoảng", tôi sẽ nói rằng sẽ khôn ngoan hơn khi lùi lại một bước và đánh giá lại mã của bạn và quy trình của bạn. Rõ ràng, có một số loại thất bại ở đó cứ lặp đi lặp lại.

Mặc dù có thể không hoàn toàn có thể làm điều này ở quy mô sản xuất thực sự, nhưng có lẽ sẽ có giá trị khi có ít nhất một thành viên cấp cao và một số tập hợp con khác của các nhà phát triển và người thử nghiệm được dành riêng cho đánh giá này.

"4 trên một cách tiếp cận" không có vẻ như là một người chiến thắng rõ ràng đối với tôi. Điều đó có nghĩa là chuyển đổi bối cảnh liên tục, có nghĩa là hiệu quả thấp hơn nhiều.

Hãy nhớ rằng, nếu bạn liên tục vội vã thực hiện các thay đổi, bạn có nhiều khả năng mắc lỗi trong những thay đổi đó và phá vỡ một thứ khác trong khi bạn đang thực hiện nó.

Chu kỳ phát hành ngắn hơn một tuần chắc chắn đã đạt được trong ngành công nghiệp phần mềm. Họ sử dụng kỹ thuật gọi là giao hàng liên tục (còn gọi là triển khai liên tục ).

Có một công ty phát hành 50 lần một ngày. Bài đăng blog này mô tả cách họ làm điều đó .

Ban quản lý đã dành thời gian suy nghĩ về cách giảm tần suất của những "công việc khủng hoảng" này và đưa ra giải pháp mà chúng tôi sẽ phát hành mỗi tuần.

Có vẻ như quản lý của bạn là nhà vô địch thế giới ... tại sao không đầu tư vào tinh thần đồng đội của bạn? Bạn sẽ thấy các vấn đề sẽ biến mất bởi themselve.

(a) + (b) IMHO, theo quy mô của nhóm của bạn, tối đa là hai tuần. Một tuần sẽ làm việc cho một người đàn ông hoặc các đội rất nhỏ (như 2 hoặc 3).

(c) + (d) Nhưng bất kể quy mô nhóm hoặc dự án của bạn, một trong những điều đầu tiên tôi làm, là tự động hóa việc xây dựng & triển khai. Tôi tiết kiệm ngày nếu không phải tuần làm việc bằng cách làm điều đó trong những ngày đầu của dự án.

Việc triển khai của bạn phải được thực hiện với một cú nhấp chuột. Từ nguồn đến dàn dựng, sau đó từ dàn dựng đến sản xuất. Có rất nhiều công cụ để thực hiện điều này có thể. Từ ant / nant đến những thứ siêu nặng như Automated Build Studio .

Mọi thứ có thể được tự động hóa từ triển khai tệp đến nâng cấp cơ sở dữ liệu, bao gồm sao lưu, thông báo, báo cáo, ...