Over the past two years, DevOps has become one of the hottest terms in the Salesforce ecosystem. When several team members and hundreds of users are involved in a Salesforce org, operations become complicated.
DevOps in Salesforce Timeline ⏳
Salesforce was founded in 1999. In comparison to what you are using now, you wouldn’t even recognize Salesforce when it was still in its infancy.
You may not even know that the term DevOps, itself, has only been around since 2009. At its inception, DevOps was defined as “a combination of cultural philosophies, practices, and tools designed to improve software quality and shorten the development lifecycle.”
A routine for ensuring that development reaches production without interfering with someone else’s development, or causing disastrous bugs when promoted.
The Evolution of DevOps in Salesforce 👨🏫
2001: Launch of Salesforce’s Build Server
2006: Salesforce Sandboxes Launched
2010: Salesforce Change Sets Launched
2017: Salesforce DX
2022: Salesforce DevOps Center arrives after a long anticipated wait
→ 2001: Salesforce’s Build Server
Salesforce’s founders knew empowering their customers would secure the cloud software’s favor. What’s the reason? It will become so valuable to them that they will not want to stop being Salesforce customers because a configurable system is tailored to their business operations.
There are several definitions of “Build Server” online if you’ve never heard of it before. This was the first version of Salesforce Setup in the Salesforce context.
→ 2006: Salesforce Sandboxes
Prior to 2006, admins and developers would make changes directly in production (or perhaps maintain a Developer org edition to mirror a production instance).
A Salesforce Sandbox environment allows you to test new configurations, code, and automation outside of production. A sandbox is a replica of your production instance that contains some or all of your metadata and data (depending on the type).
→ 2010: Salesforce Change Sets ⚒️
Development teams use change sets to move metadata components between environments, such as fields, automation, record types, etc. from a sandbox to production.
They were not only useful for reducing human error and reducing configuration duplicates, but also for documenting changes automatically. As a result, outbound change sets served as a record of what had been sent from sandboxes and what had come into production (or vice versa). For development audit trails, it was also important to know when and who deployed changes.
→ 2017: Salesforce DX ☕
Salesforce Developer Experience is a set of tools designed to improve the traditional developer’s experience of building on the platform, including the Salesforce CLI, a new IDE (replacing the Eclipse-based Force.com IDE), scratch orgs, second-generation packaging (2GP), a new metadata format, and the dependency API. All Salesforce developers benefit from Salesforce DX’s overarching goal of supporting source-driven development.
No-code developers and administrators were able to access DX workflows soon after Salesforce’s partners built DX functionality into their DevOps solutions. In order to make the lives of Salesforce developers easier, Salesforce created the metadata API.
→ 2022: Salesforce DevOps Center 👨🏼💻
The Salesforce Developer Experience includes a set of tools to enhance the developer’s experience of building on Salesforce, including the Salesforce CLI, a new IDE (which replaces the Eclipse-based Force.com IDE), scratch orgs, second-generation packaging (2GP), a new metadata format, and the dependency API. As part of Salesforce DX, all Salesforce developers benefit from source-driven development.
After Salesforce’s partners integrated DX functionality into their DevOps solutions, no-code developers and administrators were able to access DX workflows. Salesforce created the metadata API to make developers’ lives easier. The situation still needs to be improved, however. The reality of complex data management and continuous deployments that need to be defined, vetted, and tested. Currently, Salesforce DevOps Center faces the following challenges:
- Limited testing
- Unclear CI / CD process
- Lack of understanding associated with Metadata
- No deployment process
