Azure DevOps
Azure DevOps Project
The Azure DevOps project is the basic hull for providing the other tool categories and features. It contains also the permission management. Within one ODJ product you can only have one Azure DevOps project.
Multiple Azure DevOps organizations (SIT)
We are using multiple Azure DevOps organizations. Each organization has a limited number of projects that can be created. When a project gets created, an available organization is selected automatically.
Permission
Azure DevOps groups
Access to Azure DevOps is managed via SIAM roles. The SIAM roles are mapped to Azure active directory groups. This groups will be created automatically, when the Azure DevOps project gets created. The roles will be order for all team members automatically.
| SIAM group | ADO project group | Definition |
|---|---|---|
| azuredevops-xx-schwarzit-odj-[product_name]-owner | [ORGA.odj.PRODUCT]\Owner | A developer with extended permissions to manage GIT repositories, branches and pipelines. |
| azuredevops-xx-schwarzit-odj-[product_name]-member | [ORGA.odj.PRODUCT]\Member | A developer with necessary permission to add code, branches and create PR's |
| azuredevops-xx-schwarzit-odj-[product_name]-reader | [ORGA.odj.PRODUCT]\Reader | Can read all GIT repos and pipelines. Used for BC or non-technical users |
ODJ groups in Azure DevOps (SIT)
This ADO groups where added automatically to the ADO projects created by ODJ in the defined project groups. Each ODJ group is added by default to an ADO project group.
| ODJ group in ADO | containing users/groups | added to ADO project group | Access package | Description |
|---|---|---|---|---|
| [ORGA]\odj-owner | ado-odj-deliver@schwarzit.onmicrosoft.com | [ORGA.odj.PRODUCT]\Owner | Azure DevOps ODJ Firefighter Owner | Give supportive access to ODJ Deliver & Tooling team and the ODJ lead developers to all ODJ created projects. "ado-odj-deliver@schwarzit.onmicrosoft.com" needs this access permanently to execute our ODJ Deliver & Tooling provisioning and checks |
| [ORGA]\odj-member | SYS_JIRA_AzureGIT@schwarzit.onmicrosoft.com | [ORGA.odj.PRODUCT]\Member | Azure DevOps ODJ Firefighter Member | Not in use by ODJ directly. Used by QA team to integrate with their Jira QA test plugin |
| [ORGA]\odj-reader | - | [ORGA.odj.PRODUCT]\Reader | Azure DevOps ODJ Firefighter Reader | Read access for other ODJ internal teams for support cases |
ODJ support team does not have permanent access to Azure DevOps projects.
Supportive access for ODJ staff (with access packages)
The ODJ support can request time-limited read/write access to your Azure DevOps project (GIT repositories, pipelines, variable groups) to provide support.
With access packages you will get temporary access to the ODJ groups (odj-owner, odj-member, odj-reader). You have to go to https://myaccess.microsoft.com/ and request the role "ODJ Azure DevOps Support". The request must be approved by ODJ Deliver & Tooling team.
After your access is permitted, you can order the "Azure DevOps ODJ Firefighter" owner/member/reader role without any further approval (self-service). This access is time restricted. It will be removed automatically after 5h.
After the access is ordered, it may take up to 60 seconds until you have the permission. You will also receive an email.
Re-evaluate permission
When your access is not permitted after you have received the email, you can trigger a "Re-evaluate permission" process.
The re-evaluate must be done per Azure DevOps organization
Azure DevOps - Code repository
Azure DevOps is used to provide GIT repository. Other repository types in Azure DevOps are not supported. General non-ODJ questions and support can be found here.
This tool add the value azuredevops to the parameter odj_devenv_code_repository.
odj_devenv_code_repository: azuredevops
Managed elements
The managed elements table shows when the elements are created. Some will be on product provisioning level, some on component provisioning level. The selected product pattern affects also how the elements will be provisioned.
| Element / Pattern | Product (basic) | Product (advanced) | Component (basic) | Component (advanced) |
|---|---|---|---|---|
| Azure DevOps project | ✅ | ✅ | ||
| Azure DevOps repos | ✅ | ✅ | ||
| Permission | ✅ | ✅ | ||
| GIT repository | ✅ 1 | ✅ 1 |
Remarks: 1 Depending on the selected repository style (monorepo/multirepo), one GIT repo (monorepo) on product level, or one GIT repo per component (multirepo)
Azure DevOps project
Creates an Azure DevOps project, if it is not already there. More details can be found in the Azure DevOps project section.
Azure DevOps repos
Activates the repository feature in your Azure DevOps project.
Permission
Manages the permissions to access the Azure DevOps project. More details can be found in the permission section.
GIT repository
Branch policy
By default, the defined productive branch is secured by "branch policies" in Azure DevOps. Active build policies prevent a direct push to that branch. You have to create a PR (pull request) to validate your changes. The groups "member" and "owner" are automatically added to the default reviewers list of such PRs.
Branch policies are only added to repositories that contains the sourcecode for your component.
Require a minimum number of reviewers
Is a defined number of users that need to approve your PR before it can be merged to the productive branch.
Build Validation
We are adding the default pipeline to validate the code in a pre-merge build process. All necessary tasks will be executed in the pipeline.
Conventions and restrictions
- Renaming and deleting ODJ managed GIT repositories is not allowed
- For monorepo, changing the name of subfolders and the component folder name is not allowed. Files inside that structures (e.g. pipeline-file) are referenced by ODJs provisioning processes
If you ignore this conventions and restrictions, it causes issues in further support of your project through the automated functions of ODJ
Provisioning setup and configuration
Describes the provisioning of this tool and how it can be configured afterwards.
Product level
Provisioning
Azure DevOps project name
The name of your Azure DevOps project is automatically generated by the ODJ.
GIT repository layout (advanced pattern only)
Select between monorepo and multirepo GIT layout. In monorepo, all components are using the same GIT repository with sub-folders. In multirepo, each component is having it's own GIT repository.
This choise cannot be changed afterwards
Configuration
No Configuration changes are available afterwards.
Component level
Provisioning (advanced pattern only)
Repo type
The repository type is defined on product provisioning level and is only shown as an information here.
Component name
The component name is only shown as an information here.
Technology
A technology is a combination of a language, build tool and sometimes a framework. It is required to use the configured developer tools and pipeline. A wrong selection can lead to a not working pipeline and possible strange behaviors of the developer tools. Changing the technology afterwords is not possible, choose wisely. If you want to play around, choose generic. If your technology is not available, please contact the ODJ team for support.
Component folder prefix (monorepo only)
The folder prefix will be added in front of your component name. You can specify multiple folders. This value is optional.
Demo app
Add a demo app (if available) to a separate branch in your GIT repository. This app can then be merged to your productive branch.
Configuration
No Configuration changes are available afterwards.
Azure DevOps - Pipeline
Azure DevOps Pipeline is used to provide the CI/CD pipelines. The project creation and permissions descriptions are in the Code repository category in the tool Azure DevOps.
This tool add the value azuredevops to the parameter odj_devenv_pipeline.
odj_devenv_pipeline: azuredevops
Managed elements
The managed elements table shows when the elements are created. Some will be on product provisioning level, some on component provisioning level. The selected product pattern affects also how the elements will be provisioned.
| Element / Pattern | Product (basic) | Product (advanced) | Component (basic) | Component (advanced) |
|---|---|---|---|---|
| Azure DevOps project | ✅ | ✅ | ||
| Azure DevOps pipelines | ✅ | ✅ | ||
| Permission | ✅ | ✅ | ||
| Azure DevOps service connections | ✅ | |||
| Pipelines - Library variable group | ✅ 1 | ✅ 1 | ||
| Pipelines - Environments | ✅ | |||
| Pipelines - Library secure file | ✅ | |||
| Pipelines - Pipeline | ✅ |
Remarks:
1 Variable groups are create one on product level and one for each component
Azure DevOps project
Creates an Azure DevOps project, if it is not already there. More details can be found in the Azure DevOps project section.
Azure DevOps pipelines
Activates the pipeline feature in your Azure DevOps project.
Permission
Manages the permissions to access the Azure DevOps project.
Azure DevOps service connections
The ODJ created different service connection in Azure DevOps depending on the runtime and tools that you have selected.
| Type | Condition |
|---|---|
| SonarQube | when SonarQube is provisioned |
| Snyk | when Snyk is provisioned |
| Artifactory | when Artifactory is provisioned |
| Docker | targets to GCR when runtime is Google |
| Docker | targets to ACR when runtime is Azure |
| Docker | targets to Docker registry when Artifactory is provisioned and a Docker registry is created |
| Docker | for each consumed shared product with a docker registry when Artifactory is provisioned |
Pipelines - Library variable group
Product level
A variable group with the configuration of the product is created together with the pipeline definition. It is named odj-technical-product-properties. It is automatically referenced in all ODJ provided pipelines. All pipelines are allowed to use this variable group.
The variables are used to configure the pipelines without modifying the pipeline file itself (where ever this is possible). It contains names of service connections, settings for the docker container image naming and credentials for different tools.
Different provisioning events from the ODJ will add and remove variables in the variable group. This events could come from Deliver or other parts of the ODJ (like the runtime from core).
For example when you add a kubernetes cluster in Google as your runtime the value cloud_platform is set to gcp and cloud_platform_runtime is k8s.
It is not recommended to add, remove or modify values in the variable group. All values will be managed and modified by ODJ Deliver provisionings. If you need to add your own variables, create your own variable group and use it in the pipelines.
Component level
A variable group with the configuration of the component will be created for each component you add to your product. It is named odj-component-{component}-properties. It is automatically referenced in all ODJ provided pipelines. All pipelines are allowed to use this variable group.
Different provisioning events from the ODJ will add and remove variables in the variable group.
It is not recommended to add, remove or modify values in the variable group. All values will be managed and modified by ODJ Deliver provisioning. If you need to add your own variables, create your own variable group and use it in the pipelines.
Pipelines - Library secure file
Product level
A secure file is created to access the ODJ. This is required to trigger a deployment of a components. Even if the selected runtime is not GCP, this service account keyfile is required as long as ODJ is Google IAP protected.
This file is only added when a runtime environment with a kubernetes cluster was added to the product
Pipelines - Environments
Product level
Environments in Azure DevOps are created when you add a runtime to your ODJ product. For each stage your have added, you will get an environment with the name odj-{stage} automatically created in Azure DevOps. When the stage is removed, the environment will be removed.
Environments can be used to add manual approvals to deploy to specific stages. This is a build in Azure DevOps feature.
Pipelines - Pipeline
Component level
For each component a pipeline file is added to your GIT repository within the provisioning process. The file is named odj-azure-pipeline.yml. For monorepos, the file is added to the defined subfolder/component name. The file content is taken from the pipeline template repository with the matching technology.
A pipeline is created in the pipeline section in the folder ODJ managed pipeline. It has the name pattern odj-pipeline-ci-{componentName}. The pipeline references the odj-azure-pipeline.yml file in your repository.
Conventions and restrictions
- Renaming and deleting ODJ managed pipelines is not allowed
- Renaming and deleting ODJ managed pipeline files (odj-azure-pipeline.yml) is not allowed
- Renaming and deleting ODJ managed service connections is not allowed
- Renaming and deleting ODJ managed variable groups is not allowed
- Renaming and deleting ODJ managed environments is not allowed
- Renaming and deleting ODJ managed secure files is not allowed
If you ignore this conventions and restrictions, it causes issues in further support of your project through the automated functions of ODJ
Provisioning setup and configuration
Describes the provisioning of this tool and how it can be configured afterwards.
Product level
Provisioning
No configuration required
Configuration
No configuration changes are available afterwards
Component level
Provisioning
No configuration required. Autoprovisioning is supported here.
Configuration
No configuration changes are available afterwards
Azure DevOps - Boards
Azure DevOps Boards is used to provide a ticket system and agile board.
Managed elements
The managed elements table shows when the elements are created. Some will be on product provisioning level, some on component provisioning level. The selected product pattern affects also how the elements will be provisioned.
| Element / Pattern | Product (basic) | Product (advanced) | Component (basic) | Component (advanced) |
|---|---|---|---|---|
| Azure DevOps project | ✅ | ✅ | ||
| Azure DevOps boards | ✅ | ✅ | ||
| Permission | ✅ | ✅ |
Azure DevOps project
Creates an Azure DevOps project, if it is not already there.
Azure DevOps boards
Activates the boards feature in your Azure DevOps project.
Permission
Manages the permissions to access the Azure DevOps project.
Conventions and restrictions
None
Provisioning setup and configuration
Describes the provisioning of this tool and how it can be configured afterwards.
Product level
Provisioning
No configuration required
Configuration
No configuration changes are available afterwards
Component level
Provisioning
No configuration required. Autoprovisioning is supported here.
Configuration
No configuration changes are available afterwards