CI/CD, le divorce serait-il prononcé ?

Nos deux tourtereaux

L’origine

CI

Continuous Build

Objectif : Construire l’applicatif

Continuous Integration

Objectif : Valider le code et les métriques

Bref…

CD

Delivery

Objectif : Mettre un livrable à disposition

Deployment

Objectif : Deployer l’application

Development

Objectif : S’assurer que le service fonctionne

Bref…

La rencontre…

Un avenir tout tracé !

Yann

Nicolas

Découvrons la suite de leur histoire

Les petits pipelines

La définition d’un pipeline

C’est un dessin…

… Et des personnes

Yann :

Mais attention, c’est aussi des personnes
Autant côté dev que ops, le process CI/CD impacte beaucoup plus de monde que les équipes de réal.
Market', Direction, Dev, Ops, Designers, Agiliste, etc.
Pour mettre tout le monde d’accord
mais comme tout le monde à toujours raison dans ce milieu
on vous propose une méthode pour vous aider à définir ce pipeline pour que notre couple CI/CD aille bien
Tiré de nos experiences respectives

" Bref, ils ont fini par convier tous les acteurs qui graviteront autour de ces pipelines ! Une sorte atelier où nn regroupe toutes les parties prenantes et ou on modélise les processus pour venir répondre aux contraintes de chacun. Et le plus dur pour nos tourteaux dans ce moment est sans aucun doute de ne pas parler d’outils, ou d’automatisation ! "

Dis, comment on fait des pipelines ?

dis comment

Yann :

Par où on commence pour définir un pipeline ?
Par les objectifs, et pas seulement les objectifs tech
- Classique : qualité, augmenté la vitesse de déploiement, simplifier les actions, etc…
- Moins classique : Laisser les CP faire les livraisons, Automatiser des déploiements de nuit, cadencer la communication commerciale et la mise à disposition du produit, etc…
- Mauvais objectif : faire comme tout le monde, "MAIS C’EST TROP COOL"
D’où l’importance d’avoir tout le monde autour de la table
Besoins spécifiques (perf/sécurité/qualité/accessibilité)
complexité de la construction ou du déploiement (multiplatforme par example)
règles imposées par le contexte (nommage, disponibilité, etc…),

" Ca peut vous sembler évident, mais avant de se lancer, la première question qui se pose est pourquoi ? Bien évidement commencer par définir les objectifs est essentiel à la construction d’un projet commun. Mais les raisons d’être et contraintes des parties prenantes étant tellement différente, cette étape est indispensable. Besoins spécifiques (perf/sécurité/qualité/accessibilité), complexité de la construction ou du déploiement (multiplatforme par example), règles imposé par le contexte (nommage, disponibilité, etc…), ou encore qui peut voir et faire quoi, ne sont que des examples ! "

Event storming

event storming

Yann :

Comme dit précedement, il y a beaucoup de personne qui gravite autour des pipelines
Qui doit voir quoi, quand et avec quel granularité ?
Equipe dev, equipe ops, CP, Agiliste, Big boss, Testeur, etc. pas les mêmes besoins de retour ⇒ Prendre des exemples
Attention si besoin d’intégration aux outils existants (board de direction par exemple, JIRA …)
Faire simple, c’est compliqué
Zoom sur le Fail Fast : un feedback efficace

" Sauf que pour pouvoir orchestrer tout cela, ils le savent : Ils vont avoir besoin de rétroactions (des feedbacks) Mais même ça, ce n’est pas trivial.

Niveau de précision, rapidité et densité des retours, accès aux informations. Des questions qui peuvent sembler simple, mais nous le savons tous : faire simple, c’est compliqué ! Et encore plus si on a déjà de l’outillage existant auquel il faut s’intégrer ! "

Nico :

Les premières prises de décision difficile
Conflits CI/CD, CI veut tout automatiser, CD veut garder le contrôle
D’où l’importance des étapes clés, feedback, etc.
Tout auto n’est pas forcement le mieux
Surtout si process complexe, et silotage important
Définition des déclencheurs, humain ou auto
Debrayage ⇒ on verra après

" Mais derrière cette idylle, les premiers conflits approchent… C’est à ce moment qu’on se rend compte que CI et CD ne sont pas du tout sur les mêmes enjeux, en particulier sur la phase de déploiement !

