The MettleCI Azure DevOps DataStage pipeline examples require the setup of Azure ‘Environments’ (some requiring Approval) and Variable Groups to store MettleCI and DataStage installation information.
When configuring Azure to run MettleCI pipelines, there is a choice to be made between two different approaches:
Create one project containing a repository for each MettleCI/DataStage project, requiring
Create 1 Environment for each Continuous Integration, plus any other environments ending in Production, per Azure Project
Configure permissions for each Azure project
Create a separate Azure project (with default repository) for each DataStage project
Create 1 Environment for each Continuous Integration, plus any other environments ending in Production, shared between all pipelines in the Azure project
Create 1 Repository per DataStage/MettleCI project
The latter approach requires far less setup and configuration, so that is the approach we will document here.
Guides
Prerequisites
To automate the required steps in Azure DevOps, you will require…
The Azure CLI, which provides a wide range of methods for manipulating the Azure DevOps environment. Refer to Microsoft’s documentation for Installation instructions.
A user with permissions to:
Create new Repositories
Create and update Environments
Create Variable Groups
A Personal Access Token with suitable permissions
Create a Personal Access Token (PAT)
Right-click on the signed-in user, then the ellipsis (…) and User settings
Select Personal access tokens
Click on New Token, name the token, select the expiry date and select the scope (your security team will have advice on this, but Full access will minimise the chances of problems), the click on Create.
Don’t forget to copy the PAT for use in future cURL calls.
Authentication against an Azure Account
Before performing the required actions, we need to authenticate against the Azure account, using the Access Token.
az login -u <USER_EMAIL> -p <PASSWORD>
Create an Approvers Group (optional)
The purpose of this group is to approve promotion of code into an official environment, eg: Test, QA, Pre-Production, Production. MettleCI CI projects are internal (or “unofficial”) and requiring approval for those would be counter-productive.
If required, create an appropriate approvers group from the Azure DevOps management console.
In order to use this group to automatically create an approval against an environment, we need information about the group we plan to use.
$> az devops security group list --org <ORGANISATION_URL> --scope organization --query "graphGroups[?displayName=='<GROUP_NAME>'] | [0]" { ... "originId": "<GROUP_ORIGIN_ID>", "principalName": "<GROUP_PRINCIPAL_NAME>", ... }
Record these values for use later, where we refer to them as <GROUP_ORIGIN_ID>
and <GROUP_PRINCIPAL_NAME>
.
Create Repository
To create a source code repository within Azure associated with the Project:
$> az repos create \ --name <REPO_NAME> \ --org <ORGANISATION_URL> \ --project <PROJECT_NAME>
Create Variable Group
Variable groups are used by the pipeline code to organise variables, and are created per DataStage instance (although it includes agent variables as well).
Create the variable group, recording the
id
(referred to later as<GROUP_ID>
). Regular variables (not the secret value variables we use for passwords) can be added at this time (<VARIABLES>
is entered asvariable=value
, each pair separated by a space)$> az pipelines variable-group create \ --name <VRAIABLE_GROUP_NAME> \ --variables <VARIABLES> \ --authorize true \ --description <GROUP_DESCRIPTION> \ --organization <ORGANISATION_URL> \ --project <PROJECT_NAME>
Add secret value variables to the group individually for
MCIPASSWORD
andIISPASSWORD
$> az pipelines variable-group variable create \ --org <ORGANISATION_URL> \ --project <PROJECT_NAME> \ --group-id <GROUP_ID> \ --name <VARIABLE_NAME> \ --secret true \ --value <VARIABLE_VALUE>
We have observed instances in Azure DevOps where the secret value variable is created but the value is not assigned. In this case you will need to update the value manually in the Azure DevOps administration console.
Create Environment
Creating an Environment is currently not supported by the Azure CLI, but can be achieved using the REST API. All environments need to be created: MettleCI CI environments, and ‘official’ environments, i.e. Test, QA, Production, etc.
Encode the previously-created PAT as Base64. Note that the colon
:
inside the single quotes, before the PAT, is critical.$> echo -n ':<PERSONAL_ACCESS_TOKEN>' | base64
Add the encoded value as part of the authorisation in the cURL header.
$> curl POST \ -H 'Content-Type: application/json' \ -H 'Authorization: Basic <ENCODED_COLON_THEN_PAT>' \ 'https://dev.azure.com/<ORGANISATION_NAME>/<PROJECT_NAME>/_apis/distributedtask/environments?api-version=5.0-preview.1' \ -d '{"description":"<ENVIRONMENT_DESCRIPTION>","name":"<ENVIRONMENT_NAME"}'
Record the
id
field from the result. This is used below as<ENVIRONMENT_ID>
.If the environment requires approval, use
<ENVIRONMENT_NAME>
,<ENVIRONMENT_ID>
,<GROUP_ORIGIN_ID>
and<GROUP_PRINCIPAL_NAME>
to fill out the information required for the body of the request.$> curl POST \ -H 'Content-Type: application/json' \ -H 'Authorization: Basic <ENCODED_COLON_THEN_PAT>' \ 'https://dev.azure.com/<ORGANISATION_NAME>/<PROJECT_NAME>/_apis/pipelines/checks/configurations?api-version=7.1-preview.1' \ -d '{"type":{"id":"8C6F20A7-A545-4486-9777-F762FAFE0D4D","name":"Approval"},"settings":{"approvers":[{"displayName":"<GROUP_PRINCIPAL_NAME>","id":"<GROUP_ORIGIN_ID>"}],"executionOrder":1,"blockedApprovers":[],"minRequiredApprovers":0,"requesterCannotBeApprover":false},"resource":{"type":"environment","id":"<ENVIRONMENT_ID>","name":"<ENVIRONMENT_NAME"}}'
In the creation of an Approval for an Environment, the type
section ({"id":"8C6F20A7-A545-4486-9777-F762FAFE0D4D","name":"Approval"}
) contains a hard-coded id
value. This is neither project- nor pipeline-specific, but is the internal id of the “Approval” class in Azure DevOps, and should be used verbatim as described here.