Le document présente un plan de migration de plus de 80 dépôts et 1000 builds de Jenkins vers Azure DevOps, en se concentrant sur la copie des dépôts et des builds tout en conservant les configurations existantes. Il explique également les étapes pour gérer les builds, les politiques de branches, et l'utilisation d'Azure Artifacts pour la gestion des packages. En conclusion, la migration se déroule positivement, avec un retour favorable des équipes sur les nouvelles fonctionnalités et un processus de migration à finaliser.

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

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

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

5. 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

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

7. 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

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

9. 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

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

11. 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

12. 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

13. 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 !

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

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

16. 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

17. 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

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

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

20. 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

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

22. 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

23. 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

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

25. Merci
@leblond_c