Pipeline Release : import managed, approvals, RBAC et app registrations
Le pipeline de release promeut des artefacts signés vers TEST, PREPROD puis PROD. Il contrôle l’identité d’exécution, les approbations et le respect des politiques.
Pré requis de sécurité
Avant tout déploiement, les identités et portées doivent être claires.
- App registrations par environnement avec rôles minimaux Dataverse.
- Service connections Azure DevOps liées aux app registrations.
- RBAC sur Azure DevOps limitant qui peut queue/approver un release.
- Key Vault pour secrets et rotation programmée.
Étapes de release
Un enchaînement déterministe réduit les erreurs humaines.
- Auth pac sur l’environnement cible (TEST/PP/PROD).
- Import de la solution managed depuis l’artefact.
- Upgrade s’il existe une version antérieure en production.
- Post-deploy checks : Solution Health, pings API.
YAML (extrait multi-environnements)
Ce modèle factorise l’import géré et les gates.
stages:
- stage: TEST
jobs:
- job: import
steps:
- powershell: |
pac auth create --url $(TEST_ENV_URL) --tenant $(TENANT_ID) --applicationId $(APP_ID_TEST) --clientSecret $(APP_SECRET_TEST) --name TestAuth
pac solution import --path $(Pipeline.Workspace)/drop/Marlk_SalesCore.zip --async --publish-changes true --force-overwrite true
displayName: Import managed (TEST)
- stage: PROD
dependsOn: TEST
approval: Manual
jobs:
- job: import
steps:
- powershell: |
pac auth create --url $(PROD_ENV_URL) --tenant $(TENANT_ID) --applicationId $(APP_ID_PROD) --clientSecret $(APP_SECRET_PROD) --name ProdAuth
pac solution import --path $(Pipeline.Workspace)/drop/Marlk_SalesCore.zip --async --publish-changes true --force-overwrite true
displayName: Import managed (PROD)
Gates, approbations et conformité
Les contrôles formalisent le go/no-go.
- Approvals par Release manager et Security.
- Gates automatiques : Solution Checker post-import, tests API smoke.
- Change log généré depuis commits + numéro de version SemVer.
Rollback et stratégie d’upgrade
Un plan de retour est obligatoire en production.
- Conserver la version N-1 managed et le package de rollback.
- Prévoir un data fix script si schéma modifié.
- Documenter breaking changes et activation progressive des features.