The evolution of Salesforce Change Management has been quite remarkable. Initially designed as a platform focused on sales activities Salesforce has undergone changes since its creation, in 2000. Over the years it has transformed into a development platform leading to the emergence of DevOps practices within the Salesforce ecosystem. In this chapter we will take a look at the journey of tools and methodologies that have played a pivotal role in shaping change management on the Salesforce platform.

The Early Stages of Customizing Salesforce

In 2003 Salesforce took a step towards becoming a development platform with the introduction of sforce 2.0. This release represented a shift from its identity as just a sales CRM system. The notable feature introduced was the ability to create custom objects to database tables.

S-Controls: Early Programmatic Customization

Accompanying the introduction of custom objects was the inception of S-Controls, initially known as sforce controls. These were one of the two programmatic elements of the new customization capabilities. S-Controls provided a container for combining functionality and user interface elements, supporting various items such as Java applets, ActiveX controls, and web forms. Although deprecated over time, S-Controls played a crucial role as the first method for developers to customize the platform programmatically, allowing them to leverage HTML and JavaScript for creating custom pages and user-interface components.

SOQL: Querying Data Programmatically

Another significant addition to sforce 2.0 was the introduction of Sforce Object Query Language (SOQL). This language provided a powerful means of querying data from both standard and custom objects using a syntax reminiscent of the industry-standard SQL. SOQL empowered developers to programmatically query data within their Salesforce organization, facilitating actions based on the results of these queries. From an architectural perspective, SOQL aligned with the imperative to maintain high data quality, ensuring that data-driven business decisions could be made effectively.

Sforce Web Services: Enabling Integration

Sforce 2.0 also introduced Sforce web services, a fundamental capability allowing integration between Salesforce and other platforms. This integration was made possible by exposing the object model and business logic through web service APIs. Leveraging SOAP and WSDL standards at the time, developers could now interact with their Salesforce organization from more traditional development environments and systems over a network.

Workflows: Automation of Business Processes

The last major element introduced with sforce 2.0 was a business process automation engine called workflows. By defining workflow rules responsive to changes in data, business logic could be triggered for escalations, notifications, and automatic updates to data. Workflows represented a config-driven means of delivering functionality, emphasizing the importance of a low-code solution in the evolving landscape.

Apex, Visualforce, and Workflow Automation

Fast forward to the 2006 edition of Dreamforce, Salesforce’s flagship conference, where co-founder Parker Harris unveiled the most significant change to the platform to date. Customers were now empowered to develop custom solutions using Salesforce’s proprietary programming language—Apex.

Apex: Proprietary Programming Language

Apex, a variant of the popular Java programming language, marked a significant milestone, enabling automation through code beyond triggers. Initially limited to triggers, Apex later evolved to incorporate more of the object-oriented paradigm with the introduction of Apex classes. This allowed developers to build structured, decoupled implementations, surpassing the capabilities of triggers alone.

Visualforce: Revolutionizing User Interfaces

Introduced in 2008, Visualforce was another major innovation that transformed the platform. Drawing inspiration from contemporary UI languages like ASP or PHP, Visualforce seamlessly blended HTML with programmatic elements and markup. This approach provided developers with a standardized way to create custom user interfaces and pages within their Salesforce implementation.

Sandboxes, Change Sets, and Maturing DevOps Practices

As Salesforce continued to mature as a development platform, the need for safely making changes outside of the production environment became apparent. This led to the introduction of sandboxes in the winter 2006 release, providing environments for trying out changes and enhancements in a safe, isolated space. However, the original implementation of sandboxes had a limitation—they did not allow changes made in sandboxes to be moved back to production.

Change Sets: Enabling Change Deployment

Recognizing the need for a more comprehensive solution, change sets were introduced in beta for the winter 2010 release and became generally available in the Spring 2011 release. Change sets represented a significant step forward, allowing code and configuration changes made in sandbox environments to be packaged and moved between environments. This introduced a new level of flexibility, enabling the planning of Salesforce environments as part of a mature application development life cycle, including development, QA, UAT, and staging environments ahead of production go-live. This marked the initial significant step toward achieving a DevOps process aligned with other development platforms.

Metadata and Tooling APIs: Enhancing Development and Deployment

To further enhance the platform’s tooling for development and deployment, Salesforce introduced two critical APIs—the Metadata API in the Spring 2008 release and the Tooling API in the Spring 2013 release.

Metadata API: Moving Metadata Between Environments

Metadata API allowed the movement of metadata, encompassing configuration and customization elements, between Salesforce environments. Developers could retrieve metadata as XML files from one Salesforce organization and deploy it into another. This capability, similar to change sets, facilitated operations between sandboxes, production, and later, scratch orgs.

Tooling API: Aligning with DevOps Practices

