DEVOPS : Chaîne de productionMa vision du déploiement

Nicolas Wallerand (Software developer)n.wallerand@gmail.com

DEVOPSLe devops est un mouvement visant à l'alignement de l'ensemble des équipes du système d'information sur un objectif commun, à commencer par les équipes de dev ou dev engineers chargés de faire évoluer le système d'information et les ops ou ops engineers responsables des infrastructures (exploitants, administrateurs système, réseau, bases de données,...).

Pour accélérer le cycle de vie des applications et leur qualité.

Donc Optimiser le TIME TO MARKET

Automatiser le déploiement

PIPELINEUn PIPELINE est un ensemble d’étapes indépendantes (jobs) dans le processus de développement et qui augmentent le degré de confiance à chacun des niveaux.

Le PIPELINE est différent en fonction de l’architecture Serveur

Application MonolithiqueApplication cloud/Architecture microservice

Le pipeline se généralise dans les outils● Bitbucket : https://bitbucket.org/product/features/pipelines● Jenkins : https://jenkins.io/projects/blueocean/● Travis : https://travis-ci.org/● Gitlab : https://about.gitlab.com/gitlab-ci/

Code Base 12Factor

12 factorsI. Base de code Une base de code suivie avec un système de contrôle de version, plusieurs déploiements

II. Dépendances Déclarez explicitement et isolez les dépendances

III. Configuration Stockez la configuration dans l’environnement

IV. Services externes Traitez les services externes comme des ressources attachées

V. Build, release, run Séparez strictement les étapes d’assemblage et d’exécution

VI. Processus Exécutez l’application comme un ou plusieurs processus sans état

VII. Associations de ports Exportez les services via des associations de ports

VIII. Concurrence Grossissez à l’aide du modèle de processus

IX. Jetable Maximisez la robustesse avec des démarrages rapides et des arrêts gracieux

X. Parité dev/prod Gardez le développement, la validation et la production aussi proches que possible

XI. Logs Traitez les logs comme des flux d’évènements

XII. Processus d’administration Lancez les processus d’administration et de maintenance comme des one-off-processes

Worflow des branches

Un workflow git, c'est une séries d'opérations bien définies à répéter pour conserver un repo propre.

Le choix d’un workflow Git est primordial car le pipeline va s’exécuter automatiquement en fonction des pushs effectués sur une branche.

Il interagit directement avec le gestionnaire de version (comme GIT).

Le choix de la nomenclature des commits est important.

Les grands Principes

● Continuous Integration● Continuous Delivery● Continuous Deployment

Continuous Integration

TEST BUILD

Test UnitaireTest Sécurité[...]

Déploiement automatique (packagist/Satis/Artifactory)Mise à jour automatiquement de la version du composer.jsonModifier le fichier changelog

Exemple d’utilisation :

Pour des librairies qui sont utilisées seulement en dépendance d’un projet.(Monologue,Acl,etc…)

Stage

Continuous Delivery

TEST BUILD DEPLOYTest UnitaireTest Sécurité[...]

Minification/ConcatDépendancesPush variable environnement[...]Génération d’un ARTIFACT

Déploiement sur le serveur

Exemple d’utilisation :

Sur des features d’un projet (SPRINT).

Manuelle (Programmation MEP)livré à l’équipe suivante (Tests, Qualification, Mise En Production, Ops)

Stage

Continuous Deployment

TEST BUILD DEPLOYTest UnitaireTest SécuritéTests d'intégrationTest IHMTest de performance[...]

Minification/ConcatDépendancesPush variable environnement[...]Génération d’un ARTIFACT

Déploiement sur le serveur

Exemple d’utilisation :

Sur des petites features simples d’un projet qui n'engendreraient pas de régression (KANBAN).Sur des projets de documentation.

