Déploiement dans Azure depuis VSTS
Adrien Siffermann
@asiffermann
15/09/2016 - Inspiré de faits réels
Qu’est ce qu’on déploit ?
Une application (très) simple
 Un projet ASP.NET Core
 Un projet de base de
données (SSDT)
GitFlow
 Isoler, suivre et valider les développements
 Deux branches principales
 Durée de vie infinie
 master : production-ready
 develop : intégration
 Des branches de support
 Durée de vie limitée
 feature : développement en parallèle
 release : préparation des livraisons
 hotfix : corrections en production
http://nvie.com/posts/a-successful-git-branching-model/
Environnements
 develop
 0.1.0-alpha.4
 Version de développement
Integration
« INT »
 release/* ou hotfix/*
 1.0.0-beta.0
 Version à tester
Validation
« VAL »
 master
 1.0.0+0
 Données de production
Preproduction
« PRE »
 Déploiement initié manuellementProduction
« PRO »
-Edge
/
-Val
-Int
-Val
Edge
/
-Pre
/
-Pre
-Pro
Prod
Builds
 Toutes strictement identiques
 Utilisation des meta-tasks VSTS
 Version, Build, Package
 Artifacts :
 Un package WebDeploy
 Un ou plusieurs package DACPAC
http://geeklearning.io/the-9-steps-to-deploy-your-aspnet-core-10-application-to-azure-from-vsts/
Découverte du projet VSTS
Bon… On déploit ?
Rien à faire ?
 Grande période d’indisponibilité
 Démarrage à froid
 Première requête très lente
 Fichiers verrouillés
 Echec du déploiement
 Pas de rollback possible
http://geeklearning.io/a-successful-azure-web-app-deployment-process/
Blue-Green deployment
http://martinfowler.com/bliki/BlueGreenDeployment.html
 Deux environnements de production
identiques
 Un actif, servant tout le traffic
 Un inactif, sur lequel on déploie la nouvelle version
 On intervertit le routage
 L’actif devient inactif, et inversement
 Azure Web Apps Deployments Slots
 Un slot dédié au déploiement par environnement
Stop - Deploy - Start - Swap
 On arrête le slot dédié
 Fichiers verrouillés
 Déploiement sur le slot dédié
 On démarre le slot dédié
 Démarrage à froid
 On intervertit le routage entre
les deux slots
Et la base de données ?
Database Snapshots
 Générer un état intermédiaire de déploiement
 Nouvelle colonne non-nullable
 Changement de type d’une clé primaire
 Scripts de provisionning
 Sur un environnement avancé, on peut avoir à déployer plusieurs DACPAC
 Les snapshots
 Le résultat de la compilation du projet
 Ne pas déployer une version antérieure
 Déployer les versions dans l’ordre
Azure SQL Incremental Deployment
 Configuration identique
 Mini match
 Récupère la version déployée
de la base de données ciblée
 Déploie uniquement les
DACPAC nécessaires, dans
l’ordre de leur version
 Enregistre la nouvelle version
de la base de données
Préproduction
 Restauration des données de production
 Récupération d’une sauvegarde récente
 Ajout de l’utilisateur SQL
 Utilisateur dédié à cet environnement
 Utilisé dans la ConnectionString
 Exécuter un script SQL sur la base restaurée
Azure SQL Database Restore
 Récupère la dernière sauvegarde
Point in Time
 Sauvegarde automatique SQL Azure
 Restaure la base de données
Azure SQL Execute Query
 Exécute un script SQL sur une
base de données SQL Azure
 Modes d’exécution :
 Fichier
 Inline
 Script prédéfini
 Variables SQLCMD
 WorkingDirectory
A vos déploiements !
 Gratuites, Open Source, et maintenues !
 Plus de tâches à venir : AzCopy, …
 Visual Studio MarketPlace
 https://marketplace.visualstudio.com/items?itemName=geeklearningio.gl-vsts-tasks-
azure
 GitHub
 https://github.com/geeklearningio/gl-vsts-tasks-azure
 Blog
 http://geeklearning.io
 Toutes nos tâches de build & release VSTS
 https://marketplace.visualstudio.com/search?term=publisher%3A"Geek%20Learning"&tar
get=VSTS
Q&A
Merci !
Adrien Siffermann
adrien@siffermann.me - @asiffermann - http://geeklearning.io

Déploiement dans Azure depuis Visual Studio Team Services

  • 1.
    Déploiement dans Azuredepuis VSTS Adrien Siffermann @asiffermann 15/09/2016 - Inspiré de faits réels
  • 2.
  • 3.
    Une application (très)simple  Un projet ASP.NET Core  Un projet de base de données (SSDT)
  • 4.
    GitFlow  Isoler, suivreet valider les développements  Deux branches principales  Durée de vie infinie  master : production-ready  develop : intégration  Des branches de support  Durée de vie limitée  feature : développement en parallèle  release : préparation des livraisons  hotfix : corrections en production http://nvie.com/posts/a-successful-git-branching-model/
  • 5.
    Environnements  develop  0.1.0-alpha.4 Version de développement Integration « INT »  release/* ou hotfix/*  1.0.0-beta.0  Version à tester Validation « VAL »  master  1.0.0+0  Données de production Preproduction « PRE »  Déploiement initié manuellementProduction « PRO » -Edge / -Val -Int -Val Edge / -Pre / -Pre -Pro Prod
  • 6.
    Builds  Toutes strictementidentiques  Utilisation des meta-tasks VSTS  Version, Build, Package  Artifacts :  Un package WebDeploy  Un ou plusieurs package DACPAC http://geeklearning.io/the-9-steps-to-deploy-your-aspnet-core-10-application-to-azure-from-vsts/
  • 7.
  • 8.
  • 9.
    Rien à faire?  Grande période d’indisponibilité  Démarrage à froid  Première requête très lente  Fichiers verrouillés  Echec du déploiement  Pas de rollback possible http://geeklearning.io/a-successful-azure-web-app-deployment-process/
  • 10.
    Blue-Green deployment http://martinfowler.com/bliki/BlueGreenDeployment.html  Deuxenvironnements de production identiques  Un actif, servant tout le traffic  Un inactif, sur lequel on déploie la nouvelle version  On intervertit le routage  L’actif devient inactif, et inversement  Azure Web Apps Deployments Slots  Un slot dédié au déploiement par environnement
  • 11.
    Stop - Deploy- Start - Swap  On arrête le slot dédié  Fichiers verrouillés  Déploiement sur le slot dédié  On démarre le slot dédié  Démarrage à froid  On intervertit le routage entre les deux slots
  • 12.
    Et la basede données ?
  • 13.
    Database Snapshots  Générerun état intermédiaire de déploiement  Nouvelle colonne non-nullable  Changement de type d’une clé primaire  Scripts de provisionning  Sur un environnement avancé, on peut avoir à déployer plusieurs DACPAC  Les snapshots  Le résultat de la compilation du projet  Ne pas déployer une version antérieure  Déployer les versions dans l’ordre
  • 14.
    Azure SQL IncrementalDeployment  Configuration identique  Mini match  Récupère la version déployée de la base de données ciblée  Déploie uniquement les DACPAC nécessaires, dans l’ordre de leur version  Enregistre la nouvelle version de la base de données
  • 15.
    Préproduction  Restauration desdonnées de production  Récupération d’une sauvegarde récente  Ajout de l’utilisateur SQL  Utilisateur dédié à cet environnement  Utilisé dans la ConnectionString  Exécuter un script SQL sur la base restaurée
  • 16.
    Azure SQL DatabaseRestore  Récupère la dernière sauvegarde Point in Time  Sauvegarde automatique SQL Azure  Restaure la base de données
  • 17.
    Azure SQL ExecuteQuery  Exécute un script SQL sur une base de données SQL Azure  Modes d’exécution :  Fichier  Inline  Script prédéfini  Variables SQLCMD  WorkingDirectory
  • 18.
    A vos déploiements!  Gratuites, Open Source, et maintenues !  Plus de tâches à venir : AzCopy, …  Visual Studio MarketPlace  https://marketplace.visualstudio.com/items?itemName=geeklearningio.gl-vsts-tasks- azure  GitHub  https://github.com/geeklearningio/gl-vsts-tasks-azure  Blog  http://geeklearning.io  Toutes nos tâches de build & release VSTS  https://marketplace.visualstudio.com/search?term=publisher%3A"Geek%20Learning"&tar get=VSTS
  • 19.
  • 20.
    Merci ! Adrien Siffermann adrien@siffermann.me- @asiffermann - http://geeklearning.io

Notes de l'éditeur

  • #5 Gestion fiable du cycle de vie des applications Corrections à chaud, tout en préservant le cycle de développement Limite les collisions entre développeurs lors des itérations Conserve une agilité dans les développements