La planification du déploiement pour le développement à base de fonction

Question

Un produit est développé et livré comme caractéristiques plutôt que les rejets, ce qui signifie la fin d'une caractéristique, il est poussé à la mise en scène et à la production. Il peut y avoir plusieurs fonctions dans le développement et qui se chevauchent les délais de livraison. Ainsi, à tout moment le contrôle de la base de données de dev et la source a plus d'une fonction dans le développement. Lorsqu'une fonction est terminée, je voudrais pousser seulement la fonction de code spécifiques et db modifications à la mise en scène. Ce processus se révèle être sujette aux erreurs et de temps pour les raisons:

• entités DB d'une caractéristique spécifique ne sont pas indépendants, mais dépendants et étroitement liée à d'autres fonctions. Ainsi, séparer les entités spécifiques à la fonction prend beaucoup de temps et parfois difficile à réaliser. Y at-il une meilleure façon de le faire?
• Sur le code côté serveur, la séparation de la même caractéristique code spécifique est tout aussi lourd que le db. Avec Entity Framework .NET en couches sur le dessus de la DB et d'autres optimisations de performance telles que les vues prégénérés en place, est-il une meilleure façon de déployer le développement à base de fonction?

L'environnement de développement comprend de SQL Server 2008, .NET, Entity Framework avec SVN pour le contrôle source.

La fonction terme ici est pas lié au modèle FDD Agile.

Quelqu'un at-il été une expérience similaire?

Merci!

Answer 1

Je gère un projet qui fonctionne très semblable à ce que vous venez de décrire.

  

Obtenir SVN et la configuration CruiseControl.NET dès que vous le pouvez. Il est une vie / saveur de temps

     

J'ai actuellement mon équipe de travail de succursales dans SVN et se fondre dans le tronc puis marquer lorsque vous êtes prêt pour la production.

     

Gardez votre base de données sous contrôle de version et associés numéros de verion aux étiquettes (presse)

     

Je derivded mes propres méthodes DB versioning sur la base de cette grand article qui suggère la création des tables / contraintes / déclencheurs pour aider à contrôler la version de votre DB.

     

Versioning votre base de données est le plus difficile. Avant que nous avons développé une routine stricte pour modifier le tout DB était un cauchemar

de toute évidence il n'y a pas assez d'espace pour expliquer les détails, mais je suis allé de passer mes journées entières gestion / code fusion maintenant simplement vérifier dans le automatisé construit pour la tranquillité d'esprit et le temps de contribuer au projet.