Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I would like to propose a solution to our companies problem with building consistent installers for different environments. Our current process is to build an installer for test, perform testing, update app config, build installer for production.

Unfortunately this has lead to issues in the past where the installer was not properly updated etc. What can I suggest as a best practice to mitigate this problem?

share|improve this question
    
As a side question what are best practices surround SQL Authentication in app.config files? –  Sparksis Jan 29 '13 at 23:05
    
Are you trying to say with that comment that the thing that changes between test and release is the SQL authentication setting in the app.config file? –  Klee Jan 29 '13 at 23:49
    
@Sparksis: which installer technology are you going to use? Why do you have different installers for different environments, are you not deploying the same thing? –  Doc Brown Jan 30 '13 at 12:25
add comment

2 Answers

up vote 4 down vote accepted

Automate it

This is always the solution for "people are screwing up a continuous and repeatable process". Automate it.

Don't bother building a "test version" and testing it, AND THEN changing some config manually... AND THEN... building a "release" version (and waiting for it). Build both at the same time. It's the same as if you were doing a full debug/release build.

Take a look at the MSBuild Community Tasks and Jenkins CI.

Make your build system work for you. Modern build systems can do a fair bit very easily these days.

Test your release version

Seriously. What good is testing if you're not going to test what customers get? (this excludes automation that runs on instrumented builds, of course)

share|improve this answer
    
This would be my preferred solution but I've had trouble getting buy-in for this solution. –  Sparksis Jan 30 '13 at 22:34
    
@Sparksis you don't get buy-in. You just do it, and then show it to someone. If they don't want to go ahead with it after that... then you'll have some difficulties to work out. –  Steve Evers Jan 31 '13 at 21:15
add comment

You should definitely automate your building process. In order to configure the environments on each deployment you could put them on a separate XML configuration and in the build process use the 'AfterCompile' feature of the csproj.

There's a nice tutorial on building such a multiple environments automated build here:

http://zbra.com.br/2012/06/14/dynamic-environment-configuration/

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.