When executing a software application, there are always differences in configuration, depending on the environment. These configuration changes may include references to a database server, contact email addresses, or how exceptions are handled. I was recently doing some research on how Visual Studio 2010 handles this.
The question I would like to pose to folks is:
"What is your thoughts and/or model for building and deployment of the software bits? How do you use Visual Studio or other tools to build and deploy a "kit" to an environment?"
1 comment:
The way I handle configuration differences using Visual Studio is the following:
I don't use Visual Studio to handle configuration differences.
This problem shouldn't be solved in Visual Studio. It's not a developer's problem to solve, It's the build / deployment engineer's problem to solve.
Now, I'm just talking roles, not positions. It's likely that the role of build / deployment engineer is filled by a developer, which is what starts the confusion.
It's very helpful to keep clear responsibilities in mind
Responsibilities of Software Developer Role
Create system delta to meet requirements
Build / Deployment Engineer Role
Create and Maintain system to compile and propogate Developer's system delta to various environments
Anyway, now that we have our terms defined I think the everyone can agree that the general SDLC process should be something along the lines of the following:
* Disclaimer: Of course many of the roles can be filled other than the people listed, this is just my opinion on what is optimal
Lets see if I can create an ASCII sequence diagram that looks ok in a non-monospaced system
SD BE QA IT
Code Delta->Build Process->Deploy and
^ Testing
\ \
/ /
+--------------------------+
\ Release
/ Greenlight ->Deploy
\ To
+--------------------------Testing <- Stage
Release
Greenlight ->Deploy
To
Prod
Given the job of QA is delta validation, it would be optimal if the delta that propogates to an environment was confirmed to be exactly the same delta as was tested in the previous environment.
Luckily for the build engineer this is an easy requirement to meet. The secret is to have the necessary differences injected into your configuration at deployment time, instead of build time.
In this scenario of last minute injection, the same bits (build artifact) are ensured to be in every environment.
There are a few strategies to implement this.
One place I worked at just included the configuration for every environment in the build artifact in a structure such as
Configuration/{environment}/fileFullOf.config
This was used to overwrite the system configuration on a file by file basis
Another place, for each application, as part of the deployment system, kept a manifest of the things that changed per environment, along with the correct values for those things, and injected them into the configuration files
This was used to overwrite the system configuration on an entry by entry basis
I (slightly) prefer the second approach, due to another maxim of configuration management: Delta should only include the minimum needed to be functional.
The first approach breaks this because it includes configuration in the build artifact that may never get utilized.
The drawback of the second approach is when the Developers introducing configuration delta into the system do not have rights to the deployment system to make changes to mirror the changes in the system. From my experience this is a fairly common scenario.
All I can say about this scenario is that it doesn't make sense. The system that propogates delta into your environments is itself delta, and should go through the same process, and have the same rights / roles assigned as any other delta (Developers introduce delta, QA assures delta correctness, etc etc)
Anyway to sum up my (very opinionated) answer to Paul's question:
I don't and neither should you. Configuration differences should be handled during deployment
Post a Comment