Các môi trường phát triển phần mềm (Dev, Test, Staging, Production) BA cần biết

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

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 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í nữa 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ĩ cái 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 đã fix.

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ữa 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).

Nói thêm cho bạn mới: nghe "BA xác nhận bug thật hay bỏ qua" thì đừng tưởng ngày đầu đi làm bạn đã có quyền chốt. Việc của bạn lúc đó là gom cho đủ bốn thứ — đúng ra phải chạy thế nào, thực tế đang chạy thế nào, ảnh chụp hoặc video làm bằng chứng, và lỗi này ảnh hưởng tới ai — rồi đưa cho người đang chịu trách nhiệm chốt bug trong dự án. Gom đủ bốn thứ đó thì cuộc tranh cãi giữa tester và dev thường tự hết, chẳng cần bạn phân xử.

Môi trường Preview: mỗi nhánh code một đường link riêng

Hồi mình viết bài này lần đầu thì cái này còn hiếm, giờ thì gặp khá thường. Nói nhanh mấy chữ dev hay dùng để bạn khỏi khớp: mỗi người làm một tính năng trên một nhánh code riêng, làm xong thì gộp nhánh đó vào code chung, còn CI/CD là cái dây chuyền tự động chạy build và đẩy code lên máy chủ thay cho việc dev bấm tay.

Preview là khi dây chuyền đó dựng cho mỗi nhánh một bản chạy riêng có đường link riêng, gộp code xong thì tự xoá. Với BA thì tiện ở chỗ xem được tính năng ngay lúc dev vừa làm xong, không phải chờ tới đợt deploy lên testing. Nhưng đừng tưởng cứ khác link là khác hẳn nhau: nhiều chỗ các bản preview vẫn dùng chung một database, chung một backend, chung dịch vụ bên ngoài, nên hai người test song song vẫn có thể đá dữ liệu của nhau. Hỏi dev một câu "bản này dùng database riêng hay chung" là biết. Dữ liệu trong đó cũng thường trống hoặc dựng tạm, nên coi preview là chỗ xem trước, đừng lấy nó thay cho một vòng kiểm thử tử tế.

Chuyện có sẵn hay không thì tuỳ chỗ: GitLab có sẵn Review Apps, Vercel có Preview Deployments, còn GitHub Actions chỉ là công cụ chạy tự động, muốn có link preview vẫn phải cấu hình nơi deploy. Hỏi dev một câu là rõ. Có một chỗ đáng để ý: khi đã chạy CI/CD thì code gộp vào nhánh nào sẽ tự lên môi trường tương ứng, nên câu "deploy lên cho em test với" nhiều lúc không còn đúng nữa, hỏi "code gộp vào nhánh nào rồi" thì nhanh hơn.

Môi trường Demo/POC

Hai chữ này hay bị gộp làm một nhưng khác nhau. Demo là bản riêng để sale hoặc BA đem đi trình bày cho khách: dữ liệu được dọn sẵn cho đẹp, kịch bản chạy trơn từ đầu tới cuối. Còn POC (proof of concept) là bản dựng nhanh để kiểm chứng một giả định, kiểu "cái này có làm được không", "nối được với hệ thống kia không" — nó có thể xấu và thiếu tùm lum, làm xong là bỏ, đem đi demo cho khách là hớ.

Demo hay bị nhầm với staging. Khác nhau ở mục đích: staging dựng ra để tìm lỗi trước khi go live, còn demo dựng ra để cho người ta xem. Đừng demo trên staging, vì lúc đó tester đang test, dữ liệu đổi liên tục, đang trình bày mà màn hình trống trơn hoặc văng lỗi thì rất mệt.

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. Muốn dữ liệu gần giống thật thì lấy database production clone ra rồi che đi những thông tin nhạy cảm như email, số điện thoại, id nhận notification… Chỗ này mình muốn nói rõ một câu: đừng cắm thẳng staging vào database production. Nó tiện thật, nhưng chỉ cần một lần ai đó bấm nhầm nút gửi thông báo trong lúc test là khách hàng thật nhận được tin nhắn test, chưa kể dữ liệu thật có thể bị sửa mà không ai hay. Che dữ liệu ở đây tiếng Anh gọi là masking, hiểu đơn giản là thay email, số điện thoại thật bằng dữ liệu giả trước khi đưa cho môi trường test xài.
• 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ó cấu hình, phần cứng, dịch vụ đi kèm tương tự với production. Nói cho dễ hình dung: cùng loại server, cùng khoá API, cùng cổng thanh toán, cùng dịch vụ gửi mail — chỉ khác là bản dành cho môi trường thử.
• Có những cái khi mà dev chạy trên local hoặc 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ách hàng 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ư xà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.

UAT là một loại kiểm thử, không phải một môi trường

