GAB 2017 PARIS - Tester la sécurité de vos annuaires Active Directory et Azur...
Cedric leblond migrer jenkins AWS vers Azure Devops
1. Migrer de Jenkins vers Azure
DevOps les Builds Java
CÉDRIC LEBLOND
@leblond_c
2.
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
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
Docker enables developers and IT admins to build, ship and run any application, anywhere
Build, Ship, Run
Docker aims to deliver open tools to help developers build applications with open APIs to help sysadmins better manage these applications
http://docker.com/company
Docker enables developers and IT admins to build, ship and run any application, anywhere
Build, Ship, Run
Docker aims to deliver open tools to help developers build applications with open APIs to help sysadmins better manage these applications
http://docker.com/company
Author: Vincent Driessen Original blog post: http://nvie.com/posts/a-succesful-git-branching-model License: Creative Commons BY-SA
Ici utiliser un Nexus côté Azure aurait permit d’utiliser le Nexus AWS comme upstream.Azure Artifa
https://docs.microsoft.com/en-us/azure/devops/pipelines/process/templates?view=vsts
La possibilité d’utiliser des conteneurs dans la pipeline est aussi très intéressante. A chaque lancement, une nouvelle image propre est instanciée