Et surtout si on se trouve dans des structures organisationnelle dense (complexe), tout automatiser n’est pas toujours (voir rarement) la meilleure solution. Et ce sera l’occasion de définir des déclencheurs qui permettront d’enclencher les étapes suivantes… ou pas ! "

Yann :

On y arrive
Le choix des outils "ENFIN"
Ils doivent répondre aux besoins de feedback, déclenchement, etc.
Un seul pour tous ? Les meilleurs de chaque de domaine ?
Côté CI, c’est plus facile car indépendant du reste de l’entreprise
Côté CD, c’est toujours dépendant de l’infra de la boite, des stacks etc.
Grosse divergence entre CI et CD
Attention : qu’il y a déjà probablement des outils existants dans l’entreprise qui sont connus et maitrisés, rationnalisé, gestion de cout, posez la question et challenger l’existant

" Patience, on approche du but, et surtout, on va parler des choses qu’on aime : les outils ! C’est le moment… Un seul pour les gouverner tous ? Ou le meilleur pour chaque action ?

Les débats d’experts sont très, voir trop, nombreux sur ce sujet, mais ils ont identifié certains consensus. Coté CI, il y a beaucoup de standards. On essai donc de s’y conforter au maximum en fonction de son écosystème (langage). Coté CD, c’est beaucoup plus dépendant des stacks (on premise, cloud, autre…), et des process choisis (fait par les dev, par les ops, etc…) "

periodic ^[1]

1. https://digital.ai/periodic-table-of-devops-tools

Et voilà !

Petit pipeline deviendra grand …

…de manière itérative

Ce que l’on conçoit bien s’énonce clairement, et les mots pour le dire arrivent aisément!^[1]

Nico :

A dire comme ça, ça à l’air simple
Mais c’est au minimum complexe
Ce n’est pas une excuse pour ne pas faire l’exercice, sinon ça va aller dans le mur
Au début, c’est le bordel, évidemment, surtout que, comme tout bon dév, on veut coder !
Si vous mettez des trucs sous le tapis, vous allez, à un moment ou un autre, le voir revenir au galop
Mais vous allez y arriver, comme CI et CD dans leur jolie couple

" Ce qui est clair, c’est que dans la plupart des organisations, dessiner ou modéliser ce qui concerne CI/CD est au minimum complexe. Mais c’est généralement une fausse excuse pour ne pas s’y pencher sérieusement.

Si Ce que l’on conçoit bien s’énonce clairement, et les mots pour le dire arrivent aisément!^[1] ,Il en va de même pour les dessins. Et si vous ne pouvez pas représenter le processus, il y a de grandes chances que vous ne puissiez pas l’appréhender ! "

1. Nicolas Boileau

Une révolution arrive ?

L’élément perturbateur

Tous l’admiraient

Gestion des sources

.angular
.idea
conf
dist
aws
build
docker
docs
node_modules
proxy-backend
src
.browserslistrc
.dockerignore
.editorconfig
.eslintrc.json
.gitignore
.prettierrc
angular.json
CHANGELOG.md
Dockerfile
docker-compose.yml
karma.conf.js
package.json
package-lock.json
README.md
tsconfig.app.json
tsconfig.json
tsconfig.spec.json
Jenkinsfile
launch.bat
site.yml

C’est le bordel

C’est le bordel

.idea
api
docs
ihm
 | .angular
 | conf
 | src
 | .browserslistrc
 | .dockerignore
 | .editorconfig
 | .eslintrc.json
 | .prettierrc
 | angular.json
 | Dockerfile
 | karma.conf.js
 | package.json
 | package-lock.json
 | tsconfig.app.json
 | tsconfig.json
 | tsconfig.spec.json
infra
.gitattributes
.gitignore
.gitlab-ci.yml
docker-compose.yml
README.md

Fusionner les deux process

Yann :

On se retrouve avec les fichiers de conf de CI et CD au même endroit
Il faut donc "merger","fusionner" les fichiers de conf et les pratiques au même endroit
Avant c’était dans des outils/repertoires/dépots différents
Avec chacun ces pratiques, habitudes
Alignement sur le système de branching git pour la CD
Risques d’échec important, embrouilles
les décisions de l’équipe de dev, côté CI, qui étaient autonome, on maintenant un impact sur CD
CD doit s’inscrire dans les habitudes de travail de CI

" …Et c’est bien le cas !

Quand on se retrouve à devoir fusionner deux processus qui ont des habitudes et des manière de travailler très différents, les risques d’échecs sont nombreux. CI et ses commit WIP à n’en plus finir, et CD qui suffixait tout en .old au cas où …

