Mấy bữa trước ngồi chia sẻ cho một bạn BA mới vào làm mảng blockchain nắm thêm các môi trường phát triển phần mềm, nên sẵn có dịp viết lại để chia sẻ đến mọi người, có vẻ nó sẽ là kiến thức khá cũ với mọi người, nhưng đôi lúc bạn phân vân không biết được testing environment và staging environment khác nhau như thế nào, hay thỉnh thoảng lại bảo dev là “Deploy lên cho mình test với” thì dev hỏi lại “Deploy lên môi trường nào?”, hoặc thậm chí là bạn không biết khi nào gọi tên môi trường cho đúng và phù hợp, hi vọng dưới góc nhìn của một BA sẽ giúp bạn hiểu các môi trường này và áp dụng, triển khai nó một cách an toàn, hiệu quả.

Các môi trường trong phát triển phần mềm

Những môi trường mà mình nhắc đến trong bài viết hôm nay sẽ gồm có: Localhost (Development), Testing, Staging, Production, Sandbox, và một môi trường có thể hơi hơi lạ với một số người là Pilot, Devnet, Testnet.

Trước hết cho cái hình để bạn dễ hình dung hơn

Môi trường Development/Localhost:

• Môi trường này là môi trường người Dev dựa theo tài liệu của BA và xây dựng tính năng trên máy của tính (local) của họ, người khác không thể truy cập server ngoài họ.
• Database kết nối: Là database test, hoặc sandbox (tẹo mình sẽ giải thích sandbox là gì)
• Người thực hiện test:
  • Người thực hiện test trên môi trường này chính là người Dev luôn, hoặc là một người Dev khác họ pull code về và chạy thử, test lại tính năng.
  • Đôi lúc team test nội bộ sẽ pull code của Dev xây dựng xong về test trên máy local của team test nội bộ luôn, nhưng mình nghĩ này có nhưng ít.
• Vai trò của BA: Thường là hỗ trợ giải thích tính năng, nghiệp vụ, kiểm thử tính năng mới/hoặc bug fixed.

NOTE: BA cũng được xem như một phần của team test nội bộ

Môi trường Testing:

• Môi trường này thường là môi trường được đội ngũ team test nội bộ chạy kịch bản kiểm thử đã được thiết kế trước, giúp tìm lỗi và sự cố trong phần mềm, đảm bảo chất lượng phần mềm trước khi lên những môi trường tiệm cận production, hoặc production.
• Còn về phần dev thì xem thử mấy tính năng họ code có tích hợp được với code có sẵn hay code của người khác chạy được trơn tru hay không?
• Database kết nối: Là database test hoặc sandbox
• Người thực hiện test:
  • Người thực hiện chính là nhóm kiểm thử nội bộ
  • Dev đôi lúc sẽ vào test để kiểm tra lỗi có bị như nhóm kiểm thử nội bộ đã report hay không.
• Vai trò của BA: Thường là hỗ trợ kiểm thử, review bugs, đứng ra làm việc giữ tester và dev để xác nhận bug là bug thật hay có thể bỏ qua, giải quyết tranh cãi giữa họ, có thể dùng môi trường này để UAT (một số trường hợp).

Môi trường Staging:

• Cũng là môi trường test nhưng tập trung vào phần tương thích và ổn định của phần mềm trước khi triển khai, môi trường này gần như sát với môi trường production.
• Database kết nối: Là database test hoặc sandbox, đôi lúc có thể cắm trên database production hoặc là lấy database production clone ra và đổi hay dấu đi những thông tin nhạy cảm như email, số điện thoại, id nhận notification,…
  • Tại vì khúc này môi trường cần gần giống với production để khi go live tránh xảy ra lỗi hoặc sự cố không đáng xảy ra nên cần phải có configuration/phần cứng, service tương tự với production.
  • Có những cái khi mà dev chạy trên local/testing env thì thấy ngon nghẻ, nhưng đẩy lên production cái sinh ra lỗi => Cũng là một lý do để có môi trường staging để tạo cơ hội cho dev tìm lỗi liên quan đến configuration, tính tương thích với phần cứng.
• Người thực hiện test:
  • Người thực hiện chính là khách hàng hoặc nhóm kiểm thử nội bộ
  • Dev kiểm tra lỗi do KH hoặc tester report.
  • Đôi lúc vẫn có thể cho một số nhóm user đặc biệt test cùng (kiểu như sài thử và đưa ra feedback)
• Vai trò của BA: UAT, follow nắm thông tin từ khách hàng khi họ test, trao đổi nghiệp vụ nếu cần, review lại bugs, confirm một số bugs có tranh cãi.

Môi trường Production:

• Là môi trường chạy thật với người dùng và dữ liệu thật
• Database kết nối: Là database thật.
• Người thực hiện test:
  • Tester thực hiện test khi release sản phẩm
  • Dev kiểm tra lỗi do người dùng cuối report
  • BA follow hoặc kiểm tra lỗi do người khác report.
  • Người dùng cuối sử dụng
