Tại sao không triển khai vào thứ Sáu? [đóng cửa]

Joel đã đề cập trong podcast số 24 của StackOverflow rằng chính sách của công ty FogCreek là không gửi phần mềm vào các ngày thứ Sáu. Tuy nhiên, ông không giải thích lý do tại sao.

Tôi đồng ý. Tại nhà tuyển dụng của tôi, chúng tôi triển khai vào tối thứ Năm. Vì vậy, chúng tôi có thứ Sáu để dọn dẹp bất kỳ lỗi nào đã bỏ sót Đảm bảo chất lượng (QA).

Tuy nhiên, người quản lý của tôi gợi ý rằng chúng tôi nên triển khai vào tối thứ Sáu trong trường hợp QA không có đủ thời gian để kiểm tra phần mềm trước khi phát hành. Tôi nói, Kế hoạch cuối tuần của mọi người thì sao? Và nếu chúng tôi triển khai vào tối thứ Sáu, thì chúng tôi sẽ phải làm việc vào thứ Bảy để dọn dẹp bất kỳ lỗi nào bị bỏ sót - điều này thật tệ.

Vậy tại sao không gửi phần mềm vào thứ sáu?

* Chúng tôi có thể (không chắc) cần đưa ra giả định này: có một nhóm phát triển phần mềm cốt lõi nằm trong một múi giờ triển khai ứng dụng web cốt lõi của công ty họ.

Nó không chỉ là một vấn đề của lỗi. Có thể có các gánh nặng hỗ trợ liên quan khác - giải thích các tính năng mới cho người dùng, giám sát rằng không có vấn đề về hiệu suất.

Một bản phát hành mới nói chung sẽ có nghĩa là một hoạt động hỗ trợ tăng đột biến - vì vậy, lên lịch để điều đó xảy ra khi có ít người hơn (hoặc khi có nhiều thời gian hơn) là một ý tưởng tồi.

Không bao giờ triển khai vào thứ sáu vì:

1. Cuối tuần rồi nên mọi người bớt sắc đi
2. Bây giờ là cuối tuần nên mọi người không có mặt để sửa lỗi
3. Cuối tuần rồi nên mọi người không rảnh để trả lời câu hỏi
4. Bây giờ là cuối tuần, tại sao bạn sẽ triển khai sau đó?

Bạn đã trả lời khá nhiều câu hỏi của riêng bạn. Đó là một lý do ngắn gọn và ngọt ngào: nếu bạn giao hàng vào thứ Sáu và một lỗi xuất hiện trong quá trình sản xuất, nói chung sẽ không có ai xung quanh để sửa nó hoặc nói chuyện với khách hàng cho đến thứ Hai tuần sau. Đó là khả năng mất doanh thu vài ngày trong trường hợp xấu nhất.

Chúng tôi tránh phát hành mã vào thứ Năm hoặc thứ Sáu - không ai muốn dành thứ Sáu của họ để tìm ra các lỗi quan trọng trong nhiệm vụ và rất có thể là ngay cả khi chúng tôi tạo ra bản sửa lỗi trong 1 ngày, thì ít nhất một ngày nữa nó mới có thể được phát hành, có nghĩa là làm việc vào cuối tuần hoặc nó sẽ không cố định cho đến tuần sau.

Nó phụ thuộc vào nhóm mục tiêu của bạn. Chúng tôi chủ yếu triển khai vào các ngày thứ Sáu. Sản phẩm dựa trên trình duyệt của chúng tôi được khách hàng sử dụng trên toàn cầu, nhưng chủ yếu là trong giờ hành chính. Điều đó có nghĩa là chúng tôi không thực sự có bất kỳ thời gian nào ngoài buổi sáng chủ nhật nếu chúng tôi muốn đảm bảo rằng chúng tôi không ảnh hưởng đến bất kỳ khách hàng nào (Ấn Độ và Trung Đông không nghỉ làm vào các ngày thứ bảy), nhưng nói chung chúng tôi "thỏa hiệp" và triển khai các buổi chiều thứ sáu.

Nếu trước đây làm việc trên một trang web hẹn hò, nơi lý tưởng nhất là chúng tôi muốn triển khai nội dung mới vào khoảng thứ Ba, vì hoạt động cao điểm vào khoảng cuối tuần và kỳ lạ thay, thứ hai vào khoảng bữa trưa.

Nhưng dù sao, nó đi xuống 2 cân nhắc. 1. Khi nào thì nó ít gây gián đoạn nhất cho khách hàng của bạn (nếu đó là một ứng dụng web) và 2. Khi nào thì nó sẽ phù hợp nhất với nhóm phát triển để sửa chữa gấp các lỗi nghiêm trọng.

Nếu bạn lo lắng về việc các nhà phát triển của mình trở nên cẩu thả vào gần cuối tuần, đường dẫn QA của bạn có thể quá ngắn.

Chúng tôi thường triển khai vào các ngày Thứ Ba, sau đó chúng tôi có phần còn lại của tuần để giải quyết bất kỳ vấn đề nào. Nó cũng phụ thuộc một chút vào ngành, nếu không có việc vào cuối tuần có thể triển khai vào tối thứ Sáu nhưng nếu họ đang làm việc thì đó không phải là một ý kiến ​​hay.

Vì vậy, mọi người có xu hướng cẩu thả hơn một chút vào các ngày thứ Sáu (đã nghĩ về ngày nóng | bia lạnh | cả hai) và những ngày trước khi đi nghỉ ;-)

Nó thực sự phụ thuộc vào ứng dụng của bạn và mức độ bận rộn / quan trọng của nó vào cuối tuần.

Chúng tôi thường không triển khai phần mềm vào thứ sáu mà thường triển khai vào thứ bảy hoặc chủ nhật. Chúng tôi nhận thấy buổi sáng Chủ nhật là đặc biệt tốt để giảm thiểu tác động của việc phát hành.

