Docker : la CICD a porté de main

Bon, depuis plus d'un an maintenant, je me suis à Docker : D'abord doucement, sans vraiment comprendre et en utilisant des templates. Depuis quelques mois, je cherche à pousser plus loin : Créer mes propres images, mes propres pipelines.

Du coup, aujourd'hui on va causer CICD (enfin surtout CI, j'ai pas encore trop trop testé docker en prod sur mon temps libre, donc pas vraiement de déploiement)

Déjà, pourquoi ?

On ne veut pas livrer des applications qui marchent : on veut livrer des applications qui perdurent dans le temps. Et c'est là ou docker peut rentrer en jeu sur plusieurs aspects : 1. Homogeniété des environnements => T'installes ton IDE préféré, un petit coup de docker compose up, et t'es parti avec un environnement opérationnel, iso des autres devs et environnements. 2. Reproductibilité => Dev = Qa = .... = Prod , si ça marche en dev, ça marche en QA , ça marche en prod. Si les environnements et les composants sont iso partout pas de surprises ! 3. Securité => Une image minimal que ce soit en terme de paquet (git, npm, composer...) , d'accès ou d'user 4. Une pipeline d'intégration locale => Définition des étapes et on obtient l'image final que l'on va envoyer à l'étape suivante, qui une fois validé partira à l'étape suivante tel quel et ainsi de suite

Ensuite comment ?

Ce qui nous intéresse aujourd'hui c'est le point 4. une pipeline locale , permettant de jouer vos tests, et vos outils ( phpstan , mago ...). En ce moment, j'suis en plein monté en compétence sur docker : Déjà au niveau pro, j'm'occupe pas directement des fichiers docker mais j'utilise les pipelines de déploiement, j'vais fouiller dans les logs des pods, par la force des choses, je me retrouve à utiliser (et c'est tant mieux) des environnements construits via du docker (et du kubi). Bon revenons à nos containers. On veut que chaques devs qui arrivent sur le projet (projet, open-source...) puisse démarrer le projet facilement, vérifier son fonctionnement et vérifier si les Tests (TU, TI , TA) sont ok. Alors soit ça va être "bricoler" , avec des explications dans le README. On peut avoir un script qui automatise le déploiement, un script qui fait les tests etc... Soit, on peut chercher à centraliser ce process et à le simplifier (devops quoi) C'est là ou docker rentre en jeu : Tu construits ton image docker, ton docker file et chaque dev arrivant sur le projet n'a pas besoin de savoir (pour l'instant) qu'il faut tel base de donnée, tel system de cache, tel systeme de mail... C'est ton docker qui fournit tout ce qui est nécéssaire. Et ça va encore plus loin : Dans la construction de ton image , tu peux définir des étapes de builds => Etape 1 => On construit l'image de base (téléchargemetn des depenses, run des installations , compilations des assets blalbla....) Etape 2 => On joue les tests unitaires Etape 3 => On joue les tests d'intégrations Etape 4 => On joue les outils de qualimétrie Etape 5 => On construit une image minimale