Background:

3-5 developers supporting (and building new) internal applications for a non-software company. We use TFS although I don't think that matters much for my question.

I want to be able to develop a deployment pipeline and adopt continuous integration / deployment techniques.

Here's what our source tree looks like right now. We use a single TFS Team Project.

$/MAIN/src/
$/MAIN/src/ApplicationA/VSSOlution.sln
$/MAIN/src/ApplicationA/ApplicationAProject1.csproj
$/MAIN/src/ApplicationA/ApplicationAProject2.csproj
$/MAIN/src/ApplicationB/...
$/MAIN/src/ApplicationC
$/MAIN/src/SharedInfrastructureA
$/MAIN/src/SharedInfrastructureB

My Goal (a pretty typical promotion pipeline)

1. When a code change is made to a given application I want to be able to build that application and auto-deploy that change to a DEV server.

   • I may also need to build dependencies on Shared Infrastructure Components.
   • I often also have some database scripts or changes as well

2. If developer testing passes I want to have an manually triggered but automated deploy of that build on a STAGING server where end-users will review new functionality.

3. Once it's approved by end users I want to a manually triggered auto-deploy to production

Question:

How can I best adopt continuous deployment techniques in a multi-application environment? A lot of the advice I see is more single-application-specific, how is that best applied to multiple applications?

• For step 1, do I simply setup a separate Team Build for each application?

• What's the best approach to accomplishing steps 2 and 3 of promoting latest build to new environments?

• I've seen this work well with web apps but what about database changes