Nhiều team thường bỏ qua môi trường xung quanh staging khi phát triển ứng dụng. Họ thường submit một pull request (PR), chạy test bằng CI, merge vào master và rồi deploy lên production. Đây là một quy trình khá nguy hiểm vì không có việc test tích hợp nào được thực hiện. Tệ hơn nữa là nếu có lỗi thì họ tiếp cận bằng phương pháp fix trực tiếp ở môi trường xung quanh production.

Bạn Đang Xem: Tầm quan trọng của môi trường staging

Trong nội dung bài viết này, tất cả chúng ta sẽ cùng thảo luận về lợi ích của việc sử dụng môi trường xung quanh staging trong vòng đời phát triển phần mềm, và cách chúng góp phẩn đảm nói rằng sản phẩm sẽ tiến hành deliver đến production đúng như mong đợi.

I. Môi trường tự nhiên staging là gì?

Môi trường tự nhiên staging là môi trường xung quanh mà bạn deploy trong quá trình phát triển phần mềm. Bạn deploy đến môi trường xung quanh staging trước lúc deploy lên production.

Môi trường tự nhiên staging thường y chang môi trường xung quanh production. Điều này còn có tức thị chúng có cùng phần cứng, phần mềm và config, tóm lại là càng giống thì giá trị của staging càng cao.

Mức độ giống nhau giữa staging và production đảm nói rằng việc test trên môi trường xung quanh staging sẽ phả ánh đúng những gì xẩy ra trên production với cùng tham dự.

Không như môi trường xung quanh phát triển hoặc tích hợp, môi trường xung quanh staging sử dụng cùng service back-end cũng như các service khác. Chúng có cùng kiến trúc, cùng một kiểu scale, và các thông số cấu hình.

Tùy vào các nhân tố quy định (chẳng hạn yêu cầu GDPR) và khả năng che giấu tài liệu của tổ chức, môi trường xung quanh staging thường ẩn danh hoặc là bộ tài liệu hoàn chỉnh của production để gần hơn với môi trường xung quanh production trong thế giới thực. Điều này còn có tức thị môi trường xung quanh staging không được release hoặc open cho tất cả những người dùng ở production, mà nó chỉ sẵn có ở nội bộ tổ chức hoặc một số lượng người dùng nhỏ.

Để kiểm soát ngân sách, chúng ta có thể deploy môi trường xung quanh staging như một phần của vòng đời release và phá bỏ sau lúc release được chuyển đến production.

Phương thức này cho bạn khả năng để phát hiện vấn đề về code quality, vấn đề tài liệu ở tầm mức cao, vấn đề về tích hợp và các vấn đề liên quan mà không thể đơn giản được thể hiện ở môi trường xung quanh test tích hợp hoặc môi trường xung quanh thấp hơn như development hoặc local.

Phương thức này cũng được chấp nhận bạn dự đoán ở tầm mức xác thực cao, rằng việc deploy lên production có thành công hay là không, cũng như trả lời các vướng mắc dạng “service mới thêm vào có hoạt động trên production hay là không?”…

Thao tác làm việc với môi trường xung quanh staging buộc bạn phải kiểm tra tất cả những giả thiết mà bạn đưa ra trong quá trình phát triển và đảm báo rằng bạn đã xử lý để kiên cố để deploy thành công.

II. Nguy cơ của việc deploy mà không có staging

Xem Thêm : Nor trong Liên Quân là gì? Tổng hợp thuật ngữ trong Liên Quân | Ingoa

Việc test ở local hoặc chạy unit test không phải là một cách tốt để kiểm trả chất lượng sản phẩm và dịch vụ và chức năng sản phẩm. Unit test được viết bởi người, mà người thì luôn có thể mắc lỗi. Nếu như bạn chỉ test những vấn đề đã biết trước, thì bạn không thể cover những vấn đề mà bạn không biết.

Người ta thường quên rằng việc thay đổi có thể ảnh hưởng tác động tới các service khác hoặc chức năng khác. Đôi lúc một thư việc bạn sử dụng ở local có thể không hoạt động được ở cloud, và chỉ khi deploy lên production thì bạn mới phát hiện.

Thông thường thì bộ tài liệu dùng để làm test ở môi trường xung quanh thấp cấp đều là giả thiết về những cái ở production. Một số người nghĩ rằng staging là không cấp thiết vì lỗi sẽ tiến hành phát hiện sớm, nhưng rõ ràng bạn đang làm user gặp bug và lỗi cấu hình.

Nói chung, việc thay đổi có thể ảnh hưởng tác động tài liệu ở production, và có thể ảnh hưởng tác động đến cả những service liên quan.

Dựa vào niềm tin và hy vọng như một phương pháp để đảm bảo deploy lên production thành công kiên cố sẽ có được nguy cơ tạo ra nhận thức tiêu cực về chất lượng sản phẩm và dịch vụ sản phẩm của bạn và cuối cùng dẫn đến mất lợi nhuận, mất khách hàng và có thể vi phạm quy định hợp đồng với khách hàng của bạn.

giá tiền liên quan đến việc deploy hoặc code lỗi gồm có:

• Phải hotfix
• Rollback release
• Tác động ảnh hưởng đến schedule
• Khả năng mất tài liệu
• Tác động ảnh hưởng đến người dùng
• Vi phạm hợp đồng
• Rủi ra tăm tiếng / thương hiệu
• Mất doanh thu
• Mất khách hàng

