10 - Keep development, staging and production as similar as possible
Bah oui, on veut éviter le "ça marche sur ma machine pourtant". Si le développeur est capable de tester en condition de production, c'est pas mal de bug trouvés à la source.
Bah là je suis moyen d'accord...
Alors staging et production identiques, c'est une évidence, mais les environnements de dev peuvent être bordéliques.
Justement pour avoir du « ça marche chez moi mais pas en staging », comprendre pourquoi, et savoir dans quelles conditions réelles ton bouzin peut ou pas fonctionner.
Si par exemple t'as un truc en Python et qu'un des dev a une pile pas très à jour avec encore un python 3.6 antédiluvien, le jour où ça explose chez lui, tu peux dire « minimum requis = python 3.7 ».
Sinon, bah tu sais pas, et en général, quand on est sérieux, on préfère savoir.
Ça fonctionne dans l'autre sens aussi, un DEV qui fait du PHP 8.1 au lieu du 7.4 de la prod, et qui a un comportement bizarre, va pouvoir préparer la migration future vers PHP 8 en pré-corrigeant des soucis, ou peut-être simplement prévenir que tel truc va péter le jour où on voudra migrer en PHP 8.
Il y a moyen de voir apparaître des bugs masqués par telle version d'une dépendance mais pas telle autre, etc.
Bref, des environnements de dev hétéroclite, ce n'est pas obligatoirement un mal.
Par contre, ya pas photo, ça n'a aucun sens d'avoir une pré-prod qui ne soit pas autant que possible un clone de la prod.
[^] # Re: Explication
Posté par Yth (Mastodon) . En réponse au journal Douze facteurs dans ta tronche. Évalué à 5.
Bah là je suis moyen d'accord...
Alors staging et production identiques, c'est une évidence, mais les environnements de dev peuvent être bordéliques.
Justement pour avoir du « ça marche chez moi mais pas en staging », comprendre pourquoi, et savoir dans quelles conditions réelles ton bouzin peut ou pas fonctionner.
Si par exemple t'as un truc en Python et qu'un des dev a une pile pas très à jour avec encore un python 3.6 antédiluvien, le jour où ça explose chez lui, tu peux dire « minimum requis = python 3.7 ».
Sinon, bah tu sais pas, et en général, quand on est sérieux, on préfère savoir.
Ça fonctionne dans l'autre sens aussi, un DEV qui fait du PHP 8.1 au lieu du 7.4 de la prod, et qui a un comportement bizarre, va pouvoir préparer la migration future vers PHP 8 en pré-corrigeant des soucis, ou peut-être simplement prévenir que tel truc va péter le jour où on voudra migrer en PHP 8.
Il y a moyen de voir apparaître des bugs masqués par telle version d'une dépendance mais pas telle autre, etc.
Bref, des environnements de dev hétéroclite, ce n'est pas obligatoirement un mal.
Par contre, ya pas photo, ça n'a aucun sens d'avoir une pré-prod qui ne soit pas autant que possible un clone de la prod.