Je cherche à mettre en place des environnements test et production pour créer un site web avec django mais je n'ai jamais travaillé en situation réelle de "production" dans une boite informatique.
Pour avancer dans cette direction je recommande une approche par petit pas.
Avant de commencer il faut faire quelques choix techniques, ma proposition serait la suivante:
Faire du développement sans branches, cela élague la complexité. (trunk-based development) Cela a des conséquences sur la façon dont travaille l'équipe mais si l'équipe c'est toi, on peut sauter cette partie. :-)
Faire du déploiement continu. Un commit poussé est un commit déployé.
Avant de te lancer en production, si tu n'es pas familier de la technique, c'est plus facile de créer un environnement de laboratoire et une technologie comme docker permet de faire cela assez facilement.
Tu crées 3 environnements (docker compose) un pour la chaîne de livraison (pipeline), un pour le bac à sable (sandbox) et un pour la production (production). Dans la pipeline il ya un logiciel de CICD qui tourne, comme Jenkins ou GoCD par exemple. Dans tes environnements sandbox et production il y a le classique TIER3: Jango, BDD, et HAPROXY ou APISIX. Une fois que ton laboratoire est opérationnel tu peux le modifier pour le faire marcher ailleurs.
-est ce que je fais un github action qui déploie ma branche production automatiquement sur un serveur production et un github action qui déploie ma branche "test" automatiquement sur un autre serveur ou est ce que je met mes deux environnement test et prod sur le meme serveur?
Test et prod sont sur des serveurs différents: est-ce que ton environnement de production a le droit de planter ou de fonctionner en performance dégradée si tes tests mettent la machine ko? Est-ce que la bdd de test a le droit d'arriver en production suite à une erreur de configuration? Si tu veux rendre ces erreurs aussi peu plausibles que possible, utilise des serveurs différents et des droits d'accès différents. (Par exemple sur Gandi ou AWS: des comptes différents).
-comment faire référence à la meme base de données dans django pour le test et la production?
Tes environnements sont séparés, donc cela n'a pas le droit d'arriver. Maintenant, tu peux vouloir utiliser un snapshot de la BDD en production dans les tests. Ta pipeline doit pouvoir initialiser la BDD avec un snapshot arbitraire. Ensuite il faut s'équiper pour éliminer plein de choses des snapshots: artefacts cryptographique et tokens d'authentification, données personnelles, données business. (C'est en principe plus facile de créer des données synthétiques que d'adapter les données de production pour les tests.)
-Dois je avoir 3 bdd ? (une test, une production et une de sauvegarde) ?
En général deux (si tu travailles sans redondance), des snapshots si possible et des sauvegardes fichier.
-je comprend comment pousser du code sur des branches distinctes, mais j'ai du mal à comprendre comment git gere les branches en local : est ce que je peux configurer git pour que quand je modifie mon code dans un repertoire ca ne le modifie que sur une des branches? ou dois je distinguer un repertoire prod et un repertoire test ?
Quand tu modifies, du point de vue de git (commit) cela se fait toujours sur la branche en cours. Tu n'as pas forcément besoin de travailler avec des branches, et surtout pas pour distinguer "test" et "prod": cela se fait via un fichier de configuration ou des variables d'environnement.
Pour démarrer, fait des petits pas, un environnement de laboratoire. Ton premier test est de faire un cURL qui marche sur ton site déployé. Bonne chance!
# Faire des petits pas
Posté par Michaël (site web personnel) . En réponse au message aspects concrets des environnement test et environnement de production. Évalué à 5.
Pour avancer dans cette direction je recommande une approche par petit pas.
Avant de commencer il faut faire quelques choix techniques, ma proposition serait la suivante:
Faire du développement sans branches, cela élague la complexité. (trunk-based development) Cela a des conséquences sur la façon dont travaille l'équipe mais si l'équipe c'est toi, on peut sauter cette partie. :-)
Faire du déploiement continu. Un commit poussé est un commit déployé.
Avant de te lancer en production, si tu n'es pas familier de la technique, c'est plus facile de créer un environnement de laboratoire et une technologie comme docker permet de faire cela assez facilement.
Tu crées 3 environnements (docker compose) un pour la chaîne de livraison (pipeline), un pour le bac à sable (sandbox) et un pour la production (production). Dans la pipeline il ya un logiciel de CICD qui tourne, comme Jenkins ou GoCD par exemple. Dans tes environnements sandbox et production il y a le classique TIER3: Jango, BDD, et HAPROXY ou APISIX. Une fois que ton laboratoire est opérationnel tu peux le modifier pour le faire marcher ailleurs.
Test et prod sont sur des serveurs différents: est-ce que ton environnement de production a le droit de planter ou de fonctionner en performance dégradée si tes tests mettent la machine ko? Est-ce que la bdd de test a le droit d'arriver en production suite à une erreur de configuration? Si tu veux rendre ces erreurs aussi peu plausibles que possible, utilise des serveurs différents et des droits d'accès différents. (Par exemple sur Gandi ou AWS: des comptes différents).
Tes environnements sont séparés, donc cela n'a pas le droit d'arriver. Maintenant, tu peux vouloir utiliser un snapshot de la BDD en production dans les tests. Ta pipeline doit pouvoir initialiser la BDD avec un snapshot arbitraire. Ensuite il faut s'équiper pour éliminer plein de choses des snapshots: artefacts cryptographique et tokens d'authentification, données personnelles, données business. (C'est en principe plus facile de créer des données synthétiques que d'adapter les données de production pour les tests.)
En général deux (si tu travailles sans redondance), des snapshots si possible et des sauvegardes fichier.
Quand tu modifies, du point de vue de git (commit) cela se fait toujours sur la branche en cours. Tu n'as pas forcément besoin de travailler avec des branches, et surtout pas pour distinguer "test" et "prod": cela se fait via un fichier de configuration ou des variables d'environnement.
Pour démarrer, fait des petits pas, un environnement de laboratoire. Ton premier test est de faire un cURL qui marche sur ton site déployé. Bonne chance!