Devops chaine de production utilisation pipeline avec gitlab-ci

1. DEVOPS : Chaîne de production
Ma vision du déploiement
Nicolas Wallerand (Software developer)
n.wallerand@gmail.com

2. DEVOPS
Le 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

3. Automatiser le déploiement

4. PIPELINE
Un 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 Monolithique
Application 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

5. 12 factors
I. 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

6. 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.

7. Les grands Principes
● Continuous Integration
● Continuous Delivery
● Continuous Deployment

8. Continuous Integration
TEST BUILD
Test Unitaire
Test Sécurité
[...]
Déploiement automatique
(packagist/Satis/Artifactory)
Mise à jour automatiquement
de la version du composer.json
Modifier le fichier changelog
Exemple d’utilisation :
Pour des librairies qui sont utilisées seulement en dépendance d’un projet.
(Monologue,Acl,etc…)
Stage

9. Continuous Delivery
TEST BUILD DEPLOY
Test Unitaire
Test Sécurité
[...]
Minification/Concat
Dépendances
Push 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

10. Continuous Deployment
TEST BUILD DEPLOY
Test Unitaire
Test Sécurité
Tests d'intégration
Test IHM
Test de performance
[...]
Minification/Concat
Dépendances
Push 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

11. 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.)
● [...]

12. DEMO*
(* avec des slides)

13. 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

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

16. Le développeur travaille sur son Issue/feature
CODE
COMMIT
PUSHFeature-branch
HOOK GIT

17. HOOK GIT / Script de pre-commit
Grâ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

18. 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éveloppeur
Tout les jobs sont exécutés automatiquement
(remontée des erreurs)
App interne de review
utilisation de l’api-gitlab
Jobs
Quand le
développeur
estime avoir fini,
il demande une
validation
(CP/MOA)
SOUMISSION
Merge Master
Code review
Déployer un
environnement
propre à la feature
(vhost Apache)Intégration continue
Un pipeline de jobs va s'exécuter sur les branches features
Pour Faire Simple ( pas de branche release/develops)

19. 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 construite
L’application est déployée sur le serveur d’intégration

20. 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).
● […]

21. Stage BUILD
Ce 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.

22. 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).
● […]

23. 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

24. Stage VALIDATION INTÉGRATION
Ce 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

25. Application review
Grâ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 ».

26. Stage VALIDATION MERGE
Ce 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é.

27. Accept le merge
Request
La feature est mergée avec la master
Le techLead

28. Exécution du pipeline sur la branche master
Grâce au job décrit dans le fichier gitlab-ci.yml , à chaque push d’un
code 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

29. 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.

30. Pour aller plus loin
Rajouter 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 Flipping
Rollback ⇒ on relance le pipeline précédent.

31. 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