Vì sao Squeaky không dùng môi trường staging

Vấn đề của staging

• pre-live không giống hệt production
• xuất hiện hàng đợi release
• release trở nên quá lớn
• thiếu tinh thần sở hữu đối với các thay đổi
• để cho quy trình thay thế trách nhiệm

Cách Squeaky Ship

• Chỉ merge những gì có thể đưa lên live: các thay đổi đều được kiểm thử đầy đủ trong môi trường phát triển cục bộ
• Sử dụng chiến lược branching phẳng: khi feature sẵn sàng để merge thì rebase và test. Nếu có vấn đề thì roll forward
• Các feature rủi ro cao luôn dùng feature flag
• Triển khai thủ công: liên tục theo dõi sau khi thay đổi. Monitoring/logging/alert được áp dụng xuyên suốt. Triển khai blue/green

Kết luận

• Để có CI/CD thực sự, việc từ bỏ môi trường staging có thể tạo ra một cách tư duy khác về việc shipping phần mềm
• Nếu không có vùng đệm trước khi thay đổi được đưa lên live, bạn phải chắc chắn rằng các thay đổi đó phù hợp với production
• Cần có tinh thần sở hữu và sự cẩn trọng đối với mọi thay đổi mình thực hiện
• Có thể giảm chi phí và độ phức tạp của hạ tầng, đồng thời đơn giản hóa và tăng tốc vòng đời phát triển

[edunga1]

Nghĩ đến cảm giác an tâm khi xây dựng môi trường staging trong tổ chức thì tôi thấy cũng khó mà đồng cảm hoàn toàn.
Dù vậy, tôi đồng ý với nhược điểm là việc triển khai bị chậm lại hoặc số lượng thay đổi tăng lên.

Tôi nghĩ chỉ riêng việc có tồn tại môi trường staging đã có ý nghĩa, vì nó cho phép xác nhận rằng có thể triển khai sang môi trường khác và rằng phần mềm đó đáp ứng được bản chất là có thể sao chép được.

[bichi]

Ừm, tôi cũng không rõ liệu có nên dựa vào những người có “ownership” / “sự cẩn trọng” chưa hoàn thiện hay không; ít nhất, nhận trợ giúp từ một cái máy tính có thể hoạt động hoàn hảo đúng như được chỉ định chẳng phải là điều mà một lập trình viên máy tính nên làm sao?

Và nếu mở rộng khái niệm thì staging = để phê duyệt cuối cùng (kiểm tra những thứ như có đúng với spec mà chúng ta đã bàn hay không, khi đưa dữ liệu production vào thì trông có xấu hơn mong đợi hay không, v.v.)
dev = để thảo luận về nhân sự như lập trình viên và về feature (dùng để demo)

là cách chúng tôi đang sử dụng.

[xguru]

Ừm... tôi nghĩ kiểu vấn đề này còn tùy vào bạn đang phát triển loại dịch vụ nào.
Dù có kiểm thử kỹ đến đâu thì vẫn có thể phát sinh vấn đề, và cần cân nhắc xem người dùng có thể chấp nhận điều đó hay không.
Với những phần mềm như Facebook, dù có hoạt động sai một chút thì người ta cũng có thể xem là chuyện bình thường, nên cách làm này là khả thi.
Nhưng nếu là hạ tầng mang tính mission-critical hoặc dịch vụ trả phí, thì có lẽ phải chuẩn bị thật kỹ để không xảy ra vấn đề.