...
The latter approach requires far less setup and configuration, so that is the approach we will document here.
Guides
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
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 Command Line Interface (see 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.
| Code Block |
|---|
az login -u <USER_EMAIL> -p <PASSWORD> |
...
An Azure DevOps user and a Personal Access Token that provides the permissions required to create and updateâŚ
Azure DevOps Projects
Repositories
Environments
Variable Groups and Variables
Pipelines
MettleCI ships with an example repository which includes practical examples of how you can use the Microsoft Azure Command Line Interface to automate the creation of all the environmental assets necessary to establish a working Azure DevOps pipeline using the capabilities of MettleCI. These assets include âŚ
Azure DevOps Asset | Description |
|---|---|
Projects | The container for |
Agents and Agent Pools | Agent pools can be created easily using the Azure DevOps UI. Neither the number of pools your create, or the names you give them, are relevant to your MettleCI-enabled pipelines as jobs are automatically assigned to agents by Azure DevOps based on the demands required bye each of yoyr pipelines' steps and the matching capabilities advertised by your agents. The definition of Agents requires you to install one or more self-hosted Azure agents on a suitably equipped host (see https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/windows-agent?view=azure-devops) and associate the agent(s) with a relevant agent pool. |
Environments | The creation of Deployment Environments is not currently supported by the Azure CLI. Environments are created by the supplied pipelines as they are references. i.e., if you try and run a MettleCI deployment to an environment called MyQualityAssurance then environment of that name will be automatically created. Once a deploy environment has been created (either manually using the Azure UI or automatically) you can then configure its 'Approvals and checks' to restrict deployment to that environment as required. |
Repositories | Youâll need two repositories: One for your DataStage assets and one for your Compliance rules. We provide commands to create these and import the supplied examples. |
Variable Groups | Youâll need a variable group for each DataStage platform you operate. Typically, this will be one Development environment and one Production environment, and perhaps a separate Quality Assurance environment if your organisation structures its platforms like that. We provide commands to crate the variable groups and populate them with example variables required to execute the sample pipelines. Passwords are configured as âsecretâ variables. If you wish these values to reside in an Azure Key Store youâll need to modify the supplied example commands to achieve that. |
Pipelines | We provide four example pipelines:
|
Creating an Approvers Group (optional)
The purpose of this group is to approve promotion of code into an official environment, e.g., eg: Test, QA, Pre-Production, Production. MettleCI CI projects are internal (or âunofficialâ) and requiring approval for those would be counter-productivecounterproductive.
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.
| Code Block |
|---|
$> 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:
...
_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).
...
.
...
Add secret value variables to the group individually for MCIPASSWORD and IISPASSWORD
| Code Block |
|---|
$> az pipelines variable-group variable create \
--org <ORGANISATION_URL> \
--project <PROJECT_NAME> \
--group-id <GROUP_ID> \
--name <VARIABLE_NAME> \
--secret true \
--value <VARIABLE_VALUE> |
| Info |
|---|
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.
...