Alex Berg

The Problematic Deployment Process for Internal Salesforce Development

The IT development release process for a business’ internal Salesforce org is still half-baked. It is a manual, error-prone, time-consuming, and inefficient process. Developers on other platforms have found ways to automate most of the process, which lowers the chance of mistakes, so why can’t the Salesforce development process use a similar model to be more streamlined?

I’d like to discuss this more ideal model and then identify some of its potential incompatibilities with Salesforce. Some ISVs, who make AppExchange products, seem to have figured out a pretty good release model for their apps on Salesforce, but development on a business’ internal Salesforce org seems to be a different beast. Even the official recommendations from Salesforce distinguishes between ISV development and IT development.

The basics of a more ideal release process

The model that has worked extremely well for traditional software development teams relies on a central SCM repo to always hold the latest stable code base. To follow this model, each dev would have their own development environment. The only way to push your code to production is by following a code promotion process, moving your code from the least stable environment, which is a developer’s personal environment, to gradually more-stable environments, such as Integration, QA, and Staging environments.

Develop in a personal environment until the feature is complete and stable.
a) From there, to deem the feature stable when integrated with other new features, the repo contents are pushed to an integration org.
b) To deem the feature as fulfilling acceptance criteria, the repo contents are then pushed to a QA org for testing.
c) Finally, to carry out the release, the repo contents are pushed to production.

This keeps things very simple, because the same deployment process is practiced in each step. Releasing to production is the same as deploying from the integration environment to the QA environment.

Ideal’s incompatibility with Salesforce

This is a more ideal solution, but it is not an at-hand solution for development of features for an internal Salesforce org. In my experience thus far, to ensure a ‘clean sandbox’ in which to develop for the next release, all sandboxes are refreshed from production after a completed release. This action, refreshing a sandbox, is performed in the UI, which bypasses the SCM, thereby breaking the always-complete, always-stable SCM model. If we wanted to follow the ideal model, all orgs should be updated by simply pushing the up-to-date SCM contents into them.

It is not possible, however, to have every change in the repo because not everything is available for export via the Metadata API. In fact, Salesforce itself recognizes this, and, in addition to using software diffing tools on a local machine, their best suggested solution is to manually track changes between orgs. Manually doing something like this is very error-prone, not to mention time-consuming, and should be avoided.

I’m still trying to work through why more people aren’t actively searching for a more ideal model. Salesforce should be pushed to make everything available via the Metadata API, otherwise provide a more streamlined release process. Here are some possible reasons:
1) Technically not feasible. Not all org changes are available through the meta-data API.
2) Developers’ limited skillset. Not all Salesforce developers work in code or know how to use SCM.
3) Blind to the problem. Some developers don’t mind staying busy with manually solving the same problem over and over.

I’ve brought to light the goal and the some of the road-blocks between here and there, so now I ask the reader: How do you manage your internal Salesforce development release process? Do you use the SCM model by deploying from a central repo to each org? Do you use a third-party application as a solution?

Posted in: Programming, Salesforce, Software Development