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:
Version control driven development.
Initially, changes are made directly in the production environment. This can be a quick and efficient way of working after the initial implementation of Salesforce if the business doesn’t have sufficient customization of their organization to require a development team, or if costs need to be kept to a minimum, as there’s no need for additional sandboxes.
While simple, this is a risky approach. Changes are being made to the live organization that’s 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. 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 move to 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 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 customisation 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-centric 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.
It also introduces several new challenges which teams must contend with. With parallel development streams across multiple environments it’s common for sandboxes to become 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.
Version control driven development
The benefits of sandbox development and the ease of adoption means 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 begins them on the path to modern DevOps.