<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Ci-Cd :: Tag :: Ma documentation</title><link>https://quentinpigne.github.io/tags/ci-cd/index.html</link><description/><generator>Hugo</generator><language>fr-FR</language><atom:link href="https://quentinpigne.github.io/tags/ci-cd/index.xml" rel="self" type="application/rss+xml"/><item><title>CI/CD</title><link>https://quentinpigne.github.io/devops/ci-cd/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://quentinpigne.github.io/devops/ci-cd/index.html</guid><description>Introduction Les pipelines CI/CD permettent un passage simplifié et sécurisé du code en production. Ils doivent s’assurer qu’une application est correctement compilée/assemblée, testée et déployée.
Le principal objectif d’un pipeline CI/CD est de réduire les risques liés à une mise en production. En fournissant au plus tôt un retour sur la qualité du code, les tests et en faisant du déploiement un process simple et répétable. Le déploiement cesse ainsi d’être un évènement exceptionnel et devient fréquent.</description></item><item><title>Mise en œuvre</title><link>https://quentinpigne.github.io/architecture/c4/structurizr/mise-en-oeuvre/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://quentinpigne.github.io/architecture/c4/structurizr/mise-en-oeuvre/index.html</guid><description>Du fichier workspace.dsl à des diagrammes consultables, versionnés et vérifiés en intégration continue.
Le serveur local C’est la façon la plus rapide de voir ses diagrammes : un conteneur Docker qui lit un workspace.dsl dans un dossier et sert une interface web.
docker run -it --rm -p 8080:8080 \ -v "$PWD:/usr/local/structurizr" \ structurizr/structurizr local Warning La commande était auparavant l’image structurizr/lite, sans argument — forme que l’on trouve encore partout en ligne. Elle est dépréciée et n’affiche plus qu’une bannière de migration. Le point de montage et le port sont restés identiques, la migration se réduit donc à changer le nom de l’image et à ajouter local.</description></item><item><title>Tests d'architecture</title><link>https://quentinpigne.github.io/architecture/tests-architecture/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://quentinpigne.github.io/architecture/tests-architecture/index.html</guid><description>Toutes les règles posées dans cette section ont un point commun : ce sont des intentions. « Le domaine ne dépend de rien », « une couche n’appelle que celle du dessous », « seule la façade du module est importable », « aucun ORM dans le domaine ». Rien, dans un dépôt ordinaire, ne les empêche d’être violées — et une règle d’architecture non vérifiée est violée en quelques semaines, sans mauvaise volonté de personne.</description></item></channel></rss>