• Vai trò của BA: Tương tác với người dùng cuối hoặc nhận thông tin từ bên khác liên quan đến lỗi, giải quyết vấn đề phát sinh, hỗ trợ người dùng, hoặc phân tích dữ liệu/ux để tìm ra những giải pháp tốt hơn cho phần mềm.

Môi trường Pilot:

• Môi trường này mình mới biết từ năm 2019 khi làm các dự án liên quan đến banking.
• Là môi trường chạy thật với một nhóm người dùng đặc biệt và dữ liệu thật, nhóm này sẽ đưa ra các nhận xét góp ý cho ứng dụng.
• Thường thì Pilot sẽ nằm sau giai đoạn UAT và trước khi lên production
• Test trên thời gian thực để tìm ra lỗi.
• Không phải dự án nào cũng có môi trường này
• Database kết nối: Là database thật.
• Người thực hiện test:
  • Nhóm người dùng cuối đặc biệt được lựa chọn sẵn để sử dụng trước sản phẩm.
  • Nhóm kiểm thử team nội bộ và khách hàng.
• Vai trò của BA: Tương tác với nhóm người dùng đặc biệt để thu thập phản hồi, ý kiến góp ý, từ đó giải quyết các vấn đề phát sinh.
• Đây cũng là một môi trường xác minh tính sẵn sàng của dự án, nên mọi thứ giống y chang production, chỉ khác là cho một nhóm người sài, những người dùng cuối khác chưa được sài.

Môi trường Sandbox:

• Sau khi xem xét thì thấy Sandbox không nên xếp vào nhóm của Localhost, testing, staging, pilot, production, mà nó là 1 kiểu thể loại khác.
• Có thể hiểu nó là môi trường thật dùng thử, thường được sài cho những hệ thống liên quan đến tiền bạc, tài chính, payment
• Vì là dùng thử nên nó là database thử (test) chứ không phải database thật, hoặc là clone từ thật ra, chỉ cần thay đổi endpoint (api) thì sẽ có thể giúp phần mềm hoạt động trên môi trường real.
• Nếu không có sandbox thì khi test có thể khó cover nỗi những tính năng liên quan đến tiền thật.
• Mình thấy nó khi làm blockchain, hoặc banking, billing, AAS, payment gateway.
• Một số tên khác
  • Testnet/Devnet: Môi trường test/sandbox của một blockchain
  • Goerli, Sepolia: Môi trường testnet/sandbox của Ethereum.

Lưu ý khi làm việc trên các môi trường khác nhau.

• Không nên để khách hàng vào môi trường testing, sau khi mình làm với rất nhiều khách hàng cho thấy để KH vào môi trường test họ sẽ thấy những cái không hay, hoặc có khi họ không hiểu mình đang làm gì và tưởng là mình đang làm sai yêu cầu, hoặc gây ảnh hưởng đến quá trình test của team nội bộ khi KH vào và thay đổi một số cấu hình.
• Ở môi trường local host -> Có những trường hợp cần chạy cronjob liên tục hay sửa database sướng hơn trên môi trường testing (dù trên testing env vẫn thực hiện được nhưng đôi lúc gặp khó khăn)
• Chia thành nhiều môi trường testing hoặc kế hoạch release trên testing env theo từng giai đoạn để tránh bug nó bị lộn xộn, ví dụ như báo bug xong dev fix và đẩy ngay lên testing mà không báo, hoặc 2-3 testers nhảy vào test chung 1 môi trường nhưng lại thay đổi DB có ảnh hưởng lẫn nhau, làm cho kết quả test bị rối hoặc bị sai.
• Điều quan trọng là phải có môi trường Testing độc lập để không ảnh hưởng đến các môi trường khác và giúp dev tập trung vào việc tìm lỗi và sửa chúng, chứ đụng lỗi cái báo và fix liền, xong deploy lên test liền thì không hay.
• Môi trường Staging, Pilot đôi lúc không cần thiết phải có mà có thể gộp lại thành môi trường testing thôi, lý do chính là khá tốn chi phí, tài nguyên khi phải cần gần giống với môi trường production.
• Khi test ở Pilot hoặc Staging, BA cần kiểm tra lại với các thành viên khác vì có dính tới database thật, có thể sẽ gửi những kết quả test đến cho người dùng thật, do đó nên phân nhóm người dùng được nhận hoặc thay đổi email/phone thật thành những dữ liệu test.
• Đối với môi trường Pilot, luôn phải có một kế hoạch liên quan đến việc Rollback release để khi có trường hợp xấu sẽ xử lý được.

Kết bài.

Với những chia sẻ của mình hi vọng các bạn hiểu được từng môi trường phát triển phần mềm, cũng như nhiệm vụ và trách nhiệm một BA làm việc trong từng môi trường, sẽ có những thay đổi trong tên gọi của môi trường, hay trách nhiệm của người làm BA trong từng dự án, công ty khác nhau.