With the recent release of Salesforce DevOps Center Beta, the developer community has been eagerly awaiting what’s next. Based on how DevOps has evolved in Salesforce, we can make a reasonable prediction of what the future will look like for developers worldwide.
What Is Salesforce DevOps?
Patrick Debois coined the term “DevOps” in 2009 by combining “development” and “operations.” DevOps is a set of practices and philosophies that streamline the development cycle. It encourages close collaboration between the people who build applications—admins and developers—and the people who are in charge of releasing and monitoring them—admins, release managers, or team leads.
Following DevOps practices reduces the risk of forming data silos and facilitates more effective communication and collaboration, which can benefit organizations in the following ways:
- Faster release cycles.
- Increased application security.
- Fewer development errors.
- Shorter lead times for new features and changes.
- Improved code quality.
- Faster restore times after service outages.
Teams that adopt DevOps practices dramatically outperform those that rely on less efficient methodologies, which is why the evolution of DevOps in Salesforce is such a big deal. Ultimately, the more streamlined application development can be, the more competitive your organization can be.
The Evolution of Salesforce DevOps
Salesforce has come a long way since its inception as a CRM platform in 1999. Each iteration of the platform has increasingly incorporated DevOps tools to create a better developer experience.
Let’s take a look at how the platform transformed over the years to understand how it became what it is today.
2001: Salesforce Build Servers
The original HTML Salesforce UI was simple, with only one production instance and little room for development. The release of build servers in 2001 transformed Salesforce from a basic CRM to a development platform.
Also known as a continuous integration (CI) server, a build server provides developers with a dedicated environment for building their projects. The change allowed developers to configure their Salesforce instances to fit their organization’s unique needs, which made the platform so valuable there was little chance of switching to another.
In particular, the Cruise Control build server enabled early DevOps teams to schedule when they would run builds. This innovative build server inspired future CI systems such as Hudson/Jenkins. It also contributed to the development of continuous delivery (CD).
2006: Salesforce Sandboxes
In its early years, you had two options for developing in Salesforce:
- Work directly in production, which could lead to errors being released in your live instance.
- Maintain a Developer edition org that mirrored your production instance.
While these options worked, they weren’t optimal by any means. The 2006 release of Salesforce sandboxes provided developers with greater flexibility by creating a dedicated environment for experimentation. Now, developers can play with new configurations, code, and automation without risking damage to production.
However, transferring those changes from the sandbox to production was still an unnecessarily complicated process. Enter change sets.
2010: Salesforce Change Sets
Change sets allowed developers to transfer changes and metadata components between Salesforce environments. Although change sets became notorious for being frustrating to manage, their automatic documentation feature eliminated the need to manually transfer everything from a sandbox to production and vice versa. Here’s how:
- Outbound change sets: Created a record of all components moved out of the sandbox.
- Inbound change sets: Documented all components moved into production.
The platform also tracked who deployed these changes and when, which enabled organizations to streamline development audits and reduce human error.
While change systems were overall a good system for code delivery, the main shortcoming of change sets was the limited ability to track changes on a granular level. Without a single change management process, developers had to track changes using inefficient methods like Excel spreadsheets and project management systems like JIRA.
Additionally, change sets had limited support for Salesforce components, so teams had to manually update components such as profiles, permissions, and triggers. Some teams preferred updating these components manually, but it was still generally inefficient.
To address these limitations, Salesforce began incorporating more DevOps tools and functionalities.
2017: Salesforce DX and Continuous Delivery
In 2017, Salesforce released the beta version of Salesforce DX (SFDX), which stands for Developer Experience. Widely considered to be the beginning of a new era for developers and admins, the DX release more firmly incorporated DevOps into the Salesforce platform—DX’s goal was to support source-driven development rather than org-driven development.
This update also provided a new set of tools for improving the traditional developer experience on the platform, such as:
- Salesforce command-line interface (CLI): The introduction of CLI simplified build automation and development when working in a Salesforce org with features like tool aggregation, org synchronization, and org management, among others.
- Integrated development environment (IDE): IDE significantly increased developer productivity by consolidating the different elements of software writing, such as source code editing, debugging, and executable building.
- Scratch orgs: Because scratch orgs typically expire after a short period of time, automating certain tasks is often necessary for efficient CI/CD because it enables you to run all the necessary tests in a clean, repeatable, and realistic scratch org environment rather than in a special test org that only sees occasional use.
- New metadata formatting: The new metadata API made it easier to move code, which streamlined product development.
- Second-generation packaging: Second-gen managed packages (managed 2GP) created new, more efficient ways of developing, distributing, and managing apps and metadata.
However, even with these new features, there were still some areas that Salesforce needed to address. For example:
- How do you eliminate accidental overrides?
- How do you manage nested metadata structures such as triggers and profiles?
- How do you effectively manage long deployments?
The State of Salesforce DevOps 2022: Salesforce DevOps Center Beta
Salesforce DX opened the floodgates for the continuous growth of Salesforce DevOps. For example, Salesforce has been releasing a whole host of new CI/CD tools since 2020. These launches led to this year’s long-anticipated beta release — Salesforce DevOps Center.
The new product’s centralized, user-friendly interface allows developers to incorporate DevOps best practices into their development cycle. Additionally, it replaces the outdated change sets with tools like version control and visibility over your pipeline.
Some key features of the DevOps Center include:
- Automatic change tracking: This update effectively eliminates the need to track changes manually in Excel or other project management systems by automatically logging changes to metadata components.
- One-click change deployment: Once you have a clear vision of your deployment pipeline, this streamlined update enables you to deploy those changes in just a few clicks.
- GitHub integration: Seamless integration with GitHub enables developers to easily adopt source control, also called version control. This function allows you to automatically track and manage all code changes, providing a comprehensive running log of development progress that can help to resolve potential conflicts.
- Work Item management: This new feature is native to DevOps Center and enables teams to track and deploy related changes in various workflows.
Altogether, these features facilitate close collaboration and reduce the risk of bugs and errors making it to production, leading to higher-quality releases.
There’s still room for improvement, however. Some remaining weak areas include:
- Limited testing capabilities.
- Generally unclear CI/CD processes.
- Increased need to incorporate cybersecurity protocols.
- Updates for regulatory guidelines.
- Difficulty meeting the demand for high productivity and quality.
It’s also important for organizations to consider how they’ll bring all three layers of development—developers, operations, and security—together in a comprehensive, efficient process.
Moving Forward: DevSecOps
Several questions remain unanswered. Where exactly do developers, QA, release managers, and security fit into the DevOps workflow? The adoption of DevSecOps practices will provide effective answers to these questions.
DevSecOps brings data security into every step of the development pipeline, which is why it’s quickly become the industry standard for Salesforce development. The main benefits of implementing DevSecOps include:
- Increased data security: When you take a proactive approach to security, you benefit from more secure applications and updates.
- Reduced costs: Addressing security concerns early on reduces the number of vulnerabilities present in later stages, which saves the time and money you’d previously spend fixing these issues.
- Less duplicate work: With DevSecOps, your team can focus on one task at a time without having to repeat it later, which boosts productivity.
Rather than shifting your DevOps strategy left or right—the two main options in the DevOps debate—shifting to improved security can help you more easily remain compliant with key regulations and manage technical debt.
Here’s how DevSecOps can help. By providing continuous feedback at each stage of the process, developers can more effectively manage vulnerabilities that may otherwise have gone undetected. This ability can help in accomplishing the following goals:
- Ensuring developers deliver safe, clean code.
- Safely performing change management and code transportation between environments.
- Speeding up releases to improve business operations.
Implementing a DevSecOps platform can address some of these concerns by allowing teams to work off the Salesforce platform.
More Salesforce DevOps Trends to Watch
Given what developers are asking for, the information Salesforce has released, and the past history of DevOps in Salesforce, we can predict what may be coming down the pipeline over the coming months.
Generally speaking, these trends for Salesforce development have a common focus—tying up the platform’s loose ends to create a seamless, hassle-free developer experience.
1. Cloud-Native DevOps
As the cloud becomes critical for digital transformations, it’ll also become critical for more advanced DevOps in the future.
The five key principles of cloud-native DevOps include:
- Containerization: This cloud-centric technique for app development involves building within containers, which are lightweight code packages containing everything needed to run the necessary environment. Used correctly, containerization can speed the development cycle and make deployment more efficient.
- Microservices: A microservices architecture breaks an application into its individual components, known as microservices. This approach allows teams to maximize the benefits of cloud-native functionalities like containerization and CI/CD.
- CI/CD: Teams can utilize CI and CD to continuously test and improve cloud-native software more easily than they can with traditional methodologies.
- Immutable infrastructure: In a cloud-native environment, servers become immutable after deployment. This means you need to provision new, clean servers to make necessary updates and modifications.
- Orchestration: Automation will become increasingly important to DevOps workflows, making orchestration a critical component for running key operational tasks such as deployment, networking, and sustainable scaling.
All of the above principles enable teams to scale sustainably, improve development efficiency, and meet productivity goals—all important elements of a successful DevOps strategy. Plus, increased cloud adoption can further improve collaboration between development and operations teams.
It’s important to note that to deploy a cloud-native workflow, a cultural shift may be necessary for your DevOps team. Close collaboration is critical to eliminate data silos and prevent more from appearing in the future.
2. Shift Toward Agile DevOps
Moving forward, highly productive teams are likely to adopt the Agile methodology in development, which involves working in sprints that can last anywhere from a few weeks to a few months.
This methodology prioritizes fast development, frequent releases, and prompt response to feedback from users and other stakeholders. Cloud-native DevOps can integrate well into Agile teams due to Agile’s iterative development approach, which enables teams to incorporate feedback into the next iteration of their product.
DevOps metrics will be critical for adopting an Agile methodology because they provide a framework for measuring progress and making the necessary improvements. Salesforce DevOps Center’s new work item management feature will also be helpful, as it helps teams organize their work more effectively.
3. Heightened Compliance Requirements
Remaining compliant with the Sarbanes-Oxley Act, or SOX Act, is difficult enough as it is. Other organizational compliance obligations, such as HIPAA and GDPR, further complicate maintaining DevOps compliance.
As security threats evolve, cybersecurity compliance requirements are sure to tighten. Using these best practices can help DevOps teams meet changing compliance standards:
- Leverage containerization: Containing compliant applications or processes can make achieving compliance easier in future development projects by providing a guiding image.
- Create a system of record (SOR): Establishing an SOR allows your teams to ensure your product meets compliance standards before making changes to processes or codes.
- Incorporate DevSecOps into your pipeline: Proactively addressing security requirements throughout your development process provides a clear audit trail, saving time and money later on.
4. DevOps as a Service
The growth of cloud-native DevOps and the rising popularity of SaaS solutions such as Oracle NetSuite and Microsoft Dynamics 365 may lead to the emergence of DevOps as a service.
Cloud-native DevOps virtualizes your whole development process, which means you may need a cloud provider to host all your DevOps functions. The cloud consolidates all your tools into a single pipeline where the developers, operations team, and testers can closely collaborate.
Further, using SaaS-based DevOps tools may reduce costs for organizations by not requiring them to purchase more expensive tools upfront. It’s important to note these potential savings largely depend on how effectively the team can use the tools.
These Trends Indicate a Bright Future for Salesforce DevOps
Salesforce DevOps has a promising future ahead. As the platform continues to add integrations such as Slack, GitHub, and Customer 360, DevOps opportunities continue to expand.
More specifically, DevSecOps solutions are likely to become more widely used as time goes on. Using a DevSecOps platform like AutoRABIT allows you to work off the Salesforce platform, making your development process more flexible. Schedule a demo to learn more.