Les habitudes avaient la vie dure, il fallait agir ! "

Comment aider notre petite famille ?

La thérapie de couple

Nico [20 min] :

Côté CI, on sais gérer du code, le maintenir
Côté CI, se tromper, c’est notre quotidien, défaire, refaire etc.
Côté CD, on sais anticiper l’imprévisible, réagir vite aux incidents
Côté CD, bah, non en fait

⇒ P2

" Des deux cotés, leurs point forts ont fait leurs preuves. Dans la famille de CI, les Dev, aucunes actions n’est irréversible, et se planter est finalement le cas nominal ! Et maintenir du code… Ah ça, ils savent faire ! Coté CD, on retrouve plus d’administrateur (ops), de vrais experts pour anticiper l’imprévisible, et surtout pour réagir vite, voir très vite à n’importe quel incident !

Alors nous, à l’origine, nous sommes plutôt de la famille de CI… Et on va essayer de regarder comment certains principes peuvent venir en aide à la belle famille !

Surtout si maintenant on peut coder !!!! "

DRY…

Don’t Repeat Yourself

Exemple

deliver_npm_package:
  script:
    - ./is_it_friday.sh
    - npm publish # Livraison NPM
    - ./alert_ops_team.sh
    - ./send_an_email_to_PO.sh

deliver_app:
  script:
    - ./is_it_friday.sh
    - ftp -u myapp.tar.gz # Livraison FTP
    - ./alert_ops_team.sh
    - ./send_an_email_to_PO.sh

.deliver:
  before_script:
    - ./is_it_friday.sh
  after_script:
    - ./alert_ops_team.sh
    - ./send_an_email_to_PO.sh

deliver_npm_package:
  extends: .deliver
  script:
    - npm publish  # Livraison NPM

deliver_app:
  extends: .deliver
  script:
    - ftp -u myapp.tar.gz # Livraison FTP

Exemple

top-jobs.yaml

.deliver:
  variables:
    DELIVER_TASK: ''
  script:
    - ./is_it_friday.sh
    - $DELIVER_TASK
    - ./alert_ops_team.sh
    - ./send_an_email_to_PO.sh

gitlab-ci.yml

include:
  - project: 'devops-team/tools'
    file: 'top-jobs.yaml'

deliver_npm_package:
  extends: .deliver
  script:
    - npm publish

deliver_app:
  extends: .deliver
  script:
    - ftp -u myapp.tar.gz

…mais pas trop !

Un couple SOLID ?

guylookingatgirl

Une responsabilité unique

SOLID (Single responsibility)

Exemple

package:
  image: node
  before_script:
    - # install my tools :-D
  script:
    - npm run build
    - sonar-scanner ...
    - docker build

single respo 1 bad

build:
  image: node
  script:
    - npm ...

analyse:
  image : sonar-scanner
  script:
    - sonar-scanner ...

publish:
  image: gcr.io/kaniko-project/executor:debug
  script:
    - /kaniko/executor ...

single respo 1 good

Exemple

deploy:
  script:
    - deploy-db.sh
    - deploy-app.sh
    - deploy-doc.sh

single respo bad

deploy_doc:
  ...

deploy_app:
  ...

deploy_db:
  ...

single respo good

Rester ouvert…

SOLID (Open/Closed principle)

Exemple

.bad-sonar:
  variables:
    PROJECT_KEY: ''
  script:
    - |
        sonar-scanner -Dsonar.projectKey=$PROJECT_KEY
        -Dsonar.sources=./src
        -Dsonar.tests=tests/

open closed bad

.good-sonar:
  variables:
    PROJECT_KEY: ''
    SONAR_EXTRA_PARAMETERS: ''
  script:
    - sonar-scanner -Dsonar.projectKey=$PROJECT_KEY \
      -Dproject.settings=./sonar-project.properties \
      $SONAR_EXTRA_PARAMETERS

open closed good

Liskov à la rescousse…

SOLID (Liskov substitution) …ou pas !

Barbara Liskov ^[1]

1. Barbara Liskov

Ségrégation d’interface

SOLID (Interface segregation)

Exemple

template.yaml

build:            #Assemble le Jar
  stage: build
analyse-code:     #Faire les analyses qualité
  stage: test
analyse-package:  #Faire les analyses qualité
  stage: test
package:          #Construire l'image Docker
  stage: package
