Operation Guide: Azure DevOps¶
Creating and updating Documentation¶
Please see the guide for maintaining KaaS documentation here.
Enabling Pipeline Agent Pool for Application Pipeline Template for self-service on ADO projects¶
Prerequisite: Administrator role on KaaS ADO Project
In order for the pipeline template to have access to KaaS, it needs to be set up with the "kaas-prod" agent pool.
The following needs to be set up initially:
- In organisation settings → Agent pools → select "kaas-prod" → security tab, add the following permissions;
- add the
Build Service with role 'Administrator' - add the
Project Valid Users with role 'Reader' - Add the
Project Administrators with role 'Administrator' - Once a user in
Project Administrators in their ADO project settings has set → Agent pools → select "kaas-prod" → Pipeline permissions, settings/more actions -> Open access - this permission should be removed
- Once a user in
User Permissions & Resources in ADO: KaaS Workspace¶
Prerequisite: Administrator in KaaS and KaaS Workspace ADO projects
Below resource creations and access permissions must be configured on the KaaS Workspace, and whenever a new
The configuration setup is automated with the kaas-workspace-wizard, setting up permissions groups, GIT repository and permissions, pipeline and environment approvals. See KaaS Workspace Wizard Prerequisite for Service Connection setup.
- Update the namespace-packages.yaml - Repos file with the namespace details (copy an existing and replace namespace values)
-
Execute the Pipelines - kaas-workspace-wizard
-
After the creation of permission groups, adding AD groups to it can only be handled by the central team by submitting a ticket Azure DevOps - Other Requests
All NN users have read access to Confluent Cloud + Azure DevOps (for wiki and template cloning) |ADO Permission Group| Confluent Cloud Role| AD Groups| |--|--|--| |Reader (KaaS + KW) | Platform Viewer (read-only)| Office 365 - R3, Office365 - R3_2|
The default Microsoft ADO groups will be utilized, and custom namespace groups will be created inheriting from them, with explicit 'Allow' edit/contribute permissions being set on GIT repo level as shown below. Specific ADO AD groups have been created, and mapped to custom permission groups for policies. They are managed via novoAccess.
| novoAccess Role | AD Group | ADO Permission Group* | Confluent Cloud Role | KaaS Pipeline Deployment(s) | KaaS Variable Groups | KW GIT** | KW Variable Groups* | KW (Pipeline) Deployment Environments |
|---|---|---|---|---|---|---|---|---|
| KaaS Administrator | KaaS_Administrator_ADM | Project Administrator (KaaS + KW) | Yes | All | x | x | x | x |
| KaaS Operator | KaaS_Operator_ADM | Contributor (KaaS + KW) | Yes | - | - | - | - | - |
| KaaS Supporter | KaaS_Supporter | Contributor (KaaS + KW) | Yes | - | - | - | - | - |
| KaaS |
KaaS_ |
Custom (KW) | Yes | - | - | ns- |
QA, PRD | |
| KaaS |
KaaS_ |
Custom (KW) | Yes | - | - | ns- |
- | |
| KaaS |
KaaS_ |
Custom (KW) | Yes | - | - | ns- |
DEV, TST | |
| KaaS (ADO) Platform Architect | KaaS_ADO_PlatformArchitect | Custom (KaaS + KW) | No | All | - | - | - | - |
| KaaS (ADO) Codebase SME | KaaS_ADO_CodebaseSME | Custom (KaaS + KW) | No | - | - | - | - | - |
| KaaS (ADO) DevOps Engineer | KaaS_ADO_DevOpsEngineer | Custom (KaaS + KW), Project Administrator (KW) | No | Dev, Tst | - | x | x | x |
| KaaS (ADO) Operator | KaaS_ADO_Operator | Custom (KaaS + KW), Project Administrator (KW) | No | All | - | x | x | x |
| KaaS (ADO) Product Owner | KaaS_ADO_ProductOwner | Custom (KaaS) | No | - | - | - | - | - |
| KaaS (ADO) QC | KaaS_ADO_QC | Custom (KaaS) | No | - | - | - | - | - |
| KaaS (ADO) Service Manager | KaaS_ADO_ServiceManager | Custom (KaaS) | No | - | - | - | - | - |
| KaaS (ADO) Product Manager | KaaS_ADO_ProductManager | Custom (KaaS) | No | - | - | - | - | - |
*See 'KaaS Artefacts, Reviews and Approvals' for detailed approval flows (enforced by policies)
**One or more GIT repositories will be created per Team/namespace, where creating and contributing to branches and pull requests is allowed for the specific namespace users. A branch policy on main to include a minimum of two reviewers must also be configured.
*A variable group (ns-