Donc quand il parle de l'environnement de développement, il parle plutôt d'un environnement d'intégration.
Imagine le workflow suivant :
la branche main est déployée en continu sur l'environnement de dev, le développeur teste son travail
on tag une vX.Y.Z, ce tag est déployé sur la staging, les QA testent l'ensemble de l'application
après validation par les QA, la staging est promu en production
Bien sûr qu'on ne va pas demander au développeur de faire tourner toute l'infra kubernetes sur sa machine. Le développeur est responsable de sa machine.
Dans mon "ça marche sur ma machine" il fallait comprendre "je comprends pas pourquoi ca fonctionne en staging et pas en prod". Si la prod utilise PHP 7.4, ben tu utilise PHP 7.4 partout.
Si un développeur se lance la mission de passer en PHP 8, il commence par sa machine, ensuite on upgrade la staging, puis on upgrade la prod. Avec de "l'Infrastructure as Code" ce process d'upgrade (et de rollback en cas de soucis) devient plus simple.
[^] # Re: Explication
Posté par David Delassus (site web personnel) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 2.
12factor parle de déploiement.
Donc quand il parle de l'environnement de développement, il parle plutôt d'un environnement d'intégration.
Imagine le workflow suivant :
Bien sûr qu'on ne va pas demander au développeur de faire tourner toute l'infra kubernetes sur sa machine. Le développeur est responsable de sa machine.
Dans mon "ça marche sur ma machine" il fallait comprendre "je comprends pas pourquoi ca fonctionne en staging et pas en prod". Si la prod utilise PHP 7.4, ben tu utilise PHP 7.4 partout.
Si un développeur se lance la mission de passer en PHP 8, il commence par sa machine, ensuite on upgrade la staging, puis on upgrade la prod. Avec de "l'Infrastructure as Code" ce process d'upgrade (et de rollback en cas de soucis) devient plus simple.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg