Search code examples
.netsdlcagile-processes

Deployment planning for feature based development

A product is being developed and delivered as features rather than releases, meaning on completion of a feature, it's pushed to staging and then to production. There can be multiple features in development and overlapping the delivery timeline. So, at any point of time the dev database and source control has more than one feature in development. When a feature is completed, i would like to push only the feature specific code and db changes to staging. This process is proving to be error prone and time consuming for the reasons:

  • DB entities of a specific feature are not independant, but dependant and intertwined with other features. So, separating out the entities specific to the feature is time consuming and sometimes difficult to achieve. Is there any better way to do it?
  • On the server side code, similarly separating out the feature specific code is equally cumbersome as the db. With .NET Entity Framework layered on top of DB and other performance optimizations such as Pre-generated views in place, is there a better way to deploy feature based development?

The dev environment comprises of SQL Server 2008, .NET, Entity Framework with SVN for source control.

The term feature here is not related to FDD Agile Model.

Has anyone been through a similar experience?

Many thanks!

Solution

  • I manage a project that works very similar to what you've just described.

    Get SVN and CruiseControl.NET setup as soon as you can. It's a life/time savor

    I currently have my team working out of branches in SVN and merge into trunk then tag when ready for production.

    Keep your database under version control and associate verion numbers to tags (releases)

    I derivded my own DB versioning methods based from this great article that suggests creating some tables/constraints/triggers to help version control your DB.

    Versioning your database is the hardest part. Before we developed a strict routine for modifying the DB everything was a nightmare

    obviously there isn't enough space to explain the full details but I went from spending my entire days managing/merging code to now just checking in on the automated builds for peace of mind and have time to contribute to the project.