Nó thực sự phụ thuộc vào việc bạn đang cố gắng giảm thiểu tác động của bất kỳ khoảng thời gian ngừng hoạt động nào mà bạn cần để thực hiện bản phát hành, HOẶC giảm thiểu bất kỳ lỗi tiềm ẩn nào.

Bạn sẽ không thấy bất kỳ lỗi nào cho đến khi khách hàng thực sự sử dụng hệ thống (trong hầu hết các trường hợp), vì vậy việc triển khai vào thứ Sáu tương đương với việc triển khai vào sáng thứ Hai, nếu bạn có mức sử dụng thấp vào cuối tuần.

Mặt khác, những thứ như mua sắm trực tuyến có xu hướng sử dụng nhiều hơn vào cuối tuần, vì vậy bạn chắc chắn không nên triển khai một trong những thứ đó vào thứ Sáu.

Nó cũng phụ thuộc vào chính sách hỗ trợ ngoài giờ của bạn. Nếu bạn nhờ ai đó có thể khôi phục phần mềm, thì rủi ro sẽ ít hơn. Tuy nhiên, tôi vẫn muốn làm điều đó trong tuần làm việc.

Chúng tôi thường triển khai nội dung thứ ba-thứ năm, ưu tiên tránh thứ Hai (ngày bận rộn nhất của chúng tôi) và cuối tuần (khi một lỗi có thể không được chú ý gây ra sự cố)

Bạn nên triển khai vào thứ Sáu để bạn có cả ngày cuối tuần để dọn dẹp nó và sửa lỗi trước khi các thành viên còn lại trong nhóm nhận thấy những sơ suất của bạn vào thứ Hai.

Tôi sẽ không bao giờ lên kế hoạch triển khai vào ngày thứ sáu trừ khi tôi cũng dự định có mặt tại văn phòng vào thứ bảy để xác minh rằng nó hoạt động chính xác, nếu bạn kết thúc triển khai vào ngày thứ sáu vì trượt giá, bạn có nguy cơ rất cao phải gấp rút mọi việc, tốt hơn hết là hãy chờ đợi , để mọi người bình tĩnh vào cuối tuần rồi giao hàng vào thứ Hai sau khi xem xét buổi sáng.

Nếu việc triển khai của bạn diễn ra vào cuối tuần thì bắt đầu từ đêm thứ sáu có thể giúp bạn khởi đầu thuận lợi vì thường văn phòng sẽ dọn dẹp sớm hơn một chút, do đó tải tổng thể của hệ thống sẽ thấp hơn so với sáng thứ Hai.

Tôi đã làm việc với một công ty có chính sách triển khai vào các ngày thứ Sáu; họ đã ở Israel và thứ Bảy thường là ngày cuối cùng của tuần làm việc. Dù sao...

Tại công ty cuối cùng của tôi, chính sách là cung cấp cho Ops gói triển khai không muộn hơn giờ ăn trưa vào các ngày Thứ Ba và Thứ Năm. Điều này có nghĩa là họ có nửa ngày để gỡ bỏ và yêu cầu điều chỉnh nhỏ nếu có bất kỳ vấn đề gì xảy ra với giai đoạn cuối của QA trước khi phát trực tiếp. (Mọi QA khác có thể xảy ra vào bất kỳ thời điểm nào trong tuần vì nó không trực tiếp.)

Phát hành vào bất kỳ môi trường nào ngoại trừ phát trực tiếp là được vào bất kỳ lúc nào, nếu Ops có thời gian để làm điều đó (tất nhiên, điều đó nên được đặt trước dù sao) nhưng không bao giờ phát hành để sống tiếp:

Thứ hai- Thật tồi tệ, bạn vừa trở về (hy vọng là một ngày cuối tuần không làm việc) và sẽ không có mọi thứ bạn đã làm tuần trước trong tâm trí của bạn. Thứ tư- Thường là ngày làm việc kém hiệu quả nhất trong tuần và được coi là ngày "giữa công việc". Nếu vị trí của bạn là Thứ Ba và bạn bỏ lỡ nó do lỗi, Thứ Tư có thể là một lựa chọn tồi vì bạn không cung cấp đủ thời gian để sửa và kiểm tra những lỗi đó. Thứ sáu- Nào. Nghiêm túc? Hôm nay là thứ sáu. Nếu điều này thực sự cần giải thích thì bạn không đủ kinh nghiệm để làm loại vị trí quản lý mà bạn đang đảm nhiệm. Nhưng nghiêm túc mà nói, đó là vì triển khai vào các ngày thứ Sáu có nghĩa là bạn tình nguyện đến khách hàng của bạn vào cuối tuần để kiểm tra trực tiếp công việc của bạn. Môi trường. Đối với tôi, điều đó đánh bại bất kỳ sự ngu ngốc nào mà bạn có thể đang tự xếp hàng cho mình.

Chúng tôi đủ may mắn để tận dụng tốt chênh lệch múi giờ, chúng tôi có các văn phòng trải dài khắp thế giới. Do đó, khi thực hiện cập nhật cho khách hàng, chúng tôi sắp xếp nó để nó được thực hiện qua đêm cho khách hàng để giảm thiểu tác động đến họ.

điều này hoạt động tốt khi bạn kiểm soát việc triển khai và triển khai phần mềm của mình nhưng việc phát hành trên một trang web hoàn toàn là một động vật khác. Như những người khác đã chỉ ra, hãy đảm bảo rằng bạn dành thời gian cho:

1. Hỗ trợ các lỗi và lỗi có thể xảy ra
2. Hỗ trợ người dùng trong quá trình chuyển đổi
3. Các bản sửa lỗi nóng vào phút trước