While Metadata API focused on managing metadata, Tooling API was introduced to provide additional capabilities aligned with DevOps practices. These capabilities included smaller and more focused metadata retrieval and deployment, the ability to run unit tests, view test results, assess code coverage, and support additional code debugging capabilities. Tooling API became a valuable tool in managing unit test cycles, crucial for ensuring the quality of code.

The Force.com IDE and Mavensmate: Enhancing Development Experience

With the introduction of new tools leveraging Metadata and Tooling APIs, developers were no longer restricted to developing within the Salesforce platform itself. Salesforce responded by exploring ways to deliver a standardized developer experience that aligned with industry standards.

The Force.com IDE: Eclipse-Based Development Environment

One of the early IDEs that leveraged Metadata and Tooling APIs was Salesforce’s own Force.com IDE. Built on top of the modular plugin architecture of the popular Eclipse development environment, which was predominantly used for Java, the Force.com IDE allowed developers to code with a proper editor and save changes directly from the IDE to their development organizations. While the Force.com IDE gained popularity quickly, it faced challenges related to speed and stability.

Mavensmate: Lightweight Alternative

To address the limitations of the Force.com IDE, Mavensmate was introduced in 2013 as a lightweight alternative. Following a similar plugin approach, Mavensmate extended an editor called Sublime Text (later adding support for Atom), offering a considerably more lightweight experience. Developers embraced Mavensmate for its speed, stability, and ease of use, not only for development but also for deploying changes using the Metadata and Tooling APIs.

SFDX and Source-Driven Development

Despite the stability in Salesforce change management for several years, a significant shift occurred with the release of Salesforce’s SFDX (Salesforce Developer Experience) toolchain in 2018. SFDX brought the promise of modern development and deployment practices, often seen in other platforms, delivered through a command-line interface (CLI).

SFDX CLI and Scratch Orgs: Introducing Source-Driven Development

The SFDX CLI, coupled with the introduction of scratch orgs, marked a departure from traditional organization-based development models to a source-driven development model. Scratch orgs, ephemeral development environments, could be easily created and torn down, supporting different configurations and populated with test data.

Enhanced Visual Studio Code Integration

Salesforce recognized the need for tight integration with development tools and provided extensions for the popular Visual Studio (VS) Code environment. This integration facilitated both development and deployment on the Salesforce platform directly from the IDE. This approach supports effective Salesforce Change Management, ensuring smoother transitions and adaptations within the Salesforce ecosystem.

Continuous Integration and Automation

SFDX continues to be the Salesforce-recommended approach for developers working with the platform. It integrates well into continuous integration and continuous deployment (CI/CD) pipelines, enabling automated and scripted deployments. This consolidation aims to provide a more efficient command-line toolset , streamlining the process of building robust DevOps pipelines.

DevOps Center: Salesforce’s Native DevOps Solution

Salesforce, acknowledging the platform’s outgrowth of change sets and the perceived developer-centric nature of SFDX, entered the DevOps space with the release of the DevOps Center in December 2022.

Key Features of DevOps Center

DevOps Center, although not as feature-rich as third-party solutions, introduces several key features that align with best practices in Salesforce DevOps:

Source Control as the Version of Truth

DevOps Center encourages a model in which source control serves as the version of truth for changes. This emphasizes the importance of source code in capturing and tracking modifications made to the Salesforce platform.

Isolated, Incremental Change through Work Items

The concept of isolated, incremental change through work items or user stories is promoted by the DevOps Center. This aligns with agile principles and is popular in the DevOps strategy of many other platforms and organizations. It supports the idea of making changes in small, manageable increments, minimizing the risk of disruptions.

Improved Visibility and Accountability

DevOps Center provides better visibility and accountability for change delivery within the Salesforce Change Management platform. This is crucial for maintaining transparency in the development and deployment process, allowing stakeholders to track changes and understand their impact.

Considerations for DevOps Architects

As architects, it’s important not to take DevOps tooling for granted. Having the ability to work with different approaches and solutions, regardless of age, is valuable when dealing with older Salesforce organizations. DevOps Center, while not a comprehensive DevOps solution, serves as a valuable tool for educating Salesforce users on the basics of DevOps and encouraging a shift away from change sets.

In conclusion, the evolution of Salesforce Change Management as a development platform has been marked by continuous innovation and adaptability. From the early days of customization to the introduction of advanced DevOps practices, Salesforce has transformed to meet the demands of modern software development.

In subsequent chapters, we will delve into modern Salesforce DevOps tooling, techniques, and processes that shape the contemporary landscape.

Do you like to read more educational content? Read our blogs at Cloudastra Technologies or contact us for business enquiry at Cloudastra Contact Us .

Blog Details

Evolution of Salesforce Change Management: A Quick look on Journey