Bonjour,
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.
J'ai cherché sur internet un tutoriel pour savoir comment mettre en place des environnements séparés de test et production mais je n'ai rien trouvé de probant…
Je sais utiliser git et faire du déploiement de code en distinguant des branches mais je m'interroge sur les aspects tres concret pour mettre en place les environnements :
-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?
-comment faire référence à la meme base de données dans django pour le test et la production? et si on fait des modifications sur l environnement test, dois je faire une copie de sauvegarde de la base de données pour mes tests?
-Dois je avoir 3 bdd ? (une test, une production et une de sauvegarde) ?
-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 ?
Merci beaucoup pour vos retours !
# Faire des petits pas
Posté par Michaël (site web personnel) . É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!
[^] # Re: Faire des petits pas
Posté par kr1p . Évalué à 1.
Ok merci beaucoup pour ce retour!
Alors si je comprend bien, ce que tu proposes est de créer mon propre serveur de cicd pour remplacer github pour le déploiement? jai vu dockerhub, est ce que ca pourrait faire l'affaire? car je suis pas sur d etre capable de configurer moi meme un serveur cicd…jenkins ou gocd font du deploiement de container cest ca?
Là je connais pas du tout…aurais tu un bon bouquin ou un site internet qui explique un peu les "choses" à éliminer des snapshots?
A la lecture de ta réponse, j'aurais instinctivement pensé que je mettrais mon code test dans un repertoire test (ou plusieurs selon les features testés) et mon code prod dans un repertoire prod et je copie les modifs de test dans prod puis deploiement quand je veux valider une modif (meme si ca peut etre dans un peu laborieux selon ce qui est testé). Et eventuellement d apres ce que j'ai lu un "staging" environnement pour avoir une copie de la prod testable.
Le fichier de configuration dont tu parles, est-ce le .yml qu'on utilise dans github actions par exemple qui décrit les étapes de make à faire pour déployer?
Par contre peux tu expliquer l'utilisation de variables d'environnement, je ne vois pas en quoi elles peuvent etre utile pour distinguer test et prod…
[^] # Re: Faire des petits pas
Posté par maroufle34 . Évalué à 2.
Le déploiement Git, sur du cloud ou non c'est pas le niveau 0 du sysadmin, à vrai dire ça sera pas toutes les situations du monde qui seront comme ça sur le terrain…
Bref cela dit tu as cocadmin sur YouTube qui explique exactement ces problématiques de déploiement de Git, du cloud, et des apports de celui ci, quand ça apporte vraiment un plus. Ce qui n'est pas toujours le cas.
Bien sûr souvent il se sert de Docker, ou Ansible + Docker, mais pas forcément non plus.
Docker c'est intéressant aussi pour déployer des environnements de travail identiques pour la prod et les tests (au moins pas de fichiers de config qui ne vont pas fonctionner une fois sur la machine de prod)
Même si à l'époque tout ça était assez superflu, c'est quand on change d'adminsys que ça peut devenir intéressant.(au moins le nouveau n'est pas perdu dans une infra trop complexe et pas standardisée avec les outils modernes.)
[^] # Re: Faire des petits pas
Posté par kr1p . Évalué à 1.
merci pour la ref!
# Commentaire supprimé
Posté par Anonyme . Évalué à 0. Dernière modification le 21 avril 2022 à 08:01.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.