Quelles sont les meilleures pratiques pour la gestion des versions avec une application Web pilotée par les données et de nombreux développeurs?

Question

J'ai lu de nombreuses réponses à des questions similaires, mais je n'ai toujours pas trouvé la réponse que je recherchais.

Nous avons un groupe d'environ 12 développeurs et analystes métier travaillant sur une application. C'est une application énorme, je devine environ 1000 pages dans un mélange de ASP et ASP.NET.

Ce que je me demande, c'est comment les pros gèrent la gestion des versions d'une grande application comme celle-ci? Surtout comment gérer les déploiements, les changements de base de données et le contrôle des sources. Est-ce qu'ils construisent les procédures de contrôle de la source de telle sorte que l'application peut être ramenée à un point stable à tout moment? Comment la base de données s'intègre-t-elle à cela? Tous les changements de schéma de base de données et procs etc. sont-ils stockés dans le contrôle de source?

Je pense que ma solution idéale ici est de pouvoir réhydrater toute l'application de zéro à une version spécifique, y compris les données. Est-ce exagéré?

Mise à jour: ma première estimation de la taille de l'application était loin. J'ai fait un compte réel et est venu avec un plus grand nombre. 90% de ces pages sont gelés pour le développement ou inutilisés.

Answer 1

Alors que vous demandez certainement une question qui couvre beaucoup de terrain, il y a 3 grandes parties, vous devez avoir en place:

1. Utilisez un système de contrôle de version. Quelque chose comme Subversion ou GIT va automatiquement vous permettre de restaurer le code de votre application à un moment donné, ou à tout moment où vous avez "étiqueté" votre code source. Tant que tout le monde ne commet que du code qui se construit et s'exécute avec succès, chaque commit sera un point valide sur lequel vous pouvez retourner les changements. Votre système de contrôle de version gérera plusieurs lignes de code pour vous aussi bien avec des branches. Il ya many strategies pour gérer les branches, trouver celui qui fonctionne le mieux pour votre processus.

2. Utilisez un serveur de génération. Un serveur de build comme cruise control, Hudson ou TeamCity va assurer automatiquement que tous les commits est un « bon » commettras qui compile et peut fonctionner avec succès (en supposant que vous avez des tests en place)

3. donné votre schéma de base de données et base de données statique des données avec votre code dans le contrôle de version. Il existe des outils tels que LiquiBase qui vous permettent de gérer la structure de votre base de données et sont conçus pour fonctionner avec plusieurs développeurs travaillant simultanément, même dans plusieurs branches. Votre code n'est pas bon sans la structure de base de données correspondante, vous devez donc vous assurer de garder les deux synchronisés. Stocker les modifications de votre base de données dans votre référentiel de code source est le moyen le plus simple de le faire. Cela étant dit, vous ne pouvez pas stocker votre base de données complète dans votre référentiel. Il est trop grand et il change trop pour que le support de comparaison/fusion de votre contrôle source soit géré. Selon votre secteur d'activité, cela peut également ne pas être légal en raison de la réglementation gouvernementale. Si vous trouvez que vous devez restaurer votre base de données de production en raison d'une mauvaise version, vous devrez déterminer quelles instructions SQL annuleront le mieux les modifications appliquées en consultant vos scripts de mise à jour stockés.

Answer 2

Perforce a un excellent white paper pour résoudre certains des problèmes que vous soulevez. À partir de leur livre blanc, qui parle de pages Web, vous pouvez étendre le concept aux procédures stockées et aux scripts pour générer/modifier des tables. En ce qui concerne la possibilité de vous réhydrater entièrement, cela dépend vraiment de vos plans de reprise après sinistre, ainsi que de la façon dont vous configurez et configurez votre environnement de développement et de test d'intégration; et combien de temps d'arrêt vous êtes prêt à accepter. Je ne m'occupe pas de ces problèmes au jour le jour, alors peut-être que les gens qui ont beaucoup plus d'expérience dans le monde réel, surtout ceux qui travaillent dans le domaine des opérations, peuvent transmettre leur sagesse.

Answer 3

120 pages est "énorme"? Wow ...

La version d'une application comme celle-ci est assez simple. Vous disposez d'un processus de déploiement de la production qui consiste à étiqueter chaque version du système de contrôle des révisions avant sa sortie, et à installer uniquement des versions balisées. Vous sauvegardez la base de données au moment de la mise à niveau, avant de modifier le schéma, et le stockez quelque part avec un nom descriptif qui vous permet de lier le code et la sauvegarde de base de données. Si vous avez besoin de revenir en arrière, installez simplement l'ancien code et restaurez la sauvegarde. Si vous avez besoin de restaurer, mais avec les données actuelles, eh bien, c'est un problème plus difficile, et plus sur la structure de votre base de données et son évolution, mais les migrations Rails sont une étude intéressante sur la façon dont elle peut être terminé. Au-delà de cela, votre question est assez vaste et touche à beaucoup de domaines. Il vaudrait peut-être mieux contracter quelqu'un qui a déjà fait face à toutes ces choses et vous mettre sur la bonne voie.

Answer 4

C'est vraiment une application normale et de taille moyenne. Vous avez juste besoin de suivre de bons processus de contrôle de la source, d'utiliser des tests unitaires appropriés, une intégration continue, etc. Beaucoup d'organisations de développement ont résolu ce problème. En toute déférence, le fait que vous considérez que 120 pages soient énormes, et le fait que vous ayez l'impression que c'est un gros problème, m'indiquent que vous devriez envisager d'arrêter le développement dès maintenant et d'améliorer votre processus de développement. .

Je crains que si vous ne le faites pas maintenant, vous apprendrez plus tard pourquoi vous auriez dû le faire.

Answer 5

Pour quelque chose de si petit, plutôt que de vous inquiéter de pouvoir rouler dans le temps, ce que vous cherchez vraiment, c'est la possibilité de revenir à la version la plus récente. De cette façon, si vous cassez la construction, vous pouvez revenir à la version précédente. Comment?

1) Votre serveur web se lit de/www/travail 2) Poussez vos modifications dans/www/nouvelles 3) Déplacer/www/courant/www/vieux 4) Déplacer/www/nouvelle à/www/current

Si/www/courant explose, il suffit de déplacer/www/old à sa place.

Le seul problème est de supprimer le schéma de base de données qui n'en fait pas partie. L'annulation des modifications de schéma est difficile, voire impossible. Tout ce que vous pouvez vraiment faire est de restaurer l'ancienne version à partir de la sauvegarde et perdre toute activité entre la base de données en direct et ce qui était en sauvegarde. Cela a du sens si vous y réfléchissez - si vous ajoutez trois nouvelles tables et si vous refactorisez une autre table dans un meilleur schéma, comment pouvez-vous annuler le changement de schéma après cela? Vous ne pouvez pas - vous devez juste perdre toutes les nouvelles données. Moral? Prenez vos changements de base de données au sérieux - il y a une raison pour laquelle les AD sont parfois considérés comme des connards. Ils doivent être - ils ne peuvent pas simplement faire reculer les erreurs dans la base de données comme vous pouvez annuler votre code bogué.