Je migre de nombreuses builds Java, jgitflow d'une plateforme Jenkins et Nexus hébergée sur AWS vers Azure DevOps. Après une description du contexte, je vous détaillerai : - comment la migration de package Nexus est réalisée. - comment les Builds Jenkins sont recrées sur Azure DevOps. - comment utiliser jgitflow et git efficacement dans les builds Nous verrons beaucoup d'astuces et options pour orchestrer les nouvelles builds et releases. Et surtout, nous discuterons de comment accompagner les équipes dans cette transition.

1. Migrer de Jenkins vers Azure
DevOps les Builds Java
CÉDRIC LEBLOND
@leblond_c

2. Contexte : migration de +80 repos et +1000 builds
AzureAWS
Plateforme IAAS / IAC cibleEnvironnements existants
DEV Prod PreProd UAT Prod PreProd UAT DEV

3. Migrer en mode copier/coller
COPIER LES REPOS
COPIER LES BUILDS EN CONSERVANT LES MÊMES

4. Migration de repos Git
• Importer les repos Git via l’interface
•  facile et rapide,
mais une seule fois, pas d’automatisation
• Utiliser les fonctions de mirroring de Git avec un repo locale
git clone --mirror https://serverTFS/Projet/repo
git set remote dest https://dev.azure.com/orga/projet/repo
git push --mirror
•  permet de synchroniser plusieurs fois, automatisable
•  reste à modifier les configurations de Builds Jenkins

5. Migrer les builds en répliquant celles de Jenkins
• Copier les actions et paramètres depuis les Jobs Jenkins et les Jenkinsfile (groovy)

6. Vue d’ensemble de GitFlow
Author: Vincent Driessen
Original blog post:
http://nvie.com/posts/a-succesful-
git-branching-model
License: Creative Commons BY-SA

7. Migrer les premiers repos
AzureAWS
Plateforme IAAS / IAC cibleEnvironnements existants
DEV Prod PreProd UAT Prod PreProd UAT DEV

8. Résumé des builds, Ajout de branch policies
• Build de CI : compilation, tests
• Build de déploiement en Dev :
◦ feature-Deploy
◦ nightly-Deploy
• Build liées au GitFlow
◦ feature-start
◦ release-start, release-finish
◦ hotfix-start, hotfix-finish
• Ajout de Policies pour protéger la branche develop:
◦ 2 reviewers minimum
◦ Build CI réussie
◦ Commentaires resolus

9. Gérer les packages via Azure Artifacts
AzureAWS
Plateforme IAAS / IAC cibleEnvironnements existants
DEV Prod PreProd UAT Prod PreProd UAT DEV

10. Pousser les packages vers Azure Artifacts
• Azure Artifacts permet de configurer des feeds upstream publics
masi pas de feed upstream privés
•  Seule solution : déployer sur les environnements existants depuis Azure
Artifacts
• Ouvrir le flux réseau des environnements existants vers Azure Artifacts
• Pousser tous les packages Nexus existants vers Azure Artifacts
• Configurer les builds pour pousser vers le feed d’Azure Artifacts

11. Gotcha! les points à ne pas oublier
• Le nombre de Builds contraint à utiliser des conventions:
◦ Un dossier par répertoire
◦ Nommage uniforme : nomrepo-CI, nomrepo-release-start, …
• Utiliser les groupes de Tasks pour modifier une seule fois (les scripts)
• Utiliser Clone pour créer les builds similaires
• Bien coché la case : autoriser les scripts à utiliser OAuth
• Donner tous les droits nécessaires au compte de build
Project Collection Build Service
◦ Sur les repos : Contribute, create branch, create tag , force push
◦ Sur les feeds : Contribute
• Si l’option « Authenticate built-In maven feed » ne fonctionne pas,
créer les « maven credentials » et les ajouter dans le fichier settings.xml de
l’agent

12. Où en sommes-nous ?
• Equipes ont un retour positifs sur cette mise en place
•  elles retrouvent les mêmes fonctions
peu d’écarts et changements
•  permet les Pull Requests et les revue de code
• Les équipes sont prêtes à essayer sur quelques projets !

13. Finir de migrer les +80 repos et +1000 builds
AzureAWS
Plateforme IAAS / IAC cibleEnvironnements existants
DEV Prod PreProd UAT Prod PreProd UAT DEV

14. Migrer en mode full Azure
DevOps
TIRER PARTI DES FONCTIONNALITÉS DE LA PLATEFORME
SUIVRE LES BONNES PRATIQUES DE PIPELINE

15. Beaucoup de builds lancées manuellement
• Beaucoup sont liées au GitFlow :
◦ feature-start
◦ release-start, release-finish
◦ hotfix-start, hotfix-finish
•  Adoptons une stratégie plus légère : Release Flow
◦ https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/release-flow

16. Build once, deploy many
• Compilation dans plusieurs Builds:
◦ migration-CI
◦ migration-Quality
◦ migration-feature-Deploy
◦ migration-nightly-Deploy
•  Créons une définition de release
◦ Continuuous Deployment
◦ Pull Request deployment

17. Déployer de la même façon, sur des environnements similaires
•  Passons l’environnement de Dev dans SaltStack

18. Déployer l’environnement de Dev en Saltstack
AzureAWS
Plateforme IAAS / IAC cibleEnvironnements existants
DEV Prod PreProd UAT Prod PreProd UAT DEV

19. Pipeline as code
• Dans le cadre de la migration, le désavantage est d’avoir besoin de modifier les
repos
• Permet aussi de modifier une fois les étapes grâce aux templates

20. Résumé et Suite
CE QUE NOUS A AVONS VU
CE QU’IL RESTE A ACCOMPLIR

21. Résumé
• Migration des repos Git très facile et transparente
• Création de Builds presque identiques à Jenkins possible
• Remplacement des Jenkinsfile par des fichiers yaml possible
• Remplacement de Nexus par Azure Artifacts possible

22. La suite ?
• Automatiser la copie d’un répertoire de Builds en changeant le repo cible
• Migrer les 80 repos…
• Migrer complètement vers la plateforme IAAS / IaC
• Fermer l’environnement AWS

23. Compléter la migration
AzureAWS
Plateforme IAAS / IAC cibleEnvironnements existants
DEV Prod PreProd UAT Prod PreProd UAT DEV

24. Merci
@leblond_c