Chúng tôi tiếp tục đánh giá về một công cụ tuyệt vời để phát triển cho Windows và hơn thế nữa, Azure DevOps. Lần này, phải chịu đựng rất nhiều với biến môi trường, tôi quyết định dồn tất cả kinh nghiệm vào một bài viết.
Bắt đầu từ thực tế là chúng có cú pháp khác nhau cho từng môi trường thực thi, kết thúc bằng việc thiếu khả năng tiêu chuẩn để chuyển các biến từ giai đoạn này của quy trình sang giai đoạn khác.
Tôi sẽ đặt trước rằng các ví dụ chính sẽ có trên Quy trình phát hành, vì YAML vẫn chưa đạt được điều đó và tôi cần chức năng của nhiều giai đoạn và nhiều tạo phẩm. Có vẻ như điều này đã có sẵn trong các Đường ống thông thường, gần như ngang bằng với chúng về chức năng. Trong Pipelines YAML, chúng tôi đã thêm một chú giải công cụ đồ họa nhỏ vào phần trình bày văn bản với các tham số có thể được đặt. Nó rất thuận tiện; bạn không cần phải xem tài liệu cho từng mô-đun. Nhưng tôi sẽ mô tả điều này trong bài viết tiếp theo, còn bây giờ đây là bức tranh về chính sự đổi mới.
Lưu trữ và sử dụng
Hãy bắt đầu với thực tế là chúng ta có các biến mặc định trong hệ thống. Chúng bắt đầu, tùy thuộc vào nguồn gốc của chúng, bằng các từ Phát hành, Hệ thống, v.v. Danh sách đầy đủ (hóa ra là không), có sẵn tại
steps:
- bash: echo This script could use $SYSTEM_ACCESSTOKEN
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
- powershell: Write-Host "This is a script that could use $env:SYSTEM_ACCESSTOKEN"
env:
SYSTEM_ACCESSTOKEN: $(System.AccessToken)
Nếu bạn đặt một biến trên tác nhân mà tác vụ được thực thi thì đó là $(System.AccessToken). Nếu bạn muốn sử dụng nó bên trong tập lệnh powershell trên cùng một tác nhân, thì nó sẽ là $env:SYSTEM_ACCESSTOKEN. Nếu bạn, Chúa cấm, muốn sử dụng biến này trên một số máy chủ từ xa bằng cách sử dụng tác vụ PowerShell trên máy đích, bạn cần chuyển điều này thông qua một đối số cho tập lệnh bằng cách sử dụng
Các luật tương tự không áp dụng cho các biến của riêng bạn; ở đây bạn đã chịu trách nhiệm về cú pháp. Các biến có thể được đặt cục bộ trong mỗi tác vụ.
Hoặc trên toàn cầu với kho lưu trữ biến, sau đó liên kết chúng từ cửa hàng. Rất thoải mái.
Ngoài ra, nếu các biến rất bí mật, chúng có thể được lưu trữ trên đám mây Azure trong bộ lưu trữ có tên Azure Vault; bạn có thể liên kết Vault với dự án trong Thư viện.
Nói chung, mọi thứ đều rõ ràng với các biến; trong quy trình, chúng vẫn có thể được đặt thủ công cho mỗi lần khởi chạy; trong bản phát hành không có chức năng như vậy. Bạn có thể xem lại những gì bạn đang chuyển sang quy trình trong nhật ký khởi tạo tác nhân, nhưng hãy nhớ rằng chúng đã ở đó ở dạng được chuyển đổi.
Biến động
Cuộc vui bắt đầu khi chúng ta muốn nhận được một số giá trị trong một giai đoạn và chuyển nó sang giai đoạn tiếp theo.
Chúng tôi không được cung cấp chức năng như vậy. Nhưng đôi tay của chúng ta không hề nhàm chán và với sự trợ giúp của Google, một giải pháp đã được tìm ra. Cảm ơn Chúa, Azure DevOps có một API cho phép chúng tôi làm được nhiều hơn một chút so với những gì được mô tả trên giao diện.
Vì vậy, chúng tôi sẽ cần lệnh gọi để cập nhật các biến toàn cục, việc này chúng tôi sẽ thực hiện trực tiếp từ bên trong quy trình. Địa chỉ được lấy từ các biến môi trường, giống như các biến môi trường không có từ nào trong tài liệu, như đã đề cập trước đó. Bạn có thể tự thiết lập chúng hoặc hơn thế nữa, mã hóa cứng chúng nếu họ đóng cửa hàng.
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )
Chúng ta đặt giá trị trống của biến muốn chuyển, đặt Phạm vi - Phát hành
Ví dụ: chúng tôi tạo một số trình tạo giá trị ngẫu nhiên. Hãy chú ý đến cú pháp khai báo một biến trong giai đoạn này; chức năng này đã được giới thiệu.
Trong bước tiếp theo, chúng ta chuyển biến vào tập lệnh, vâng, vâng, điều đó không thể thực hiện được một cách trực tiếp mà phải thông qua một đối số.
Kịch bản dưới spoiler
PowerShell
#Script requires stageVar variable in release variables set to Release scope
param ( [string] $expVar )
#region variables
$ReleaseVariableName = 'StageVar'
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID) )
#endregion
#region Get Release Definition
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
#endregion
#region Output current Release Pipeline
Write-Output ('Release Pipeline variables output: {0}' -f $($Release.variables | ConvertTo-Json -Depth 10))
#endregion
#region Update StageVar with new value
$release.variables.($ReleaseVariableName).value = "$expVar"
#endregion
#region update release pipeline
Write-Output ('Updating Release Definition')
$json = @($release) | ConvertTo-Json -Depth 99
Invoke-RestMethod -Uri $releaseurl -Method Put -Body $json -ContentType "application/json" -Headers @{Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN" }
#endregion
#region Get updated Release Definition
Write-Output ('Get updated Release Definition')
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
#endregion
#region Output Updated Release Pipeline
Write-Output ('Updated Release Pipeline variables output: {0}' -f $($Release.variables | ConvertTo-Json -Depth 10))
#endregion
Hoặc
Cú đánh
INPUT_VAR=$1
RELEASE_VAR=$2
echo Test ID: ${INPUT_VAR}
RELEASE_URL="${SYSTEM_TEAMFOUNDATIONSERVERURI}${SYSTEM_TEAMPROJECTID}/_apis/release/releases/${RELEASE_RELEASEID}?api-version=5.0"
echo release url: $RELEASE_URL
RELEASE_JSON=$(curl -H "Authorization: Bearer $SYSTEM_ACCESSTOKEN" $RELEASE_URL)
OUTPUT=`jq ''.variables.${RELEASE_VAR}.value' = '"${INPUT_VAR}"'' <<< $RELEASE_JSON`
curl -H "Authorization: Bearer $SYSTEM_ACCESSTOKEN" -H "Content-Type: application/json" -X PUT -d "$OUTPUT" $RELEASE_URL
Tóm lại, tập lệnh của chúng tôi lấy biến myVar làm đầu vào và sử dụng API để đặt giá trị của biến này vào stageVar. Trong bước tiếp theo, sử dụng cú pháp biến hệ thống, chúng ta có thể xem xét nó.
Ví dụ khá đơn giản nhưng chức năng mở ra những cơ hội tốt cho chúng ta, ngoài những điều tôi đã làm ở trên
Trong bài viết tiếp theo, nếu cần, tôi sẽ nói về quy trình YAML; gần đây có khá nhiều đổi mới thú vị ở đó.
Nguồn: www.habr.com