Bonnes pratiques de mise en scène de bases de données
Je suis sur le point de déployer en production un site assez complexe et pour la première fois besoin d'un environnement de staging où je peux tester les choses dans un environnement plus réaliste, en particulier en ce qui concerne certains services externes qui ne peuvent pas être exécutés localement.
Mon plan général est de développer et de tester d'abord localement, de pousser des changements simples (petites corrections de bugs, HTML/CSS, JS, etc) directement vers la production, et pour les changements plus importants, poussez d'abord vers le sous-domaine de mise en scène pour des tests approfondis, puis vers production.
Je ne pense pas que j'ai besoin de synchroniser les bases de données de staging et de production (une mise à jour manuelle occasionnelle ferait l'affaire) mais je me demande s'il existe de bonnes pratiques générales en ce qui concerne la maintenance d'un environnement de staging par rapport à un environnement de production, en particulier en ce qui
Toute pensée générale / Conseil / expérience serait appréciée.
Mise à jour:
Merci pour les commentaires, je comprends l'essentiel. Je suppose que ça vaut prendre le temps de réfléchir à ce sujet. Accepté la réponse.
2 réponses
En contournant la mise en scène et en apportant des changements dans la production est une recette pour le désastre et la désuétude. Au fur et à mesure que vous effectuez ces modifications, La définition de mineur commence à changer. Deuxièmement, à mesure que les deux environnements partent (c'est-à-dire que la mise en scène ne correspond plus à la production), les choses se cassent et vous perdez confiance dans l'environnement de mise en scène. Pour tirer le meilleur parti d'un serveur intermédiaire, vous devez effectuer des déploiements automatisés, tester complètement et ensuite déployer (automatisé) en production (peu importe la taille du changement). Vous devez également vous assurer que l'environnement complet est aussi similaire que possible,et le rester. Cela inclut évidemment la DB. Je configure normalement une synchronisation quotidienne ou horaire (selon la fréquence à laquelle je construis le site ou l'application) pour maintenir la base de données, et je l'exécuterai souvent dans le cadre du processus de construction.
Comme quelqu'un développe un logiciel Outil qui aide à chaque étape du processus de déploiement, je peux dire que la meilleure pratique en matière d'environnements de mise en scène est de refléter votre environnement de production exactement. Cela inclut un schéma de base de données identique (les données ne sont pas pertinentes, la sauvegarde/actualisation occasionnelle est correcte), la même version du système d'exploitation, les service packs mis à jour, les paramètres du serveur web, etc.
Dans un monde idéal, tests fonctionnels ou d'acceptation par l'utilisateur n'a pas besoin d'être fait dans la mise en scène car le but d'un environnement de mise en scène est seulement de tester votre déploiement en production. Dans le monde pratique cependant, il est parfois acceptable que votre environnement de mise en scène soit également votre environnement de test fonctionnel ou UA.
Chaque fois que vous modifiez un paramètre ou une configuration sur votre serveur de production, vous devez modifier le paramètre sur le serveur de mise en scène, cela garantira que si vous pouvez déployer votre application pour probabilité, déployer à la production sans erreur.