Deployment Strategies

Over the years, after encountering both successful and painful Salesforce deployments, I’ve seen one approach that has worked well in managing environments and ensuring a successful deployment for the customer.

Here are some of my top tips for performing deployments.

1 Build Management Throughout the Project

Implementing and maintaining a simple change log, which captures all config and code changes can really help in knowing exactly what has changed in the system. A simple excel file shared on tools such as Google Drive can do this job, with columns such as the following can be used to maintain the change log:

Change Name	Components Changed	Component Type	Reason	Changed By	Change Owner	Deployed Date

When looking back at the file to understand the reasons of change later, it is much easier to step back and understand exactly why a particular change was done, and what components formed part of that change.

2 Knowing and deploying the Deltas

It is easy when creating changesets to simply deploy everything, however when we are working with an existing Salesforce instances, which may/may not be shared across many regions, this is a very dangerous and often disastrous approach. The changelog mentioned above is therefore vital in allowing the development team to understand exactly what has changed, so they can form the change package appropriately only including those changed components.

There are tools such as DiffMerge which combined with GitHub and Hudson can be used to automate some of this process. You could for example take a metadata extract from your development sandbox and compare this with the QA sandbox to see where the variances are and thus know exactly which components are different. This is an approach we can take when we have/need a structured build management process. I will post an article in the future detailing exactly how these tools can be setup and used with Salesforce.

3 Unit Tests with 80%+ coverage

It goes without saying in the Salesforce domain, test, test and please test. Writing test classes can often seem a painful task, thankless and time-consuming, however if we choose to see this from a different light we can begin to realise the genuine value there is in this activity. If the unit tests are based on expected business use cases, we can actually use these tests as part of a build management process to verify that a change in config/code in the system does not break expected functionality of the system. We could setup a job that executes tests say daily in the QA sandbox, monitoring test failures to measure the impact of updated code in the org. Test should cover both functional and technical aspects of the system, and business use cases should be kept in mind when creating unit tests. I have also found that writing unit tests as you go along is more fruitful than test driven development as there are sometimes dependencies in the implementation that do not allow one to adopt a test driven development approach. Writing as you go along ensures the task is not seen as being too painful, and developers are also more likely to consider all scenarios when validating their code via the unit tests. This encourages them to think strongly about expected user and system behavior.

4 Maintain a Master package.xml

One can maintain a master package.xml file that we can update as we go along. Each time we add a custom field, custom code, profile, custom component etc we can update this master file continuously, ensuring we have logged all the component we have changed. This is much more beneficial than attempting to do this 3-4 months into the build of a project when it is very difficult to remember exactly what our changes were.

5 Deployment Paths & Use of Sandboxes

Establish and maintain a set deployment path into the live system which incorporates the following Sandboxes:

The use of an intermediary Testing sandbox helps with the following:

• Allowing the business to only test code that is stable and ready for testing.
• Allows developers to develop and play in a sandbox without worrying needing to be frozen out because the business are testing.
• Allows the maintenance and management of a stable code-base and allow for activities such as running automated regression tests or running unit tests.
• Provides the business with a stable and more complete system where they can perform their testing, without running into ad-hoc code change issues.

Hope these tips above help you out on your Salesforce project. As mentioned in this blog, my writing has no affiliation to Salesforce.com, but is purely my personal thoughts on the subject matter, and I hope it can be of assistance to the wider Salesforce community. Deployments done right will lead to increased customer satisfaction and harmony and lead to a solid and sound technical migration of changes into a customer’s live system. By adopting some of the tips/methods above you can take steps to ensuring a positive go-live experience for your customers.