Understanding history is important for us to go confidently into the future. With an understanding of how things were, and how/why they’ve changed over time, we’re better placed to take advantage of what the future could have in store.
DevOps has been one of the hottest terms in the Salesforce ecosystem over the past two years. Operations will get ‘messy’ when running a Salesforce org for hundreds of users, with multiple team members supporting the development.
We’ve come a long way – from change sets, to DevOps Center, to DevSecOps – these we can call the three phases of DevOps in Salesforce. So, what can we expect to see next? As we know, the Salesforce world moves fast, and innovators are consistently spotting areas where there’s room for improvement.
DevOps in Salesforce Timeline
Salesforce has been around since 1999. We guarantee you wouldn’t even notice Salesforce in its infancy compared to what you work with now.
In fact, 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 that aims to shorten the development life cycle and provide continuous delivery with high software quality”. In other words, routines that people can follow to ensure their development makes it to production, without interfering with another’s development, or causing disastrous bugs when promoted into production.
Here’s how DevOps has evolved in the context of Salesforce. We’ll then dive into each of these milestones.
- 2001: Salesforce’s build server launched
- 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
Despite being two years old, the founders of Salesforce knew that by empowering their customers to configure their Salesforce instances, would secure the cloud software favor. Why? Because a configurable system, therefore tailored to their business operations, becomes “sticky” — they will find it so valuable that they won’t want to stop being a Salesforce customer.
If you haven’t come across the term “build server”, you will find various definitions online. In a Salesforce context, this was the first iteration of Salesforce Setup.
At this point, you would have been an early adopter of Salesforce. You only had a single production instance, and any changes would be made directly in there. Stating the obvious, there was no change management, no version control, and no source control. Salesforce was a CRM and not a development platform.
Have you seen the oldest UI of Salesforce? This was built on simple HTML. Times were far more simple!
2006: Salesforce Sandboxes
You may think that sandboxes must have always been a part of Salesforce, as I assumed. Pre-2006, admins and developers were making changes straight into production (or perhaps maintaining a Developer edition org to mirror production instance).
A Salesforce Sandbox environment enables you to test new configuration, code, and automation outside of your production (live) instance – it’s like a replica of your production instance with some or all of your metadata and data (depending on the sandbox type).
2010: Salesforce Change Sets
Love them or loathe them, change sets allow development teams to move metadata components between environments – examples include fields, automations, record types, etc. between, say, your sandbox to production.
Could you even imagine that sandboxes existed without change sets for four years?
Not only did change sets eliminate the need to duplicate configuration work from sandboxes into production, and reduce human error, they were a rudimentary way to automatically document changes. In other words, outbound change sets became a record of which components had been sent from sandboxes, and inbound change sets recorded what had come into production (or vice versa). When and who deployed changes was also important for the development audit trail.
At this point, we have a good system of code delivery, but we did not have a controlled change management practice – you would still have managed these processes in Excel sheets or a system like JIRA. The challenge was that you could not bring everything into one place. This is when Salesforce moved towards a DevOps approach.
2017: Salesforce DX
Salesforce Developer Experience (SFDX or just DX) 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.
Personally, I remember this moment in Salesforce’s history. It was the start of a new era for developers and admins, after Salesforce had unfortunately been voted the least liked platform for developers to work with.
“Before we had source control, I remember my colleagues were exporting code and storing it in their local file systems, Google Drives, and so on. We attempted to use the metadata API to see how we can move code – the start of DevOps principles – to ensure that you have sufficient collaboration between developers.”
– Prashanth Samudrala, Product Manager, AutoRABIT.
During this phase of development, automation is required – the essential tools that have been popular since, such as Jenkins, Circle CI, GitHub.
Salesforce’s overarching aim for DX was to support source-driven development, and this benefits everyone building on Salesforce. Basically, moving to a package-based development where you can add incrementally to packages.
It didn’t take long for Salesforce’s partners to build DX functionality into their DevOps solutions, making DX workflows accessible to no-code developers and admins. The metadata API was a gift from Salesforce to build products that would make the lives of everyday Salesforce developers easier.
Despite the multiple tooling that Salesforce provided, gaps remained. How do you eliminate accidental overrides? Do multi-hour or multi-day deployments? Manage the nested metadata structures that Salesforce has (e.g. profiles and triggers)?
Enter Salesforce DevOps.
2022: Salesforce DevOps Center
Salesforce DevOps Center arrives after a long-anticipated wait. Why? For one, the Salesforce DevOps Center is such an enormous improvement on old workflows using change sets. Secondly, change sets have become outdated and cumbersome, the bugbear of many Salesforce professionals.
Superseding change sets, the Salesforce DevOps Center offers version control and visibility over your release pipeline, which ultimately leads to better quality releases with fewer bugs and errors, and seamless collaboration.
On the other hand, there’s still room for improvement. Acknowledging that we operate in a reality of complex data management, and continuous deployments that need to be defined, vetted, and tested. Right now, with Salesforce DevOps Center, we’re facing:
- Limited testing
- Unclear CI / CD process
- Lack of understanding associated with Metadata
- No deployment process
Taking Stock of Ongoing Challenges
There are other DevOps challenges that aren’t necessarily related to specific tools, including the fact that:
- New tools are introduced every year, making it challenging to keep up with how these additional technologies are woven into DevOps processes.
- Increased data security threats require necessary, and fast, action when they arise.
- Updated regulatory guidelines that must be addressed.
- The demand for heightened productivity, security, and quality never cease.
There’s an issue with the infinity loop that we often see – it’s a 2-dimensional, generalistic approach to how DevOps should function. However, it doesn’t show the feedback loop – in other words, where does the developer/release manager/QA get involved? It doesn’t represent the reality – the complexities of day-to-day operations – instead, it represents operations in a linear form. When bringing a process into play, the diagram does not actually represent who does what, and where.
It became difficult for organizations to get all three layers working together: the developer, operations, and security layer.
Where Next? Enter DevSecOps
With the traditional infinite loop not reflecting reality, an additional layer has been woven into operations: security.
DevSecOps aims to solve the aforementioned challenges – to bring security into the operations model, and therefore, mitigate security risks, all while keeping your CI/CD pipeline moving along without delays. Making the everyday life of a developer easier.
This ensures that developers and operations are collaborating, and that as your organization grows, security becomes a key aspect – after all, security does not start in production, but at the developers’ workstation.
An example of a software security risk is a profile change at the IDE-level (“modify all” changes from false to true), it’s pushed, and nobody catches that. That’s likely going to lead to a huge problem – even a situation that the organization can’t come back from fast.
Shifting “In” to Security
Technical debt compounds as you go. “Shift left” brings security in right at the developer-level, using the right tools (data code analysis tools, composition analysis tools) to ensure that you’re capturing all dependencies.
The “shift right” approach is more focused on operations (stress testing, performance testing) ensuring the code that you’re putting into your Salesforce behaves as expected and does not create a bad experience for your business users.
“Shift left” and “shift right” have been popularized for some time. What AutoRABIT believes is that organizations need to shift into security – in other words, not shifting left or shifting right but shifting in. You need to have continuous feedback from the QA to the developer, from the integrations to the developer, from the operations to the developer. All these feedbacks will ensure that you’re shifting into security.
DevSecOps Example
- You need to ensure that developers are delivering clean and safe code. So, you need to have tools to track common weaknesses, enumerations, or understanding the required governance rules in place. You’re not only moving code, but you’re also securing code, so if something detrimental happens, you have the right mechanisms to pull you back from disaster.
- You need a secure way of performing change management and code transportation from the developer’s IDE, to version control, and back to the sandbox. Multiple elements are in play, all acting together for an improved flow.
- There is a continuous feedback loop that is generated with each action that developers do. In terms of having better business operations, most professionals want faster releases. If you want faster releases, you need to have continuous learning. Faster releases are not a result of cutting down metadata, or having a faster pipeline into your production. This feedback mechanism connects the dots (peoples, stages), and that’s how you can bring faster releases.
Salesforce Cybersecurity Risk Budget?
How much should a CSO budget for Salesforce cybersecurity risk? This is a very big question. Even in the past year, we have witnessed many software vulnerabilities, such as the Log4j2 security flaw, or the Heroku attack, and often we do not know the intensity, or the extensiveness, of these attacks.
You should really be asking these questions to ensure that you are able to meet your day-to-day business needs – and we believe that this starts at the developer level all the way through. There is no way that you can control all of this in your production instance.
Taking Responsibility for Security
It’s commonly thought that Salesforce takes care of security. They don’t promise to take care of all aspects of security – in fact, most aspects are your organization’s responsibility.
Salesforce manages security at the data center level, i.e. your data won’t be compromised by data center hacks.
With the shared responsibility model, your organization is responsible for your data and the configurations that you make within Salesforce.
Anyone whose Salesforce specialized knows how complex the object structure is – the master-detail relationships, look-up relationships – the responsibility of controlling this software supply chain risk is with you, the customer. Most organizations do not have dedicated teams to ensure that security does not come as an afterthought.
The ISV ecosystem has been working with Salesforce to bridge gaps. Tools developed by partners bring a streamlined process so that you can, ultimately, deliver clean, safe code.
Summary
This guide has taken you through the evolution of DevOps with Salesforce – from humble beginnings, to innovation that’s now accelerating at a faster rate, with a lot of interest and activity around DevSecOps. Hopefully, by this point, you understand why development approaches keep changing!
For those who are thinking about faster releases, the first and foremost my advice is to start at the developer level to automate and secure your software supply chain as much as possible. Have the right checks and balances in place to make sure your production is not affected.
There are tools such as Salesforce DX or Salesforce DevOps Center, but it should be your responsibility to protect your production instance as we move into the future, as cyber security is critical (we’ll be witnessing more attack patterns and ways users’ data is exploited).