Triển khai blue-green hứa hẹn các bản phát hành không thời gian chết: bạn thiết lập một bản sao mới của dịch vụ của mình, gửi một số lưu lượng truy cập đến đó, và chuyển đổi khi nó có vẻ hoạt động tốt. Vấn đề nằm ở từ "hoạt động tốt". Một kiểm tra sức khỏe của bộ cân bằng tải thường ping một điểm cuối và chờ phản hồi 200. Điều đó cho bạn biết tiến trình đang chạy. Nó không cho bạn biết liệu bản dựng mới của bạn có trả về JSON đúng, tuân thủ cùng hợp đồng hay vẫn xác thực token theo cách phiên bản cũ đã làm hay không. Vì vậy, bạn chuyển đổi, và người dùng thực đầu tiên tìm thấy lỗi mà kiểm tra sức khỏe của bạn không thể nhìn thấy.
Hướng dẫn này sẽ chỉ cho bạn cách kiểm thử môi trường xanh như một người dùng thực sẽ làm trước khi bất kỳ lưu lượng truy cập sản phẩm nào đến đó. Bạn sẽ chạy một bộ kiểm thử API đầy đủ trên hệ thống nhàn rỗi, chặn quá trình chuyển đổi dựa trên các kết quả đó và kết nối toàn bộ mọi thứ vào quy trình của bạn để nó diễn ra trong mỗi lần triển khai. Chúng ta sẽ sử dụng Apidog và Apidog CLI làm lớp kiểm thử, bởi vì các kịch bản kiểm thử mà bạn xây dựng trong ứng dụng máy tính để bàn có thể chạy tự động trong CI đối với bất kỳ môi trường nào bạn chỉ định.
Nếu bạn đã thực hành blue-green nhưng coi bước xác minh là "nhấp chuột xung quanh một phút," thì đây là phần biến nó thành thứ bạn có thể tin cậy. Mục đích của việc chạy hai môi trường giống hệt nhau là để xác thực một trong số chúng trong điều kiện thực tế. Một kiểm tra sức khỏe là mức tối thiểu, không phải mức tối đa.
Tóm tắt
Triển khai blue-green chạy hai môi trường sản phẩm giống hệt nhau và chuyển đổi bộ định tuyến giữa chúng. Trước khi bạn chuyển lưu lượng truy cập từ blue (đang hoạt động) sang green (mới), hãy chạy bộ kiểm thử API đầy đủ của bạn trực tiếp trên green. Chặn việc chuyển đổi dựa trên một bản dựng green của bộ kiểm thử. Với Apidog CLI, chỉ định các kịch bản kiểm thử tương tự vào URL cơ sở của môi trường green trong quy trình của bạn, thất bại quá trình triển khai nếu bất kỳ khẳng định nào bị lỗi, và chỉ sau đó mới chuyển đổi bộ định tuyến. Kiểm tra sức khỏe xác nhận một tiến trình đang chạy; kiểm thử API xác nhận hợp đồng vẫn còn hiệu lực.
Triển khai blue-green thực sự là gì
Triển khai blue-green là một mẫu phát hành giữ hai môi trường cấp độ sản phẩm cạnh nhau. Một phục vụ lưu lượng truy cập trực tiếp (gọi là blue). Môi trường kia nhàn rỗi, sẵn sàng nhận phiên bản tiếp theo (green). Bạn triển khai bản dựng mới đến green, xác minh nó, sau đó thay đổi một công tắc duy nhất (một đích bộ cân bằng tải, một bản ghi DNS, một bộ chọn dịch vụ Kubernetes) để tất cả lưu lượng truy cập hiện chảy đến green. Blue trở thành trạng thái chờ nhàn rỗi cho bản phát hành tiếp theo. Nếu có gì đó bị lỗi, bạn có thể quay lại blue trong vài giây.
Sự hấp dẫn là rõ ràng. Không có thời gian bảo trì. Việc chuyển đổi gần như tức thì. Và việc hoàn tác là rẻ nhất có thể, bởi vì phiên bản trước vẫn đang chạy và sẵn sàng. So sánh điều đó với một triển khai cuốn chiếu, nơi bạn thay thế các thể hiện tại chỗ và một bản dựng tồi đã phục vụ một phần người dùng vào thời điểm bạn nhận ra.
Nhưng mẫu này chỉ có hiệu quả nếu môi trường green thực sự sẵn sàng khi bạn chuyển đổi. Kiểm tra sẵn sàng đó là nơi hầu hết các nhóm đầu tư chưa đủ. Họ xác nhận green khởi động và vượt qua một kiểm tra /health nông cạn, sau đó chuyển đổi và hy vọng. Hình dạng của triển khai blue-green giúp việc kiểm tra kỹ lưỡng trở nên dễ dàng. Green được triển khai đầy đủ và có thể truy cập được, chỉ là chưa nhận lưu lượng truy cập công cộng, vì vậy không có lý do gì để bỏ qua nó. Bạn có một bản sao sản phẩm hoàn chỉnh, cô lập đang chờ được kiểm thử.
Nếu bạn muốn biết thuật ngữ chiến lược phát hành rộng hơn, phân tích của chúng tôi về phân phối liên tục so với triển khai liên tục so với tích hợp liên tục đặt bối cảnh cho vị trí của blue-green.
Tại sao kiểm tra sức khỏe không phải là một bài kiểm thử
Đây là khoảng trống thường gây rắc rối cho các nhóm. Một kiểm tra sức khỏe điển hình trông như thế này:
# Kiểm tra sức khỏe của bộ cân bằng tải
GET /health -> 200 OK -> đánh dấu mục tiêu là khỏe mạnh
Điểm cuối đó thường trả về một {"status":"ok"} được mã hóa cứng. Nó không chạm vào cơ sở dữ liệu của bạn. Nó không thực hiện xác thực. Nó không chuỗi hóa một tài nguyên thực. Một bản dựng có thể vượt qua kiểm tra này trong khi mọi điểm cuối nghiệp vụ đều trả về 500, một payload bị lỗi hoặc schema của ngày hôm qua.
Hãy xem xét các chế độ lỗi mà một ping /health sẽ dễ dàng bỏ qua:
- Một migration chưa chạy, khiến
GET /orders/{id}bị lỗi do thiếu cột. - Một trường JSON đã đổi tên (
user_idtrở thànhuserId) làm hỏng mọi người tiêu dùng hạ nguồn. - Một thay đổi xác thực hiện từ chối các token mà ứng dụng di động vẫn đang phát hành.
- Một bản nâng cấp phiên bản phụ thuộc làm thay đổi định dạng ngày từ ISO 8601 sang dấu thời gian Unix.
- Một header mới bắt buộc trả về
400cho bất kỳ máy khách nào không gửi nó.
Không có điều nào trong số này ngăn tiến trình khởi động. Tất cả đều làm hỏng người dùng thực ngay khi bạn chuyển đổi lưu lượng truy cập. Giải pháp không phải là một kiểm tra sức khỏe thông minh hơn; đó là một bộ kiểm thử thực sự gọi các điểm cuối của bạn theo cách máy khách thực hiện, khẳng định mã trạng thái, thân phản hồi, schema và độ trễ, sau đó báo cáo đạt hay không đạt. Đây là nguyên tắc tương tự đằng sau kiểm thử hợp đồng API; bạn đang kiểm tra xem dịch vụ đang chạy có còn khớp với thỏa thuận mà người tiêu dùng phụ thuộc vào hay không.
Quy trình kiểm thử blue-green, từ đầu đến cuối
Đây là chuỗi chúng ta đang hướng tới. Bước mới là "kiểm thử green," và nó nằm giữa triển khai và chuyển đổi.
- Triển khai đến green. Đẩy bản dựng mới đến môi trường nhàn rỗi. Nó có thể truy cập được tại một địa chỉ nội bộ, ví dụ
https://green.internal.example.com, nhưng chưa có lưu lượng truy cập công cộng nào đến đó. - Kiểm thử khói green. Chạy một tập con nhanh các yêu cầu trên đường dẫn quan trọng đối với green. Đăng nhập, lấy một tài nguyên cốt lõi, tạo một tài nguyên. Nếu bất kỳ cái nào thất bại, dừng lại ở đây. Blue vẫn đang phục vụ người dùng và không bao giờ nhận ra.
- Chạy bộ kiểm thử đầy đủ đối với green. Thực hiện các kịch bản kiểm thử API hoàn chỉnh của bạn (các đường dẫn thành công, các trường hợp lỗi, luồng xác thực, khẳng định schema) nhắm vào URL cơ sở của môi trường green.
- Chặn quá trình chuyển đổi. Nếu bộ kiểm thử vượt qua, tiếp tục. Nếu bất kỳ cái nào thất bại, quy trình dừng lại và môi trường green bị gỡ bỏ hoặc để lại để kiểm tra. Môi trường sản phẩm không bị ảnh hưởng.
- Chuyển đổi. Định tuyến lại bộ định tuyến (bộ cân bằng tải, DNS hoặc bộ chọn dịch vụ) từ blue sang green.
- Xác minh trong môi trường sản phẩm. Chạy cùng một kiểm thử khói đối với URL trực tiếp sau chuyển đổi để xác nhận việc chuyển đổi đã diễn ra suôn sẻ.
- Giữ blue sẵn sàng. Giữ môi trường cũ trong một cửa sổ hoàn tác. Nếu việc giám sát sau chuyển đổi gặp vấn đề, hãy quay lại ngay lập tức.
Mẹo là các bước 2, 3 và 6 sử dụng các định nghĩa kiểm thử giống nhau. Bạn xây dựng các kịch bản một lần và chỉ thay đổi URL cơ sở mà trình chạy nhắm mục tiêu. Đó là khả năng chúng ta sẽ thiết lập tiếp theo.
Xây dựng các kịch bản kiểm thử trong Apidog
Trước khi tự động hóa bất cứ điều gì, bạn cần một bộ kiểm thử đáng để chạy. Apidog cho phép bạn xây dựng nó một cách trực quan, sau đó chạy nó từ dòng lệnh mà không cần viết lại bất cứ thứ gì. Tải xuống Apidog và tạo một dự án cho dịch vụ bạn đang triển khai.
Trong một dự án, bạn tập hợp các kịch bản kiểm thử từ các điểm cuối API hiện có của mình. Một kịch bản là một tập hợp các yêu cầu có thứ tự với các khẳng định và truyền biến giữa các bước. Đối với một bộ kiểm thử sẵn sàng blue-green, bạn muốn các kịch bản phản ánh những gì máy khách thực làm, không chỉ các kiểm tra riêng lẻ.
Một bộ khởi đầu thực tế cho một dịch vụ đặt hàng:
- Luồng xác thực:
POST /auth/loginvới thông tin đăng nhập hợp lệ, khẳng định200, trích xuất token bearer vào một biến, sau đó sử dụng nó trong mọi yêu cầu tiếp theo. - Đường dẫn đọc:
GET /ordersvới token, khẳng định200, khẳng định phản hồi là một mảng, khẳng định mỗi mục cóid,statusvàtotal. - Tài nguyên đơn lẻ:
GET /orders/{id}, khẳng định schema khớp với định nghĩa OpenAPI của bạn, khẳng địnhtotallà một số lớn hơn 0. - Đường dẫn ghi:
POST /ordersvới một thân yêu cầu hợp lệ, khẳng định201, khẳng địnhidtrả về không trống, sau đóGETid mới đó để xác nhận nó đã được lưu trữ. - Các trường hợp tiêu cực:
GET /orders/{id}với token không hợp lệ, khẳng định401.POST /ordersvới một trường bắt buộc bị thiếu, khẳng định400.
Hai tính năng quan trọng nhất để phát hiện các lỗi mà kiểm tra sức khỏe bỏ qua. Đầu tiên, khẳng định schema: Apidog có thể xác thực phản hồi dựa trên JSON Schema hoặc định nghĩa OpenAPI cho điểm cuối đó, do đó một trường đã đổi tên hoặc đổi kiểu sẽ khiến kiểm thử thất bại thay vì lọt vào môi trường sản phẩm. Thứ hai, khẳng định phản hồi trên các giá trị cụ thể, header và thời gian phản hồi, để bạn bắt được sự thay đổi tinh tế: thay đổi định dạng ngày, một giá trị null nơi bạn mong đợi một số, sự suy thoái độ trễ.
Quyết định thiết kế chính là xử lý môi trường. Đừng mã hóa cứng https://blue.example.com vào các yêu cầu của bạn. Định nghĩa một biến môi trường cho URL cơ sở và tham chiếu nó ở mọi nơi dưới dạng {{baseUrl}}. Trong Apidog, bạn thiết lập các môi trường (Production, Green, Local) và chuyển đổi môi trường đang hoạt động, hoặc bạn ghi đè URL cơ sở tại thời điểm chạy từ CLI. Đây là nguyên tắc quản lý môi trường và bí mật tương tự được đề cập trong hướng dẫn của chúng tôi về máy khách API với quản lý môi trường và bí mật; các kiểm thử của bạn vẫn giống hệt nhau giữa blue và green, chỉ mục tiêu di chuyển.
Nếu bạn muốn đóng gói các kịch bản này thành một đơn vị có thể chạy được, bộ kiểm thử của Apidog nhóm nhiều kịch bản lại để một lệnh có thể chạy toàn bộ kiểm tra sẵn sàng.
Chạy bộ kiểm thử từ dòng lệnh
Ứng dụng máy tính để bàn là nơi bạn xây dựng và gỡ lỗi các kịch bản. CLI là thứ chạy chúng trong quy trình của bạn đối với môi trường green. Cài đặt nó bằng npm; bạn cần Node.js v16 trở lên:
npm install -g apidog-cli
Trình chạy thực thi một kịch bản kiểm thử từ cấu hình CI. Trong Apidog, bạn tạo cấu hình CI cho một kịch bản kiểm thử, cung cấp cho bạn một lệnh chạy được liên kết với một token truy cập. Dạng cơ bản:
apidog run "https://api.apidog.com/api/v1/api-test/ci-config/<config-id>/detail?token=<token>" \
-r html,cli \
--out-file green-readiness
Cờ -r chọn các trình báo cáo. cli in kết quả ra thiết bị đầu cuối để nhật ký quy trình của bạn hiển thị chính xác khẳng định nào đã thất bại. html ghi một báo cáo độc lập mà bạn có thể lưu trữ dưới dạng một artifact bản dựng cho bất kỳ ai xem xét việc triển khai. Cũng có một trình báo cáo JSON khi bạn muốn đưa kết quả vào một công cụ khác. Cờ --out-file đặt tên cho đầu ra để mỗi lần chạy có thể truy vết đến một bản dựng.
Để chỉ định bộ kiểm thử vào môi trường green cụ thể, trình chạy chấp nhận một cờ môi trường để cùng một kịch bản chạy đối với các mục tiêu khác nhau:
# Kiểm thử môi trường green (nhàn rỗi) trước khi chuyển đổi
apidog run "<ci-config-url>" \
--environment <greenEnvironmentId> \
-r cli,html \
--out-file green-pre-switch
Bạn cũng có thể điều khiển việc chạy hoàn toàn từ các tệp kịch bản đã xuất khi bạn muốn giữ mọi thứ trong kho lưu trữ và tránh gọi mạng để lấy cấu hình:
apidog run --exported-data ./tests/orders-readiness.json \
--variables ./tests/green.variables.json \
-r cli
Để tìm hiểu sâu hơn về trình chạy và các tùy chọn của nó trong bối cảnh quy trình, hãy xem cách tự động hóa kiểm thử API trong CI/CD. Hành vi quan trọng đối với blue-green là mã thoát: khi một khẳng định thất bại, CLI thoát với mã khác 0. Thực tế duy nhất đó là điều cho phép bạn chặn quá trình chuyển đổi. Một mã thoát khác 0 sẽ dừng quy trình trước khi bước chuyển đổi từng chạy.
Kết nối nó vào quy trình GitHub Actions
Đây là bước xác minh trong một quy trình triển khai. Điều này giả định rằng một công việc trước đó đã triển khai bản dựng đến môi trường green và môi trường green có thể truy cập được từ trình chạy. Công việc kiểm thử môi trường green, và chỉ khi chạy thành công thì công việc tiếp theo mới thực hiện việc chuyển đổi.
name: deploy-blue-green
on:
push:
branches: [main]
jobs:
deploy-green:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Deploy build to green environment
run: ./scripts/deploy-green.sh
# green is now reachable at https://green.internal.example.com
test-green:
needs: deploy-green
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run readiness suite against green
run: |
apidog run "${{ secrets.APIDOG_CI_CONFIG_URL }}" \
--environment "${{ vars.GREEN_ENV_ID }}" \
-r cli,html \
--out-file green-readiness
- name: Archive HTML report
if: always()
uses: actions/upload-artifact@v4
with:
name: green-readiness-report
path: ./green-readiness.html
switch-traffic:
needs: test-green # only runs if test-green passed
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Flip router from blue to green
run: ./scripts/switch-to-green.sh
- name: Smoke test production URL post-switch
run: |
npm install -g apidog-cli
apidog run "${{ secrets.APIDOG_SMOKE_CONFIG_URL }}" \
--environment "${{ vars.PROD_ENV_ID }}" \
-r cli
Chuỗi phụ thuộc sẽ thực hiện việc chặn cho bạn. switch-traffic liệt kê needs: test-green, vì vậy nếu bộ kiểm thử sẵn sàng thất bại, công việc chuyển đổi sẽ không bao giờ bắt đầu. Green vẫn nhàn rỗi, blue vẫn phục vụ, và không ai ở hạ nguồn bị ảnh hưởng. if: always() trên việc tải lên artifact có nghĩa là bạn sẽ nhận được báo cáo HTML ngay cả khi thất bại, đó là chính xác lúc bạn muốn đọc nó.
Lưu trữ URL cấu hình CI và token dưới dạng bí mật kho lưu trữ, không bao giờ viết trực tiếp. ID môi trường có thể là biến kho lưu trữ vì chúng không nhạy cảm. Nếu nhóm của bạn chạy trên GitLab, Jenkins, CircleCI hoặc Azure Pipelines, cấu trúc là giống hệt nhau: một giai đoạn kiểm thử thoát với mã khác 0 sẽ chặn giai đoạn chuyển đổi. Hướng dẫn chi tiết của chúng tôi về tự động hóa kiểm thử API trong GitHub Actions trình bày chi tiết hơn về thiết lập trình chạy, và mẫu tương tự có thể chuyển sang bất kỳ nền tảng nào trong số này.
Kiểm thử khói trước, bộ kiểm thử đầy đủ sau
Chạy toàn bộ bộ kiểm thử trên môi trường green là một cổng phù hợp, nhưng bạn không muốn phát hiện ra một bản dựng hoàn toàn bị hỏng ở phút thứ tám của một lần chạy mười hai phút. Chia xác minh thành hai lượt.
Kiểm thử khói là một kịch bản nhỏ gồm ba đến năm yêu cầu bao gồm đường dẫn quan trọng. Đăng nhập, đọc một tài nguyên, tạo một tài nguyên, đọc lại nó. Chạy nó trước. Nếu môi trường green không thể làm những điều này, toàn bộ bộ kiểm thử là lãng phí thời gian và bạn nên thất bại nhanh. Giữ điều này dưới ba mươi giây.
Bộ kiểm thử đầy đủ chỉ chạy sau khi kiểm thử khói vượt qua. Đây là nơi có độ bao phủ: mọi điểm cuối, các trường hợp lỗi, các trường hợp biên, xác thực schema trên mọi phản hồi, các hoán vị xác thực, phân trang, các header giới hạn tốc độ. Nó chậm hơn và điều đó không sao, bởi vì đó là cổng cuối cùng trước người dùng thực.
Cách tiếp cận hai cấp này là logic tương tự đằng sau suy nghĩ kịch bản kiểm thử so với trường hợp kiểm thử: kịch bản khói là một tín hiệu tin cậy nhanh, bộ kiểm thử đầy đủ là độ bao phủ toàn diện. Cả hai đều nhắm vào cùng một URL cơ sở của môi trường green; chúng chỉ khác nhau ở mức độ bao phủ và thời điểm chúng chạy.
Một lưu ý về dữ liệu kiểm thử. Green là một môi trường sản phẩm, vì vậy hãy cẩn thận về những gì các kiểm thử đường dẫn ghi của bạn tạo ra. Hoặc chỉ định các kiểm thử ghi vào một tài khoản kiểm thử chuyên dụng mà bạn sẽ dọn dẹp các bản ghi, hoặc chạy chúng đối với một thể hiện green được hỗ trợ bởi cơ sở dữ liệu staging trước khi lớp dữ liệu được thăng cấp. Xác minh hành vi mà không làm ô nhiễm dữ liệu sản phẩm là ranh giới bạn phải giữ, và đáng để hiểu sự khác biệt giữa môi trường sandbox so với môi trường kiểm thử khi bạn thiết kế điều này.
Các lỗi thường gặp làm mất đi toàn bộ ý nghĩa
Các nhóm áp dụng blue-green nhưng vẫn gặp lỗi. Thường là một trong những điều sau đây.
- Kiểm thử blue thay vì green. Nếu bộ kiểm thử của bạn nhắm vào URL trực tiếp, bạn đang kiểm thử phiên bản đã có trong sản phẩm, không phải phiên bản bạn sắp phát hành. Luôn nhắm mục tiêu rõ ràng vào URL cơ sở của môi trường green trước khi chuyển đổi.
- Chỉ kiểm tra mã trạng thái. Một mã
200với thân sai vẫn là một phản hồi bị hỏng. Khẳng định hình dạng payload và các giá trị chính, không chỉ trạng thái HTTP. Khẳng định schema là điều giúp phát hiện đổi tên trường và thay đổi kiểu. - Bỏ qua các trường hợp tiêu cực. Một bản dựng trả về
200cho một token không hợp lệ là một hồi quy bảo mật mà kiểm thử đường dẫn thành công sẽ không bao giờ bắt được. Bao gồm các trường hợp401,403và400trong cổng. - Không có nguyên tắc hoàn tác. Siêu năng lực của blue-green là hoàn tác tức thì, nhưng chỉ khi bạn giữ môi trường blue sẵn sàng. Đừng gỡ nó xuống ngay khi môi trường green hoạt động trực tiếp. Giữ nó trong suốt cửa sổ giám sát của bạn.
- URL mã hóa cứng trong yêu cầu kiểm thử. Ngay khi một URL cơ sở được tích hợp vào một yêu cầu, bạn đã mất khả năng chạy cùng một bộ kiểm thử đối với green và blue. Sử dụng một biến môi trường cho máy chủ, mọi lúc.
- Coi kiểm tra sức khỏe là cổng. Toàn bộ bài viết, trong một dòng. Việc kiểm tra báo cho bộ cân bằng tải rằng một tiến trình tồn tại. Các kiểm thử API của bạn cho bạn biết hợp đồng vẫn có hiệu lực.
Blue-green so với canary: nơi kiểm thử phù hợp
Blue-green không phải là chiến lược không thời gian chết duy nhất, và cách tiếp cận kiểm thử thay đổi theo từng cái.
| Chiến lược | Lưu lượng truy cập di chuyển như thế nào | Nơi kiểm thử API phù hợp |
|---|---|---|
| Blue-green | Tất cả cùng một lúc, từ blue sang green | Bộ kiểm thử đầy đủ đối với môi trường green trước khi chuyển đổi; cổng là trước khi chuyển đổi |
| Canary | Dần dần, một phần nhỏ % sang phiên bản mới | Các khẳng định liên tục trên phần canary; thăng cấp dựa trên các chỉ số sạch |
| Cuốn chiếu (Rolling) | Từng thể hiện một, tại chỗ | Kiểm thử khói trên từng thể hiện; khó chặn hơn vì quá trình triển khai đã diễn ra |
| Tạo lại (Recreate) | Dừng phiên bản cũ, bắt đầu phiên bản mới (với thời gian chết) | Bộ kiểm thử chạy trong cửa sổ; thời gian chết là sự đánh đổi |
Blue-green cung cấp cho bạn cổng sạch nhất trong bốn chiến lược vì môi trường green được triển khai hoàn toàn và cô lập hoàn toàn khi bạn kiểm thử nó. Bạn có một bản sao sản phẩm hoàn chỉnh để xác minh, không có người dùng nào bị ảnh hưởng, và một công tắc nguyên tử duy nhất. Canary đánh đổi cổng sạch đó để có sự tiếp xúc dần dần và dựa nhiều hơn vào giám sát trực tiếp. Đối với hầu hết các dịch vụ được hỗ trợ bởi API, blue-green cộng với một bộ kiểm thử trước chuyển đổi là cách đơn giản nhất để có được độ tin cậy cao mà không cần thời gian bảo trì.
Hình dạng thực tế của điều này
Một nhóm công nghệ tài chính điều hành một API thanh toán sử dụng blue-green cho mọi bản phát hành vì một triển khai lỗi không phải là một lỗi giao diện, đó là một giao dịch thất bại. Cổng của họ là một bộ kiểm thử gồm bốn mươi kịch bản đối với green bao gồm xác thực, khóa idempotency, làm tròn tiền tệ và chữ ký webhook. Toàn bộ quá trình chạy mất khoảng sáu phút. Không có gì đến môi trường sản phẩm cho đến khi nó hoàn toàn xanh, và báo cáo HTML được đính kèm vào mỗi lần triển khai để phục vụ việc kiểm tra.
Một nhóm SaaS với một API công cộng chạy một phiên bản tinh gọn hơn: một cổng kiểm thử khói gồm mười hai kịch bản đối với green, sau đó chuyển đổi, sau đó là một kiểm thử khói sau chuyển đổi đối với URL trực tiếp. Ưu tiên của họ là phát hiện sự thay đổi schema, vì các tích hợp bên thứ ba bị hỏng rõ ràng khi một trường thay đổi hình dạng. Khẳng định schema trên mọi phản hồi là trọng tâm của cổng của họ.
Cả hai nhóm đều xây dựng các kịch bản một lần trong Apidog và chạy chúng tự động từ CLI trong mỗi lần đẩy. Ứng dụng máy tính để bàn vẫn là nơi các kỹ sư gỡ lỗi và mở rộng kịch bản; quy trình là nơi các kịch bản đó trở thành cổng phát hành.
Kết luận
Triển khai blue-green cung cấp cho bạn một bản sao miễn phí, được triển khai hoàn chỉnh của môi trường sản phẩm đang nhàn rỗi trước mỗi bản phát hành. Lãng phí điều đó bằng cách chỉ kiểm tra một kiểm tra sức khỏe nông cạn là cách phổ biến nhất các nhóm phát hành lỗi với chiến lược không thời gian chết. Giải pháp là kiểm thử green như một người dùng trước khi bạn chuyển đổi.
Các phần:
- Xây dựng các kịch bản kiểm thử thực sự (xác thực, đọc, ghi, các trường hợp tiêu cực, khẳng định schema) một lần, trong Apidog.
- Sử dụng một biến môi trường cho URL cơ sở để cùng một bộ kiểm thử chạy đối với green và blue không thay đổi.
- Chạy một kiểm thử khói nhanh trước, sau đó là bộ kiểm thử đầy đủ, cả hai đều nhắm vào môi trường green.
- Chặn quá trình chuyển đổi dựa trên mã thoát của bộ kiểm thử trong quy trình của bạn để một thất bại sẽ chặn việc chuyển đổi.
- Giữ blue sẵn sàng để hoàn tác tức thì trong suốt cửa sổ giám sát của bạn.
Thiết lập điều này một lần và mọi lần triển khai sẽ tự động có cùng cổng. Tải xuống Apidog để xây dựng bộ kiểm thử sẵn sàng của bạn, tạo cấu hình CI và đặt bước apidog run vào quy trình của bạn trước giai đoạn chuyển đổi. Người dùng thực đầu tiên của bạn không bao giờ nên là kiểm thử thực đầu tiên của bạn.
FAQ
Triển khai blue-green đơn giản là gì? Đó là việc chạy hai môi trường sản phẩm giống hệt nhau và chuyển đổi tất cả lưu lượng truy cập giữa chúng. Một (blue) phục vụ người dùng trực tiếp trong khi cái kia (green) nhận phiên bản mới. Bạn kiểm thử green, sau đó chuyển một công tắc duy nhất để green trở thành môi trường trực tiếp. Blue vẫn là một mục tiêu hoàn tác tức thì.
Làm cách nào để kiểm thử môi trường green trước khi chuyển đổi lưu lượng truy cập? Chỉ định bộ kiểm thử API của bạn vào URL cơ sở của môi trường green và chạy nó trong quy trình của bạn trước bước chuyển đổi. Với Apidog CLI, hãy chạy các kịch bản của bạn bằng lệnh apidog run đối với môi trường green, thất bại quá trình triển khai nếu bất kỳ khẳng định nào bị lỗi, và chỉ chuyển đổi lưu lượng truy cập nếu bộ kiểm thử vượt qua.
Tại sao kiểm tra sức khỏe của bộ cân bằng tải không đủ cho blue-green? Một kiểm tra sức khỏe thường ping một điểm cuối và xác nhận phản hồi 200, điều này chỉ chứng minh tiến trình đang chạy. Nó sẽ không phát hiện ra một trường JSON đã đổi tên, một migration bị lỗi, một luồng xác thực bị hỏng hoặc một thay đổi schema. Một bộ kiểm thử API thực sự khẳng định trên thân phản hồi, schema và các trường hợp lỗi, vì vậy nó phát hiện ra các lỗi mà kiểm tra sức khỏe bỏ qua.
Tôi có thể chạy các kiểm thử API tương tự trong CI mà tôi đã xây dựng trong ứng dụng máy tính để bàn không? Có. Các kịch bản bạn xây dựng trực quan trong Apidog chạy không thay đổi từ Apidog CLI. Bạn tạo cấu hình CI cho một kịch bản, sau đó gọi apidog run với cấu hình đó trong GitHub Actions, GitLab CI, Jenkins hoặc bất kỳ quy trình nào. CLI thoát với mã khác 0 khi thất bại, điều này cho phép bạn chặn việc triển khai.
Sự khác biệt giữa triển khai blue-green và canary trong kiểm thử là gì? Blue-green chuyển đổi tất cả lưu lượng truy cập cùng một lúc sau khi bạn kiểm thử môi trường green đã được triển khai hoàn chỉnh, vì vậy cổng là trước khi chuyển đổi. Canary dịch chuyển lưu lượng truy cập dần dần sang một phần nhỏ và dựa vào giám sát trực tiếp của phần đó. Blue-green cung cấp một cổng kiểm thử trước phát hành sạch hơn; canary mang lại sự tiếp xúc dần dần trong thế giới thực.
Tôi có nên chạy các kiểm thử đường dẫn ghi trên môi trường sản phẩm green không? Hãy cẩn thận với dữ liệu. Hoặc sử dụng một tài khoản kiểm thử chuyên dụng mà bạn sẽ dọn dẹp các bản ghi, hoặc chạy các kiểm thử ghi đối với một thể hiện green được hỗ trợ bởi cơ sở dữ liệu staging trước khi thăng cấp lớp dữ liệu. Mục tiêu là xác minh hành vi mà không làm ô nhiễm dữ liệu sản phẩm, đó là ranh giới giữa một sandbox và một kiểm thử sản phẩm thực sự.
Cổng kiểm thử trước khi chuyển đổi nên nhanh đến mức nào? Chia nó ra. Chạy một kiểm thử khói gồm ba đến năm yêu cầu trên đường dẫn quan trọng trong vòng dưới ba mươi giây để thất bại nhanh, sau đó chỉ chạy bộ kiểm thử đầy đủ (mọi điểm cuối, các trường hợp lỗi, kiểm tra schema) nếu kiểm thử khói vượt qua. Một cổng hoàn chỉnh gồm vài chục kịch bản thường kết thúc trong vài phút, điều này là chấp nhận được đối với một cổng phát hành.