Quelles sont les meilleures pratiques à utiliser pour passer une application Web du développement à la production?

Question

Notre environnement de développement comporte de nombreuses couches et est compliqué à répliquer ou à sauvegarder efficacement. Fondamentalement, le système de fichiers (par exemple/usr/appdir/webapp ...) a d'autres applications servant notre application Web, ces applications que nous mettons à jour en effectuant des mises à jour svn à partir de leur dépôt.

L'utilisation de l'application Web elle-même (en tant qu'utilisateur) affectera à la fois le système de fichiers et la base de données. La sauvegarde du système consiste donc à avoir une copie du système de fichiers et de la base de données (mysqldump) au même moment. L'un des deux en soi ne sera pas une sauvegarde complète, car l'application est très dynamique elle-même. Lorsque nous déployons une application Web à la mise en scène pour l'un de nos clients afin de tester et d'entrer des données, nous avons un environnement difficile à synchroniser depuis notre environnement de développement, ou même à mettre en production. Puisque nous allons faire une demande de changement du client en développement, mais le client lui-même fera des changements dans la mise en scène.

En ce moment, nous utilisons des périodes de congélation, où nous demandons à nos clients d'apporter des changements aux environnements de développement ou même directement à la production (avant d'aller complètement vivre). Je me demande s'il s'agit d'une bonne pratique sur la façon d'avoir un processus efficace pour passer de dev -> staging -> production? Ou si vous avez des pointeurs.

Answer 1

En raison de cela, votre problème est compliqué par la nature de votre application.

Premièrement, votre application fait-elle une distinction entre les fichiers qui font partie de l'application et les fichiers qui ne sont que de simples données? Sinon, sauf si vous avez une raison très convaincante de ne pas le faire, un changement de cette nature devrait simplifier considérablement le contrôle de version de votre système de fichiers - alors il serait logique d'avoir les parties de l'application sous contrôle de version, mais pas les parties de données. Deuxièmement, j'ai toujours trouvé que la conservation des données du système de fichiers en synchronisation avec les données de la base de données était pénible. Une solution (qui peut être un refactoring plus complet) est de rendre l'un générateur de l'autre. Pourriez-vous en quelque sorte stocker le contenu du système de fichiers dans votre base de données liée aux données pertinentes, qui pourrait peupler le système de fichiers à partir d'un script? Si vos fichiers sont trop volumineux, dans de nombreux cas, il suffira d'avoir des fichiers représentatifs à des fins de développement et de test. Vous pouvez également disposer d'un référentiel distinct pour les données, qui peut prendre une image valide d'un ensemble de données (base de données et système de fichiers) pouvant être stockées et gérées séparément dans votre code d'application (bien que cette approche apporte d'autres informations). problèmes ...)

Si les problèmes de conception ici sont immuables, je ne peux pas penser à une meilleure idée que vos périodes de congélation.

Answer 2

Je n'apporte généralement aucun changement dans l'environnement de QA/transit. Toute modification est effectuée dans l'environnement de développement, puis transmise à la fois au contrôle qualité et à la production. Normalement, je n'utilise pas de données en direct dans QA/staging si je peux l'éviter. Dans les cas où j'ai des données en direct dans QA/staging, j'utiliserai quelque chose comme SQL Data Compare (de Red Gate) pour gérer la migration des nouvelles données de l'environnement QA/staging vers la production.

De plus, je maintiens des configurations distinctes pour les dev/QA/production dans le contrôle de code source. C'est un peu pénible de devoir se rappeler de faire des changements dans toutes les configs quand le changement les affecte tous, mais il y a assez de différences pour qu'il soit plus facile de faire ça que de mettre à jour la config pour QA/production. installée.