Avoir différents environnements
Combien nécessaires ?
Production
Cela va dépendre de votre produit et de vos préférences. Par exemple, quand vous rédigez un article sur un blog, il est fort probable que vous fassiez vos modifications directement sur ce qu'on pourrait appeler "environnement de production". Et cela s'y porte très bien, car l'outil reste peu complexe et la prise de risque est donc faible.
Development
Quand vous faites du développement informatique (avec une équipe de plus d'1 personne), il y a un moment où vous voulez normalement montrer ce qui a été développé à des personnes associées au projet, aussi pour qu'elles testent avec des vérifications manuelles. Il est peu probable que des personnes non-techniques téléchargent le code technique, installent ce qu'il faut (base de données…), pour enfin lancer le produit localement et pouvoir le tester. Le plus simple est donc de leur mettre à disposition un environnement de développement (ou de test, suivant votre nommage).
Il peut être intéressant de le différencier de la production via un bandeau dans le header pour éviter de malencontreuses actions. Et aussi de sensibiliser les testeurs sur le fait d'utiliser des données "fake" non-sensibles car cet environnement peut être manipulé par plus de monde que la production.
Aussi, si le code est open source et que personne n'utilise ses données personnelles, il n'est pas nécessaire de vous embêter à le mettre derrière un proxy type oauth2-proxy. Pour la sécurité :
- Il est surtout important de ne pas utiliser les mêmes instances (applicatif et stockage) que la production en cas d'infiltration ;
- Pour mitiger le risque de données sensibles oubliées dedans vous pourriez tous les X mois faire un reset avec un jeu de données de test.
L'environnement de développement peut cohabiter avec des environnements éphémères (par fonctionnalité développée, souvent appelés "review apps"), voire même être remplacé par ceux-ci.
Staging
Certains projets ont un environnement de recette intermédiaire entre development et production, qui est censé représenter la production sans pourtant l'être, avec des jeux de données de production anonymisés par exemple. Ce qui veut dire qu'une modification doit passer development → staging → production, rajoutant une étape de test qui n'est pas forcément soutenable pour une équipe.
L'utilité du staging va surtout dépendre de la criticité de votre projet. Si vous pouvez vous permettre de parfois pousser des erreurs en ayant l'agilité de les corriger rapidement, n'avoir que development + production permet de rester simple.
Comment ça s'organise ?
Les environnements sont souvent différenciés par des branches Git différentes, qui, à chaque commit, seront déployées.
Il y a pas mal de standards pour gérer à la fois les environnements "runtime", ainsi que les branches correctives ou de fonctionnalités (Gitflow, GitHub flow, Gitlab flow…). Nous choisissons Gitflow comme base en l'adaptant en fonction des phases d'avancement du projet (peut-être pas besoin des branches release, peut-être pas besoin de branches de feature si qu'un seul développeur…). L'important est d'être à l'aise pour éviter de perdre du temps, conciliez-vous au début du projet.