Mobile DevOps

Adrien Siffermann@asiffermann

21/09/2016 - Inspiré de faits réels

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é manuellement

Production« PRO »

Semantic Versionning 2.0.0 a.k.a. « Semver » Majeur : changements incompatibles

avec la version précédente Mineur : ajout de fonctionnalités

rétro compatibles Patch : bug fixes rétro compatibles Statut sémantique Nombre de changements

GitVersion

Un exemple avec les technos Microsoft

Builds Continuous Integration

Version, Build, Package

Toutes strictement identiques Utilisation des meta-tasks VSTS

Publication d’artifacts

http://geeklearning.io/the-9-steps-to-deploy-your-aspnet-core-10-application-to-azure-from-vsts/

Xamarin Test Cloud Tests automatisés

d’interface graphique mobile

Exécutés sur chaque Pull Request

Choix des devices

Back-end 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é manuellement

Production« PRO »

-Edge

/

-Val

-Int

-Val

Edge

/

-Pre

/

-Pre

-Pro

Prod

Front-end 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é manuellement

Production« PRO »

Releases Déploiement des

packages générés par les builds

Front-end APK, IPA HockeyApp, Stores publics…

Back-end WebDeploy, DACPAC Azure

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

Q&A

Merci !Adrien Siffermann

adrien@siffermann.me - @asiffermann - http://geeklearning.io