L'article présente PDM et uv, deux outils modernes pour la gestion de projets Python, offrant des avantages significatifs par rapport à pipenv et poetry. PDM gère les dépendances, les environnements virtuels et la publication de paquets sur PyPI, tandis que uv accélère l'installation des dépendances et optimise l'utilisation du disque grâce à des liens matériels. L'auteur explique comment installer et configurer ces outils, soulignant leur efficacité et leur simplicité d'utilisation, notamment pour les intégrations continues (CI/CD). Un résumé des avantages et des étapes d'installation est fourni, mettant en avant la supériorité de cette combinaison pour les développeurs Python.
L’article recommande d’abandonner Kaniko et de ne pas se précipiter sur Docker BuildX pour la construction d’images de conteneurs en CI/CD, en proposant plutôt Buildah comme solution plus simple et plus robuste, car il permet de construire des images OCI sans dépendre d’un daemon Docker ni d’une configuration complexe souvent nécessaire avec Docker-in-Docker ou BuildX. L’auteur explique que Kaniko a été abandonné et que BuildX reste fortement lié à l’écosystème Docker et à son daemon, alors que Buildah, issu de l’écosystème Podman, fonctionne de manière plus légère et s’intègre facilement dans des pipelines CI pour construire et pousser des images, éventuellement même via une API sans Dockerfile.
Pour remplacer son instance GitLab auto-hébergée (trop gourmande en ressources pour un usage personnel), l’auteur a migré vers Forgejo (fork de Gitea) en utilisant Terraform pour automatiser la transition. Plutôt que d’utiliser des scripts de migration obsolètes, il a exploité les providers Terraform pour GitLab et Gitea/Forgejo : le code liste les projets source, les recrée en mode miroir sur la nouvelle forge, puis bascule le domaine. La CI/CD a été réécrite en workflows Forgejo Actions (similaires à GitHub Actions), simplifiant le processus et réduisant significativement la consommation de ressources (10 Go de RAM et 10 % d’espace disque gagnés). Une approche efficace et maintenable, qui montre comment détourner Terraform pour des besoins ponctuels. Le gain en performance et en simplicité est notable, surtout pour un petit serveur.
L’article détaille la mise en place d’un pipeline GitLab CI pour un projet Symfony, avec les étapes clés suivantes :
-
Automatisation des tests (unitaires, fonctionnels) à chaque Merge Request ou push, en utilisant SQLite pour les tests (plus léger que PostgreSQL).
-
Configuration du fichier
.gitlab-ci.yml:- Définition des stages (
build,test). - Utilisation d’images Docker (PHP 8.3, Node 21.7) pour exécuter les jobs.
- Installation des dépendances (Composer, npm) et exécution des tests via PHPUnit.
- Gestion des fixtures et du schéma de base de données en environnement de test.
- Build des assets front-end (Webpack Encore) avec partage des artefacts entre jobs.
- Définition des stages (
-
Blocage des merges si les tests échouent, via l’option "Pipelines must succeed" dans les paramètres de GitLab.
-
Bonus : Pistes pour aller plus loin (analyse statique avec phpstan, audit de sécurité, déploiement automatique).
L'article explique comment déployer un projet Symfony en utilisant la pipeline CI/CD de Gitlab. Il donne aussi quelques conseils et bonnes pratiques
L'article explique comment utiliser les fichiers .http pour tester des API et augmenter la couverture de code sans écrire de tests d'intégration complexes. Les fichiers .http sont des fichiers texte simples qui décrivent des requêtes HTTP et peuvent être exécutés directement depuis des IDE populaires comme IntelliJ, Visual Studio et VSCode, ou en ligne de commande.
L'auteur propose d'utiliser ces fichiers dans les pipelines CI/CD pour exécuter des tests d'API et collecter la couverture de code. Il mentionne l'outil httpyac pour exécuter les fichiers .http en ligne de commande et dotnet-coverage pour instrumenter les binaires et collecter la couverture de code sans framework de tests.
L'article fournit également des exemples de commandes pour exécuter ces outils et intégrer les tests dans des pipelines Azure DevOps et GitHub Actions
.
Dagger est un outil permettant de lancer des pipelines CI/CD en local sans utiliser de plateformes, le tout étant piloté par le langage de programmation de votre choix.
Novops charge les secrets (stockés dans un gestionnaire par exemple) en mémoire en général sous forme de variables d'environnements. Il s'intègre très bien dans une pipeline CI / CD.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre