Second London Force.com Developer Meetup / Deploying

This week saw the second London Force.com Developer Meetup at the Skills Matter eXchange, with a three handed talk on Team Development Strategies on the Force.com Platform from Wes Nolte, Anup Jadhav and Laurent Delcambre.  This time the meetup was captured on video - you can view it at: http://skillsmatter.com/podcast/nosql/team-development-strategies. There were also prizes on offer for answering snap questions from the presenters - I managed to come away with a Ruby on Rails book and a Salesforce.com T-Shirt.


One of the more interesting topics of discussion for me was around deploying changes between sandbox and production.  Like many Force.com developers I suspect, all my early deployments were carried out using the Force.com IDE, highlighting the elements I wanted to deploy, right-clicking and going through the deploy to server wizard.  This gives a nice visual indicator of the changes that will be made on the target system:

However, there are a couple of downsides to this:

• If the deployment fails, you have to start over from scratch.  Not too bad if there's only a couple of files like my example deployment above, but a bit tedious once you get into double figures.
• The changes aren't repeatable.  If I want to deploy those same files to another org at a later date, that's only possible if no additional changes have been made.

For these reasons I tend to use change sets these days, although these only work between connected organizations (e.g. sandbox to production or between sandboxes associated with the same production org).

Change sets are persistent, so when working on a piece of development you can add the new/changed elements as they are created.  Once you are ready to deploy, you upload the change set to the target org which locks the elements in their current form.  This means that if you need to deploy to a separate org (a training sandbox for example), it doesn't matter when you do this, the change set will be in exactly the same state as when it was first uploaded.  I've found this aspect to be particularly useful when I have a large amount of changes to deploy to production - I can test out deploying to a pre-production sandbox and once I've ironed out the issues, I can simply "replay" the change set into production.

If the deployment of a change set fails, you can simply clone the change set, fix the problem and then upload it again.  An important point to note is that when you clone the change set, you get the latest version of each of the elements in the new change set.

Change sets aren't a silver bullet though - being limited to connected org means that you must be developing in a sandbox to use them.  If you are working in a Developer Edition, they won't be available.  They also tend to be slower than using the IDE - something that can become important when you have to wait 30 minutes for the latest attempt at the change set to be uploaded at 1am in the morning.  Less of a regular issue, but still an issue nonetheless, is that they tend to be fragile around Salesforce.com releases - sometimes the upload takes a couple of days to become available, while at other times it doesn't make its way to the target org at all.  I'd imagine this is down to the source and target orgs being at different versions (e.g. sandbox at Summer 11 but production at Spring 11).  Where possible, we always look to avoid major deployments to production in the run up to these upgrade windows.

The next meetup is planned for October/November time - I'm looking forward to it already.