When deploying updates, do you deploy all or selected/changed assemblies?

Question

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.

Answer 1

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.

• MaxSC: +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.
• mpeterson: Yeah, having a production/release branch should be considered a requirement. That has saved me on a few occasions.

Answer 2

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.

• Rocklan: 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.
• Matthew Skelton: 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.

Answer 3

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.