Salesforce powers thousands of businesses around the world, from small non-profits to global technology giants. Despite this diverse customer base, many businesses follow a similar evolution in their release management, motivated by the need to effectively manage the increasing complexity in both their teams and environments. 

This evolution falls into three broad categories: 

Initially, changes are made directly in the production environment. With no need for additional sandboxes, this can be a quick and efficient way of working after the initial implementation of Salesforce for businesses that don't have sufficient customization of their organization to require a development team, or where costs need to be kept to a minimum.

While simple, this is a risky approach. Changes are being made to the live organization being used by the business on a daily basis. Bugs and unfinished features can cause significant disruption, and it’s difficult to quickly identify and fix issues. Parallel development streams are very challenging, with developers or admins commonly overwriting each other’s changes or creating merge conflicts. There are also fundamental limitations in terms of the changes that can be made — new Apex classes can’t be created in a production environment, for example.

To avoid the issues with working in production, teams commonly start using a number of sandboxes to build and test code prior to release into production. This can vary from a single sandbox to a range of developer, partial, and full sandboxes with increasing complexity and data. 

Development in sandboxes provides many advantages over development in production. Developers and admins can begin to work in parallel development streams, reducing the chances of stepping on each other’s toes. Changes can be tested prior to release to production, reducing the risk of bugs and making it more likely that a feature will meet the business needs of the end user. Apex code can be written and tested before being migrated to production, allowing for a much greater degree of customization of the environments. The segregation of different environments also allows for more refined change control.

As a result of these benefits, many teams quickly move to the sandbox development model, adapting the process as the team size and environment complexity grows.

Sandbox development does not solve all the issues of a production-focused approach, however. Code conflicts and accidentally overwriting changes remain a pain point, and there is limited audit capability to track why and when changes were made and by whom. 

It also introduces several new challenges that teams must contend with. With parallel development streams across multiple environments, it’s common for sandboxes to fall out of sync. This limits the effectiveness of testing and can increase the risk of duplicated work. Identifying which features are ready for testing, and which components should be included in each release often becomes a manual, spreadsheet-based task. In the event of a rollback, it can be difficult to know exactly what the most recent stable state was.

The biggest challenge for many, however, is simply migrating the metadata effectively between the multiple environments. The complexity of Salesforce metadata, combined with the steep learning curve of the command-line-based deployment tools can become a serious time drain on the release team.

The benefits of sandbox development and the ease of adoption mean that most teams have moved onto this approach. Despite its advantages, its inherent challenges limit how far teams can go on their path to agile development. Over time, the lack of automation, limited change tracking, interfering development streams, and complex environment management drive many teams to look for a better solution. 

For many, version control is at the heart of such a process, and sets them on the path to modern DevOps.