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'm a developer and I have had several experiences in web application deployment which are the following:

  1. Deploy all files then apply configuration values as appropriate to the environment. We've used this style of deployment for larger softwares with long development cycles and quick releases aren't needed or allowed unless for emergencies.
  2. Deploy only what has changed; manually update configuration files with what new or updated configuration as appropriate to environment. We've used this style for web applications that tend to be more agile, i.e. fix and feature releases are almost done daily. I've had issues with this before where not all assemblies dependent on an assembly that has changed were identified (A constant value was change in assembly A and the same constant was used in assembly B and only assembly A identified as changed).

Which of the 2 is a better (or best) practice? I'm starting a new medium sized project where deployments would be on a monthly basis and would like to establish this process early on.

share|improve this question

3 Answers 3

I like deploying everything. To me it ensures that both the deployment and configuration are completely repeatable, and if you use this process for populating your DEV and QA environments, you're testing it on a very regular basis.

As you've seen, if you only deploy what has changed, or what your deployment process thinks has changed, there is a risk of code updates and configuration adjustments falling out of sync. That could make it hard to reproduce the exact process environment if you needed to. (think failed backups, crashed servers, or just debugging difficult problems)

Your mileage may vary, but I've been using some form of method #1 for a long time with good success.

share|improve this answer
2  
+1 for method #1. Moreover you should think about having a branching strategy in order to be able to create a new branch from the Production one, dedicated to hot fixes (as it seems to be one of your concerns). And as soon as this HF branch has been deployed, you could just merge its content back to the trunk. –  MaxS - Betclic Jul 4 '13 at 9:30
    
Yeah, having a production/release branch should be considered a requirement. That has saved me on a few occasions. –  mpeterson Jul 5 '13 at 16:03

Deploying everything is fine when the codebase is small, but does not scale as it becomes larger.

You can gain control above and beyond your two points by using a deployment pipeline to push changes to your different environments. The pipeline is triggered by changes, so you retain traceability over changes, whilst deploying only when needed.

share|improve this answer
    
How large are we talking about? Apparently facebook deploy 1.5 gig of code every day, in 15 minutes to all of their servers using bittorrent. –  LachlanB Oct 17 '13 at 1:16
    
Facebook's case is a bit unusual. They deploy a single 1.5GB binary, which is not normal practice (but works for them). When you have more separate sub-systems than dev teams, you'll want to use deployment pipelines. –  Matthew Skelton Oct 17 '13 at 17:05

I deploy everything. It's a lot safer, doesn't cost you much and saves a lot of headaches. When you're debugging issues on a test server the last thing you want to be thinking about is "hang on is this code in DLL #3 up to date".

If you're in .NET land, I have had issues where deploying a .NET DLL (the only one that had changed) that had a dependency on a third-party control just stopped working. Deploying the whole lot fixed everything.

share|improve this answer

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.