How do I structure code and builds for continuous delivery of multiple applications in a small team?
- by kingdango
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)
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
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.
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