can-i-deploy:     #Faire les analyses qualité
  stage: test
deploy:           #Déploie dans l'infra
  stage: deploy

interface segragation bad

maven-template.yaml

build:            #Assemble le Jar
    ...
analyse-build:    #Faire les analyses qualité
    ...

docker-template.yaml

analyse-package:  #Faire les analyses qualité
    ...
package:          #Construire l'image Docker
    ...

terrform-template.yaml

can-i-deploy:     #Faire les analyses qualité
    ...
deploy:           #Déploie dans l'infra
    ...

interface segragation good

Une inversion de dépendance ?

SOLID (Dependency inversion)

Exemple

deliver-on-artifactory:
  script: ./push_artefact_to_repo.sh

deploy: # Attend que l'étape de livraison soit ok
  needs: [deliver-on-artifactory]
  script: ./deploy.sh

dependency inversion bad

# Doit déposer l'artefact au bon endroit
deliver:
  script: ./push_artefact_to_repo.sh

# Vérifie que l'artefact soit bien présent
check_artefact_readiness:
  script: ./check_artefact.sh

# Déploie si l'artefact est au bon endroit
# (contrat respecté)
deploy:
  needs: [check_artefact_readiness]
  script: ./deploy.sh

dependency inversion good

Un peu de lacher prise ?

Le risque du "tout automatique"

Nico :

Comme dit precedement, CI et CD ont des divergences, des complémentarités et surtout un même objectif
Même si on arrive à construire un pipeline qui convienne à CI et CD
Et malgré tout ces principes SOLID, on a toujours un problème
Si le pipeline va de bout en bout, même si on fait attention, si le moindre grain de sable se met dans les rouages, ça va pété

" Si on reprend ce qu’on vous a dit précédemment, malgré nos différences, nous avons de vraies convergences, et surtout une grande complémentarité entre ces deux là !

Si on reprend l’enchainement de nos phases qui emmène le code jusqu’en production on voit bien que chacun peut apporter sa pierre à l’édifice. Mais il y a une condition pour ca : Qu’un grain de sable ne vienne pas bloquer toute la chaine. "

Exemple

Jenkinsfile.build

{
  ...,
  stage ('deliver') {
    build '../proj-deliver/master'
  }
}

Jenkinsfile.deliver

{
  stage('check requirements') {}
  stage('Deploy approval') {
    input "Deploy to prod ?"
  }
  stage ('deploy') {
    build '../proj-deliver/master'
  }
}

Jenkinsfile.deploy

{
  stage('check requirements') {}
  ...,
}

Pouvoir debrayer !

Ou l’art de faire des pauses

Nico :

Il faut donc pouvoir debrayer
Mettre des points d’arrêt
L’importance de l’inversion de dépendance
Gain en lisibilité, surtout sur les points d’arrêt défini lors des ateliers de création des pipelines
Pouvoir reprendre/relancer

" Nous en avons un peu parlé sur le D de SOLID, mais la dépendance, aussi inévitable soit-elle, doit être réfléchie. Selon nous, l’une des clés de la réussite réside dans la présence régulière de point d’inférence qui sont bien matérialisé sur ce schéma.

Ainsi chaque phase va à la fois être dépendant du résultat de la précédente, mais indépendant en terme d’action. Si vos pipelines répondent à ces principes vous gagnerez naturellement en lisibilité, et en maintenabilité, et vous aurez la possibilité de débrayer ou non le coté automatique de l’étape ! "

Points d’inférence

Oups …

Le monde des Bisounours

KISS : Keep It Simple Stupid

Qui est ce thérapeute ?

Un plan à trois

L’arrivée…

devops arrival

La boucle est bouclée

devops

Yann :

Mais même si le pipeline allait jusqu’au déploiement
On ne savait pas ce qu’il se passait après la fin du pipeline
On a donc rajouté Monitor (qui n’est pas que du monitoring de plateforme, il permet aussi de vérifier que le deploiement soit OK)
Et plan, pour intégrer les évolutions en fonction de monitor
Et BIM, la boucle est bouclée
Génial d’un point de vue market'

" Mais comment savoir ce qui se passe vraiment ? On conceptualise alors deux phases supplémentaires : Monitor et Plan. La première vis à mesurer ce qui se passe en production, et à le reboucler vers les responsables métier pour qu’ils fassent évoluer les applications. La seconde intègre au processus global la planification des modifications fermant la boucle et la rendant infinie !