AUTO (pas d’intervention humaine

Stage

Et la qualité ? livrer des bugs...

Ceci implique d’avoir une couverture de tests (unitaires, d’intégration, de performances, mutations, etc.) très complète.

Outre les tests unitaires, inévitables, on trouvera donc toute une série de tests automatisés comme :

● Tests d’intégration (Fitnesse, Greenpepper, etc.)● Tests IHM (Selenium, etc.)● Tests de performance (Gatling, OpenSTA, etc.)● [...]

DEMO*

(* avec des slides)

Exemple du Continuous Delivery (GITLAB/GITLAB-CI)● Nouvelle demande (feature d’un projet ) cahier des charges/ spécifications

● Ajout de la feature dans un logiciel de gestion projets (Mingle/JIRA/Issue Gitlab,youtrack) et assignation à un développeur

Le développeur fait la tâche qui lui est assignéeIl crée une branche (en fonction du workflow git ) à partir de la tâche

Le développeur travaille sur son Issue/feature

CODE

COMMIT

PUSHFeature-branch

HOOK GIT

HOOK GIT / Script de pre-commitGrâce au hook git (script lancé au commit) à nous pouvons lancer une série de vérifications lors de chaque commit pour s'assurer de la qualité du code (linter, CodeSniffer et tests).

● des normes psr (PHP).● test unitaire.● phpLint…● Nomenclature des messages des commits.● Suppression automatique des var_dump() des console_log().● […]

En utilisant des outils comme GrumPHP

Test TU Build Deploy review validation merge

request

Test secu

Test Build Deploy review

Validation Request merge

Stage

(tester/builder/déployer sur intégration)Pour chaque push du code du développeurTout les jobs sont exécutés automatiquement(remontée des erreurs) App interne de review

utilisation de l’api-gitlab

Jobs

Quand le développeurestime avoir fini,il demande une validation(CP/MOA)

SOUMISSIONMerge MasterCode review

Déployer un environnement propre à la feature (vhost Apache)Intégration continue

Un pipeline de jobs va s'exécuter sur les branches featuresPour Faire Simple ( pas de branche release/develops)

Exécution du pipeline des branches Feature

Grâce au job décrit dans le fichier gitlab-ci.yml, le job est exécuté à chaque push d’un code d’une branche autre que la branche master.

L’application exécute les tests (TU, Test Sécurité….)L’application est construiteL’application est déployée sur le serveur d’intégration

Stage TEST

Les jobs peuvent:

● Exécuter des tests unitaires (phpunit).● Exécuter des tests sécurité.● Exécuter des tests d’acceptation (codeception).● Loguer le déroulement (date…).● Retourner des indicateurs de qualités.● Informer les collaborateurs (email/bot Mattermost).● […]

Stage BUILDCe job peut :

● Mettre à jour les dépendances (via composer).● Lancer les tâches de modifications/de concaténation (via gulp/gruntJs).● Supprimer des fichiers des TU (inutile pour les environnements DEV).● Créer une archive/artifact du code source.● Loguer le déroulement (date…).● Informer les collaborateurs (Email/ bot Mattermost/slack).● […]

Dans un jobs de release :On peut créer un fichier d'environnement qui pushe les variables définies dans le projet Gitlab.Ce fichier est utilisé dans une lib php qui crée des variables d'environnement serveur.

Stage REVIEW/INTEGRATION (deployer)

Le job doit:

● Déployer l’artifact du code dans le directory du serveur web.● Créer un vhost (apache/nginx) htttp://issue-name.review.domain.com + reload

apache.● Loguer le déroulement (date…).● Informer les collaborateurs( email/bot Mattermost).● […]

Quand le développeur estime avoir fini sa feature il « fait une demande de validation » pour le chef de projet

Il lance manuellement un job de validation

Stage VALIDATION INTÉGRATIONCe job doit :

● Soumettre une demande de validation de la feature au chef de projet.● Il envoie un email (bot dans Mattermost) avec les informations de l’issue, l’url de review de l’issue

etc…

Ce job peut :● Loguer le déroulement (date…)● Informer les collaborateurs (email/ bot Mattermost)● […]

App interne de review utilisation de l’api-gitlab

Il valide Soumission du job de MERGE De la branche feature sur la master

Application reviewGrâce à cette application câblée sur l’api rest de Gitlab (ou autre JIRA) on peut récupérer les informations de l’issue

Visualiser l’issue (iframe de http://issue-name.review.domain.com)

et exécuter le jobs de demande pull request en cliquant sur « Je valide cette Feature ».

Stage VALIDATION MERGECe Jobs doit être exécuté manuellement par le chef de projet qui valide la feature.

Il permet grâce à l’api Rest de gitlab de créer un pull request entre la branche de la feature et la master et de faire une demande au release manager/Tech Lead de valider le pull request.

Le Tech Lead peut faire du code review.L’expert sécurité peut vérifier d'éventuelle faille de sécurité.

Accept le merge Request

La feature est mergée avec la master

Le techLead

Exécution du pipeline sur la branche master

Grâce au job décrit dans le fichier gitlab-ci.yml , à chaque push d’uncode sur la branche master :

● L’application exécute les tests (TU, Test Sécurite….) pour l’intégration de l’ensemble des features.

● L’application est buildée● L’application est déployée sur le serveur pre-prod (iso prod)

On déploie manuellement et on lance le job de déploiement en production.

Test Build Deploy pre-pro

Test fonctionnel

Deploy pro Reporting

ZERO DOWNTIME DEPLOYMENT (ZDD)

Qui permet de déployer une nouvelle version d’un système sans interrompre le bon fonctionnement du service.

Blue/Green Deployment

C’est le pattern classique de ZDD. Il suppose que l’application soit hébergé sur au moins deux chaînes applicatives, puisque l’objectif est de déployer la version N+1 d’une application sur une des chaînes, tandis que le service est maintenu sur les chaînes encore en version N.

Pour aller plus loinRajouter du Reporting/Monitorer (surveillance )

● Sonar● Analyse de logs ===> ELK ● […]

Rajouter des :● Tests fonctionnels● Tests d’accessibilité (Axe-core)● Tests de pénétration (Pentests)● Tests de performance/de charge● Métrologie (Avalanche)● audit sécurité● […]

Feature FlippingRollback ⇒ on relance le pipeline précédent.

QUESTIONS ?

Merci● http://blog.octo.com/feature-flipping/● http://blog.octo.com/zero-downtime-deployment/● http://blog.octo.com/continuous-deployment/● https://github.com/phpro/grumphp● https://about.gitlab.com/2014/09/29/gitlab-flow/● https://www.slideshare.net/MarineKaram/tester-cest-douter-linkvalue-tech