chaine de production pipeline
TRANSCRIPT
DEVOPS : Chaîne de productionMa vision du déploiement
Nicolas Wallerand (Software developer)[email protected]
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