To paraphrase this rather long question:
Why would you need more than 2 build configurations for their project when used in conjunction with service configurations ?
I have a cloud service that contains multiple websites which needs to be deployed onto a number of different Azure platforms, one for Test, one for UAT, and one for Live.
Each environment needs a different host header defined for the website it deploys e.g. test.myportal.com, test.myservice.com, uat.myportal.com, uat.myservice.com, live.myportal.com and live.myservice.com.
This means I need to define a ServiceDefinition for each environment, fine so far.
In previous related questions I've seen (Azure: Is there any way to deploy different instance sizes for test/production, Azure connection string best practices (step 4, and using $(Configuration) instead of $(TargetProfile) in the .ccproj file), people have mentioned that you will need X configurations (meaning build configurations). This doesn't make sense to me, as I only need two build configurations (Debug and Release) for the way that the code is built, rather than how the service is configured. Rather, what I need are three service configurations.
My question is, am I right in thinking that a build configuration should only be used for how the code is built and that people who create multiple different build configurations for service configuration are wrong? (That's not the best word to use, I admit)
To further explain how I'm implementing a solution around this, I continue below:
I'm configuring my CI build server for MSBuild to take an additional parameter, TargetProfile, alongside Configuration.
The MSBuild commands for my environments look like this:
For Test:
msbuild mySolution.sln /p:TargetProfile=Test /p:Configuration=Debug
For UAT
msbuild mySolution.sln /p:TargetProfile=UAT /p:Configuration=Debug
For Live
msbuild mySolution.sln /p:TargetProfile=Live /p:Configuration=Release
For my cloud service, I use three ServiceDefinition.csdef files, one for each environment: ServiceDefinition.Test.csdef ServiceDefinition.UAT.csdef ServiceDefinition.Live.csdef. These are kept in a '/config/' folder.
In my cloud server ccproj file I only have two Configurations, Debug and Release, with a task in BeforeBuild :
<Target Name="BeforeBuild">
<Copy SourceFiles="configs\ServiceDefinition.$(TargetProfile).csdef" DestinationFolder="$(OutputPath)" />
<Move SourceFiles="$(OutputPath)ServiceDefinition.$(TargetProfile).csdef" DestinationFiles="$(OutputPath)ServiceDefinition.csdef" />
</Target>
This then ensures that I only ever need two build configurations, but can have as many service configurations as I like, just by changing the TargetProfile parameter that I pass into MSBuild.
To reprise my question:
Am I right in thinking that a build configuration should only be used for how the code is built, and that people who create multiple different build configurations for service configuration are wrong ?
