Ce billet met en lumière l'importance de définir des valeurs par défaut sûres pour les drapeaux (flags) dans les scripts et commandes. L'auteur, Zhe Lu, illustre comment une simple omission, comme oublier le drapeau --dry_run, peut entraîner des conséquences graves. Il recommande de choisir des valeurs par défaut qui minimisent les risques d'erreurs coûteuses, comme par défaut un mode "dry run" ou l'ajout de confirmations explicites. Il souligne également l'importance de rédiger des documentations avec des exemples sécurisés, en évitant les valeurs par défaut dangereuses. Enfin, il suggère de rendre obligatoires les drapeaux spécifiques à l'environnement pour éviter les mélanges de configurations.
L'article explique comment utiliser SOPS (Secrets OPerationS) pour chiffrer et gérer des secrets dans des dépôts de code, seul ou en équipe. Il couvre l'installation de SOPS et de age (outil de chiffrement), la création de paires de clés, et trois cas d'usage : chiffrer des variables d’environnement, des secrets Kubernetes, et des secrets pour des flakes Nix. L'article détaille également l'installation manuelle de SOPS sur des distributions non supportées et fournit des commandes pour chiffrer un fichier texte.
Julien Wittouck, architecte freelance et formateur, partage son expérience en passant de direnv à mise pour la gestion des variables d'environnement et des outils de développement. Il explique les limites de direnv et les avantages de mise, qui offre une gestion de packages, de variables d'environnement et d'exécution de tâches, tout en étant extensible via des plugins. Il détaille l'installation sur Linux et la configuration du shell pour une intégration fluide.
mise-en-place est un outil polyvalent pour la gestion des environnements de développement. Il permet de gérer les versions des outils (remplaçant asdf, nvm, etc.), de basculer entre différents ensembles de variables d'environnement (remplaçant direnv) et d'exécuter des tâches (remplaçant make ou les scripts npm). Licencié sous MIT, il est maintenu par @jdx et d'autres contributeurs.
L’article explique deux approches pour gérer plusieurs environnements (développement, staging, production) avec Docker : une approche inspirée de Rails, utilisant des Dockerfiles séparés (ex: Dockerfile.dev, Dockerfile.prod), et une approche idiomatique Docker basée sur les multi-stage builds. La première méthode offre une séparation claire, mais peut entraîner de la duplication de code, tandis que la seconde permet de centraliser la configuration dans un seul fichier, réduisant la redondance et facilitant la maintenance, bien qu’elle puisse devenir complexe à mesure que les builds se sophistiquent. L’auteur souligne que le choix dépend de la complexité des environnements et de l’expérience de l’équipe avec Docker.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
La commande en question
SET >> %userprofile%\Downloads\variables_env.txt
L'astuce concerne surtout l'idée d'une base par environnement (dev, test)
Présentation de devbox, un outil basé sur les paquets Nix et qui permet de se construire des environnement isolés - un complément à Docker ?
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
Intéressant... un outil basé sur Docker pour générer des environnements de développement web complets (avec php, apache / nginx, mariadb / mysql / ..., etc.)