Chỗ này bạn mới hay lẫn, vì đi làm sẽ nghe người ta nói "môi trường UAT" như thể nó là môi trường thứ bảy.

UAT (User Acceptance Testing) là việc khách hàng hoặc người dùng nghiệm thu xem phần mềm có đúng cái họ cần không. Nó là một hoạt động kiểm thử, và hoạt động đó phải chạy ở đâu đó: thường là staging, đôi khi là pilot, dự án nhỏ thì chạy luôn trên testing. Nên khi nghe "môi trường UAT", cứ hiểu là "cái môi trường mà dự án này dùng để chạy UAT" rồi hỏi lại cho rõ là môi trường nào, đừng đi tìm một loại môi trường mớ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.

Deploy và release không phải một: feature flag, canary

Chỗ này nếu nắm được thì sau này đỡ hoang mang: deploy là đưa code lên production, còn release là cho người dùng thấy tính năng đó. Hai việc này không nhất thiết xảy ra cùng lúc. Ở mấy đội mình gặp gần đây, code lên production từ tuần trước rồi nhưng tính năng vẫn đang tắt, tới ngày mới bật.

• Feature flag là cái công tắc bật/tắt tính năng, bật là chạy, không cần đẩy code lại. Nó cho phép giấu một tính năng đã nằm sẵn trên production.
• Canary release thì khác: nó đẩy phiên bản mới cho một phần người dùng thật dùng trước, ví dụ vài phần trăm, thấy êm thì mở rộng dần. Không phải giấu, mà là mở từ từ.

Nghe thì giống pilot, nhưng pilot thường được dựng thành một môi trường riêng cho nhóm người dùng được chọn, còn hai cái này diễn ra ngay trên production.

Với BA thì nó đổi vài thói quen. Lúc viết tài liệu, hỏi thêm tính năng này có nằm sau flag không, ai được bật. Lúc khách báo lỗi, hỏi luôn tài khoản của họ có nằm trong nhóm được bật hay chưa. Không hỏi thì hai bên ngồi nhìn hai màn hình khác nhau rồi cãi qua cãi lại, mà thật ra chẳng ai sai.

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.
• Nói cho đúng thì pilot là cách cho một nhóm người dùng được chọn xài trước, chứ không nhất thiết phải là một môi trường riêng. Bên banking mình làm thì họ dựng hẳn một môi trường riêng, nhưng nhiều chỗ khác chạy pilot ngay trên production rồi phân quyền hoặc bật feature flag cho đúng nhóm đó thấy. Bạn nghe "pilot" thì hỏi thêm một câu là đang chạy ở đâu, đừng mặc định.
• Là bản 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 xài, những người dùng cuối khác chưa được xà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à một kiểu thể loại khác.
• Có thể hiểu nó là một khu vực tách riêng do bên cung cấp dịch vụ dựng ra cho mình xài thử, thường gặp ở những hệ thống liên quan đến tiền bạc, tài chính, payment. Nó không phải một loại database, mà là cả một bản dịch vụ chạy riêng: cùng cách gọi, cùng luồng, nhưng tiền không có thật.
• Vì là bản thử nên dữ liệu trong đó là dữ liệu test chứ không phải dữ liệu thật. Ở đây có một chỗ nhiều bạn hiểu nhầm là "đổi endpoint là chạy được thật" — endpoint là địa chỉ mà phần mềm mình gọi sang bên kia, đổi nó chỉ là một phần thôi. Muốn chuyển sang bản thật thường còn phải đổi khoá truy cập, khai báo lại webhook (địa chỉ để bên kia gọi ngược về mình), làm lại dữ liệu và xin quyền. Nên khi nghe "chuyển qua production nhanh mà, đổi cái link thôi" thì bạn hỏi lại cho chắc.
• 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, SaaS, payment gateway.
• Một số tên khác:
  • Testnet: mạng test công khai của một blockchain, ai cũng vào được.
  • Devnet: mạng dev riêng của đội, ngắn hạn, reset lúc nào cũng được.
  • Với Ethereum thì tên testnet đổi theo thời gian: Goerli và Holesky đã ngừng hỗ trợ, hiện tại xài Sepolia (cho người làm app, contract) và Hoodi (cho validator, staking). Mấy cái tên này thay đổi theo từng năm, bản thân Sepolia cũng đang được tính chuyện thay thế, nên khi vào dự án blockchain nhớ hỏi lại đang test trên mạng nào chứ đừng lấy tên trong tài liệu cũ.