Lợi ích bạn nhận được từ việc sử dụng môi trường xung quanh staging là mức độ đảm bảo chất lượng sản phẩm và dịch vụ lơn hơn và sự hài lòng của khách hàng. Ngoài ra, bằng phương pháp giảm tác động hoặc số lỗi trong sản phẩm, chúng ta có thể tiết kiệm ngân sách và chi phí rất nhiều ngân sách. Ví dụ: chúng ta có thể giảm lượng thời kì bạn phải chi ra để rollback, hoặc giảm thời kì cung cấp các hotfix kịp thời mà có thể ảnh hưởng tác động đến chu kỳ luân hồi phát triển. Bạn cũng tiết kiệm ngân sách và chi phí ngân sách cho những sự cố có thể xẩy ra trong quá trình sinh sản và thời kì trả lời các vướng mắc của người dùng hoặc viết báo cáo giải trình lỗi.

III. Ba kịch bản thế giới thực

Hãy cùng điểm qua một số kịch bản tiềm tàng có thể tránh khỏi nếu như bạn sử dụng môi trường xung quanh staging. Chúng tôi đang phát triển một ứng dụng gọi là Bitcoin Price Index. Đây là một ứng dụng React đơn giản, kết nối người dùng với CoinDesk API để cung cấp thông tin về xu hướng giá của bitcoin dựa theo đơn vị tiền tệ được lựa chọn.

1. Sai service URLs

Ở kịch bản trước nhất, trong những khi phát triển ở môi trường xung quanh thấp cấp (local/development), chúng tôi trỏ ứng dụng đến một mock service của CoinDesk API để giảm ngân sách và lưu lượng. URL này nên trỏ đến CoinDesk API thực tế trước lúc deploy lên production.

Như bạn thấy, mock URL bằng phương pháp nào này đã lẫn vào trong code.

Thay đổi này thao tác làm việc trơn tru ở môi trường xung quanh dev. Trong môi trường xung quanh staging, service liên quan không nên ở đó, và sự thay đổi này nên được bắt lỗi trước lúc lên production.

Đây là giá trị cơ bản của môi trường xung quanh staging: giữ các thay đổi không apply trực tiếp lên production bằng phương pháp cung cấp một môi trường xung quanh để test và validate.

2. Lỗi ở source control và review

Hãy xem một ví dụ khác: 2 developer commit chức năng mới mà có cùng file, nhưng khác ở dòng CSS. Ở mỗi nhánh riêng của developer, style và sản phẩm đúng như mong đợi.

Thay đổi được merge và deploy lên production.

Xem Thêm : Công Nghệ In Trực Tiếp Lên Áo Thun (DTG) Là Gì ?

Tuy nhiên, khi mỗi developer tạo pull request để merge vào development, style bị chèn lẫn sẽ không còn được show ra trong quá trình review vì chúng nằm ở cả 2 pull khác nhau. Chúng được merge sai và deploy lên production. Kết quả là sản phẩm có một trạng thái không mong muốn.

3. Các service liên quan

Cuối cùng, hãy cùng đào sâu vào trong 1 phát biểu thân thuộc của developer: “nó chạy trên máy em”

Ở đây một developer thêm imagemagick đến stack để xử lý ảnh upload. Những thư viện npm liên quan đến imagemagick được thiết lập và lưu vào package.json, nhưng “imagemagick-cli” chỉ được cài ở máy developer.

Vậy nên những khi test ở local thì chức năng hoạt động xác thực, nhưng khi đưa lên production thì không.

*Error: Command failed: CreateProcessW: The system cannot find the file specified*

Không có môi trường xung quanh staging, những kiểu vấn đề như vậy này sẽ rất dễ xẩy ra.

Thực tế là tất cả những ví dụ này đều là những sai trái hoàn toàn có thể phòng tránh khỏi. Những sai trái này xoành xoạch xẩy ra, và có thể không bị tóm gọn trước lúc lên production nếu không có một môi trường xung quanh staging. Khi ứng dụng của bạn trở thành phức tạp, tiềm năng cho những loại lỗi này cũng tăng theo cấp số nhân.

Sử dụng một môi trường xung quanh staging như một phần của vòng đời deploy có thể giảm nguy cơ xẩy ra những lỗi này.

IV. Môi trường tự nhiên staging không cần phức tạp

Một lý do thường thấy để không sử dụng staging là chúng phức tạp hoặc tốn ngân sách. Có một sự thực là nó thêm ngân sách, và devops trở thành tốn kém, và môi trường xung quanh staging rất khó để thiết lập như môi trường xung quanh production. Tuy nhiên, nó không cấp thiết phải như vậy.

Các cloud platform văn minh được chấp nhận bạn sử dụng staging khi cần, và tự động hóa quá trình deploy. Chúng giúp cho bạn tránh khỏi những lỗi mà ảnh hưởng tác động đến production.

Một cách khác là tự động hóa deploy lên staging gồm có các thông tư về infra và ảo hóa như Kubernetes.

Nếu không có quy trình tự động hóa, ta cũng có thể có thể sử dụng máy móc giống với production để deploy thủ công.

Điều cuối cùng, sử dụng staging giúp cho bạn nắm bắt được những phương thức phát triển phần mềm văn minh để cải thiện năng suất của team. Quan trọng hơn, nó giúp cải thiện chất lượng sản phẩm và dịch vụ sản phẩm bạn gửi đến cho khách hàng.

Tham khảo: https://hackernoon.com/staging-environments-are-overlooked-heres-why-they-matter-5jp2gm0