Intéressant d’un point de marketing non ? "

L’émergence

Des accompagnateurs

Une question de communication

Nico :

Sauf que souvent, au lieu d’avoir une équipe qui cherche à favoriser la comm' dev et ops
On a une équipe qui se positionne au milieu au lieu d’améliorer l’échange
On se retrouve donc avec une nouvelle équipe qui doit comprendre et le dev, et l’ops
Et DevOps est souvent plus proche de CI, de nouveaux problèmes de communication arrivent avec CD.
Et vu que DevOps, n’est pas CI non plus, il y a donc des problèmes de comm' avec CI

" Et finalement au lieu de favoriser la communication entre deux entités, on en a inventé une troisième qu’on a mise au milieu. Une sorte de médiateur de couple, souvent issu de monde de dev, donc proche de CI. Et on remarque que dans de nombreuses structures, les difficultés de compréhensions demeurent, soit entre la réalisation et l’équipe dite DevOps, soit entre cette dernière et les ops. "

Bref…

Faisons le point

C’est l’heure du choix

Séparation des responsabilités

Construction
Assemblage
Mise en service
Règles

Et pourquoi pas…

Proposer sans imposer, critiquer sans discréditer

Vecteur de la culture DevOps

Nico :

Leur union est plus forte que jamais
Notre choix
Plus d’équipe DevOps, mais une vraie culture
Comme imaginé à la base
Le plus difficile, mais probablement le plus efficace
L’équipe est composée des devs et des ops
L’équipe doit avoir toutes les compétences (on parle de l’équipe, pas de vous tout seul)
Ouverture d’esprit
CI et CD forme un vrai couple pour faire de jolis pipelines ensemble

" C’est sans aucuns doutes notre choix du cœur… Ici, le devops n’est plus une équipe, mais un culture et une pratique d’entreprise, comme imaginez à l’origine.

On peut reconnaitre en revanche que c’est sans doute la proposition la plus délicate à mettre en œuvre. Les compétences de l’ensemble de votre équipe (pas de vous seul hein !) et l’état d’esprit nécessaire pour que tout ce petit monde travaille ensemble n’est pas facile à obtenir. "

CI/CD, le divorce est-il prononcé ?

A vous de jouer !

@nicgiro / @YannSchepens

Références

SOLID
https://fr.wikipedia.org/wiki/SOLID_(informatique)
Event Storming
https://pablopernot.fr/2019/07/event-storming-description/
Software crafter
https://www.slideshare.net/__MaxS__/software-craftsmanship-un-nouvel-eldorado
DevOps
https://fr.wikipedia.org/wiki/Devops

CI/CD, le divorce serait-il prononcé ?

Nos deux tourtereaux

L’origine

CI

Continuous Build

Continuous Integration

Bref…​

CD

Delivery

Deployment

Development

Bref…​

La rencontre…​

Un avenir tout tracé !

Yann

Nicolas

Découvrons la suite de leur histoire

Les petits pipelines

La définition d’un pipeline

C’est un dessin…​

…​ Et des personnes

Dis, comment on fait des pipelines ?

Event storming

Et voilà !

Petit pipeline deviendra grand …​

Une révolution arrive ?

L’élément perturbateur

Tous l’admiraient

Gestion des sources

C’est le bordel

C’est le bordel

Fusionner les deux process

Comment aider notre petite famille ?

La thérapie de couple

DRY…​

Exemple

Exemple

…​mais pas trop !

Un couple SOLID ?

Une responsabilité unique

Exemple

Exemple

Rester ouvert…​

Exemple

Liskov à la rescousse…​

Ségrégation d’interface

Exemple

Une inversion de dépendance ?

Exemple

Un peu de lacher prise ?

Exemple

Pouvoir debrayer !

Points d’inférence

Oups …​

Le monde des Bisounours

Qui est ce thérapeute ?

Un plan à trois

L’arrivée…​

La boucle est bouclée

L’émergence

Des accompagnateurs

Une question de communication

Bref…​

Faisons le point

C’est l’heure du choix

Séparation des responsabilités

Et pourquoi pas…​

CI/CD, le divorce est-il prononcé ?

A vous de jouer !

Références

Bref…

Bref…

La rencontre…

C’est un dessin…

… Et des personnes

Petit pipeline deviendra grand …

DRY…

…mais pas trop !

Rester ouvert…

Liskov à la rescousse…

Oups …

L’arrivée…

Bref…

Et pourquoi pas…