Bảng tóm tắt cho dễ nhớ

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 localhost, 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). Cronjob là mấy việc hệ thống tự chạy theo giờ, kiểu 0 giờ mỗi ngày tổng hợp số liệu, mùng 1 mỗi tháng xuất hoá đơn.
• Chia thành nhiều môi trường testing hoặc lên kế hoạch release trên testing env theo từng giai đoạn để tránh bug 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 một 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. Rollback là quay ngược về bản cũ khi bản mới hỏng. Kế hoạch này không phải việc junior tự dựng, nhưng bạn nên biết dự án mình có nó hay không, và ai là người có quyền bấm nút quay lại — hỏi trước lúc yên bình dễ hơn hỏi lúc đang cháy.
• Mỗi môi trường có một bộ cấu hình riêng: địa chỉ database, key của bên thứ ba, mức ghi log, bật tắt gửi email… Phần lớn mấy ca "chạy trên máy em ngon mà lên production lại lỗi" là nằm ở đây chứ không phải ở code. BA không cần biết sửa, nhưng biết để khi lỗi chỉ xảy ra ở đúng một môi trường thì hỏi được câu đúng: cấu hình hai bên có khác nhau chỗ nào không.

Mới vào dự án thì xin cái bảng này

Đây là thứ mình thấy hữu ích nhất cho bạn mới: ngày đầu vào dự án, xin một bảng liệt kê các môi trường đang có. Không có sẵn thì tự ngồi hỏi rồi ghi lại, mất nửa buổi nhưng xài được cả dự án. Mỗi môi trường ghi: đường link vào, đang chạy bản nào, dữ liệu lấy từ đâu, đang nối với dịch vụ ngoài nào (thanh toán, gửi mail, gửi tin nhắn), ai được vào và xin quyền ở đâu, ai là người phụ trách.

Bảng đó trả lời giúp bạn phần lớn câu hỏi kiểu "chỗ này test được không", "sao em không vào được", "cái này có gửi mail thật không" mà không phải đi hỏi vòng vòng.

Trước khi test trên dữ liệu gần thật, rà mấy câu này

Hễ môi trường nào dính tới dữ liệu thật hoặc bản clone từ thật (staging, pilot, đôi khi cả demo) thì rà trước khi bắt đầu:

• Dữ liệu trong đó có thông tin cá nhân của người thật không: tên, email, số điện thoại, số tài khoản, địa chỉ.
• Nếu có thì đã được che chưa, hay vẫn còn nguyên?
• Mấy đường gửi ra ngoài đã tắt hoặc đổi hết chưa: email, SMS, thông báo đẩy, webhook, thanh toán?
• Ai đang có quyền vào môi trường này, có ai không nên thấy dữ liệu đó mà vẫn vào được không?

Bốn câu thôi nhưng hỏi được thì bạn tránh cho dự án cái tình huống tệ nhất: khách hàng thật nhận được thứ gì đó từ một đợt test.

Chạy UAT thì cần chuẩn bị gì

Ở trên mình có nói UAT là hoạt động chứ không phải môi trường. Còn đây là mấy thứ nên chốt trước khi bắt đầu, để lúc chạy khỏi rối:

• Ai là người nghiệm thu và ai được quyền nói "cái này đạt".
• Đạt là đạt theo tiêu chí nào — bám vào phần mô tả yêu cầu đã thống nhất, chứ không phải theo cảm giác lúc ngồi test.
• Khi nào bắt đầu được: bản trên môi trường đó đã đúng bản cần nghiệm thu chưa, dữ liệu đã sẵn chưa.
• Khi nào coi là xong, lỗi còn lại xử lý ra sao.
• Kết quả test và xác nhận đạt lưu ở đâu. Chỗ này nhiều bạn bỏ qua rồi ba tháng sau cãi nhau không có gì để chỉ.

Tự kiểm tra

Bạn có thể dùng mấy câu này để tự rà lại phần vừa đọc:

1. Khách muốn xem thử tính năng mới, bạn cho họ vào môi trường nào, và vì sao không phải testing?
2. Tester báo một lỗi, dev nói "trên máy anh chạy bình thường mà". Có thể đang xảy ra chuyện gì?
3. Sắp chạy UAT trên bản clone từ database thật, bạn cần kiểm tra gì trước khi hệ thống gửi email hay tin nhắn đi?
4. Dự án nhỏ, sếp hỏi có cần dựng staging riêng không. Bạn trả lời sao?
5. Pilot với feature flag khác nhau chỗ nào?
6. Đội blockchain nói "test trên testnet nhé", bạn cần hỏi lại gì?

Kết bài

Tên gọi các môi trường và trách nhiệm của BA sẽ khác nhau tuỳ dự án, tuỳ công ty, nên đừng thuộc lòng bài này rồi đem đi áp nguyên xi. Cái đem đi được là thói quen: trước khi ngồi xuống test bất cứ thứ gì, hỏi cho ra bốn thứ — mình đang ở môi trường nào, đang chạy bản nào, dữ liệu trong đó là thật hay giả, và những đường gửi ra ngoài đang bật hay tắt. Hỏi được bốn câu đó thì bạn đã hơn kha khá người đi làm vài năm rồi.