Intégration continue / Déploiement continu
https://slides.com/benjichaz/but3-ci-cd
Ingénieur en développement
spécialisé front-end
Chez Matawan
Éditeur de logiciel pour le monde du transport de voyageur
8 heures
Aujourd'hui
Évaluation par DS (QCM)
iut@chazelle.pro
06 51 23 51 39
Intégration continue
Déploiement continu
Projet CircleCI + IBM Cloud
Comprendre ce qu'est la CI/CD
Mettre en place une CI/CD
Approche de développement logiciel où les changements de code sont régulièrement et systématiquement intégrés et testés (CI: Intégration continue) avant d'être automatiquement déployés (CD: Déploiement/Livraison continu/e) dans un environnement de production, permettant ainsi des mises à jour fréquentes et fiables du logiciel.
CI
CD
Dev
Ops
Philosophie de collaboration menant vers l'automatisation
Automatisation de l'intégration et du déploiement
Définir les attendus techniques et fonctionnels de la tâche / du projet.
Qui ? Product Manager, Product owner, ...
CI
CD
Ajouter l'incrément de code nécessaire à la réalisation de la tâche/projet.
Qui ? Développeur
Comment ? Système de gestion de version (git, ...)
Note: Dès cette étape, au push/au merge, ici, on peut déjà avoir déjà des vérifications automatiques CI (tests unitaires, lint, compilation, ...)
CI
CD
Compiler ou assembler le code pour créer le produit final. En plus du code buildé, cette étape peut produire des artefacts (rapport de compilation, ...)
Qui ? Processus automatiques CI à la fusion d'un incrément
Comment ? Pipeline CI (GitHub Actions, CircleCI, Jenkins, Travis CI ...), compilateurs / transpileurs / bundlers (Webpack, Rollup, ...)
CI
CD
Vérifier le fonctionnement du produit afin de détecter et corriger les erreurs éventuelles.
Qui ? Humains et processus automatiques
Comment ? Tests d'intégrations (Selenium, Cypress, Puppetter, ...)
CI
CD
Persister le code (et/ou le build) du produit pour être prêt à être mis à disposition .
Qui ? Processus automatiques CD
Comment ? Git release, registry (npm, composer, ...)
CI
CD
Mettre le produit ou le service sur un environnement à disposition des utilisateurs (production ou autre).
Qui ? Processus automatiques CD
Comment ? Transfère de fichier (FTP, SSH, ...)
CI
CD
Gérer et maintenir le produit ou le service en fonctionnement.
Qui ? DevOps
Comment ? Instances serveur (AWS EC2, Azure VM, Google Compute Engine, ...)
CI
CD
Observer et contrôler le produit ou le service pour garantir son bon fonctionnement.
Qui ? DevOps
Comment ? Outils de monitoring (Grafana, New Relice, Azure Monitor, Google Cloud Monitoring, ...)
CI
CD
Mettre en œuvre par des processus qui se lancent, s’exécutent et se terminent tout seul.
CircleCI |
Pipeline > Workflow > Job > Step |
GitHub Actions | Workflow > Job > Step > Action |
Jenkins | Pipeline > Job > Build |
GitLab CI/CD | Pipeline > Job > Stage |
Travis CI | Build > Job > Stage |
Microsft Azure DevOps | Pipeline > Job > Step |
Google Cloud Build | Build > Step |
# Job : Tests unitaires
Step 1 : npm install
Step 2 : npm run unit-tests
# Job : Type-checking
Step 1 : npm install
Step 2 : npm run type-check
# Job : Lint
Step 1 : npm install
Step 2 : npm run lint-check
Workflow : CI Frontend
Trigger
Success / Fail
Les jobs d'un workflow s’exécutent en parallèle par défaut,
toutefois, on peut les configurer pour être séquentiels
Déclenché par git ou manuellement
Workflow : CI Frontend
Workflow : CI Backend
Workflow : CD
Pipeline
Success / Fail
Success / Fail
Success / Fail
Trigger
?
?
?
Un workflow peut être conditionné
Par exemple sur une branche
Les workflows s’exécutent en parallèle par défaut,
toutefois, on peut les configurer pour être séquentiels
Push trigger : Push sur une branche ou n'importe quelle branche du repository
Pull Request trigger : Pull request ouverte sur le repository
Approval trigger : Pull request approuvé sur le repository
Scheduled trigger : Planifié à une heure ou un intervalle de temps régulier
API trigger : Via CircleCI API.
Manual trigger : Via le dashboard CircleCI dashboard or via API.
Webhook : Via un l'appel d'une URL HTTP
Workflow : CI Frontend
Workflow : CI Backend
GitHub Check
Trigger git push sur
feat/add-button
Success
Fail
Bloqué le merge d'une Pull Request sur GitHub
Success équivaut à un processus (au sens UNIX du terme) qui retourne un code de retour 0. Tout autre status fera tomber le job et son workflow en Fail
# Job : Tests unitaires
Step 1 : npm install
Step 2 : npm run unit-tests
Logiciel
Matériel
Les services CI/CD offrent souvent la possibilité de choisir dans quel environnement exécuter les pipelines CI/CD.
Conteneur, machine virtuelle...
CPU, GPU, Internet ...
# Job : Tests unitaires
Step 1 : npm install
Step 2 : npm run unit-tests
Partie exécutante de bas niveau du processus automatique.
S'appuie sur un approche script :
main ────o───────────────────────o────── Lors d'un git push/merge : CD
\ /
\ /
develop ───────o───o───o─────────o───────── Lors d'un git push/merge : CI
\ /
\ /
feat/*** ──────────────────o───o──────────── Lors d'un git push : CI
Méthodologie de gestion de branches pour les dépôts Git. Elle propose un modèle avec des branches spécifiques pour les fonctionnalités, les versions et la maintenance, facilitant le développement collaboratif et la gestion des releases.
GitHub permet de définir des règles de protection sur les branches du repository avec un nom ou un pattern de nom donné
Cela peut servir à :
Une "release" est une version précise d'un logiciel à un moment donné. Matérialisé par une persistance du code (et/ou de son build) à un endroit donné (GitHub release, registry npm, ...)
42.10.27
Major
Minor
Patch
Majeur : Changements majeurs, pas toujours rétrocompatibles (breaking change)
Mineur : Ajout de fonctionnalités sans changer la rétrocompatibilité.
Patch : Corrections de bugs ou améliorations mineures sans ajout de nouvelles fonctionnalités.
42.10.27
Major
Minor
Patch
Prochaine version majeur : 43.0.0
Prochaine version mineur : 42.11.0
Prochaine version patch : 42.11.28
SSH, ou Secure Shell, est un protocole de communication sécurisé utilisé pour accéder à distance à des ordinateurs et pour exécuter des commandes de manière sécurisée sur des réseaux.
SSH permet également le transfert de fichier de manière sécurisé, ce qui en fait un protocole de choix pour les équipes DevOps en charge de gérer les déploiements.
Le plus souvent, SSH est authentifié à l'aide d'une paire de clés asymétrique : une clé privée (gardée par l'utilisateur) et une clé publique (partagée sur les serveurs) pour une authentification sécurisée sans transmettre de mot de passe.
Un mode username/password existe, mais il n'est pas recommandé.
(symlink) current/
(directory) releaseA/
(symlink) current/
(directory) releaseA/
(directory) releaseB/
scp /cd_runner/releaseB root@remote:releaseB
(symlink) current/
(directory) releaseA/
(directory) releaseB/
ssh root@remote "rm current" ssh root@remote "ln -s releaseB current"
(symlink) current/
(directory) releaseB/
ssh root@remote "rm releaseA"
Cette approche permet de minimiser les risques de pannes en cas de problèmes lors du transfert des fichiers.
Il permet également de drastiquement réduire le temps où l'application n'est plus disponible.
Mettre en place une CI/CD pour automatiser les vérifications à l'intégration, ainsi que la release et le déploiement d'un petit projet Vue.js/Express.
Avec GitHub, CircleCI et IBM Cloud.
Le projet n'est pas noté mais...
CI
CD
Release du code
Pas de réel tests
d'intégration
release
Aspects Operate et Monitor absents
Release du build
via SSH
Pour des raisons de simplicité
Si vous allez au bout de la mise en place de la CI/CD
Chaque question a UNE SEULE bonne réponse.
Chaque réponse juste rapporte un point, chaque réponse fausse soustrait un point, et chaque réponse non répondue ne rapporte ni ne soustrait de point.
Pour chaque question, ÉCRIRE la lettre de la réponse correcte à vos yeux en dessous du numéro de la question, dans le tableau-ci dessous.
Q | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ... |
R | A | B | C | D | A | B | C | D | ... |
Mâcon ou Lyon
Télétravail possible
Cœur de métier sympa
Équipes bienveillantes et compétentes
A vous de jouer