Why Salesforce?

Over the past 20 years, Salesforce has become the fastest growing enterprise software platform and a market leader in Sales, Service, Marketing, Integration, and custom application development among other areas.¹ Although there are many reasons why a company might adopt or consider using Salesforce, the overriding value proposition is that Salesforce provides tons of capabilities out of the box, releases new capabilities at an ambitious pace, and allows for virtually endless customization and innovation. Unlike with traditional platforms, there’s no need to manage infrastructure for computing, data, network, or security and no need to invest in generic system administration that adds no value for the organization. Add to this the accessible and supportive community and learning culture based around Salesforce’s Trailhead, which enables rapid onboarding and skill development, and it’s easy to see the attraction of this platform.

Companies who adopt Salesforce do so because they don’t want to manage servers, networking infrastructure, security, and the countless other aspects of application development that don’t directly bring business value. When an enterprise company takes an interest in automating a new part of their workflow or storing data, they have no interest in provisioning servers or containers, let alone implementing ongoing monitoring, data backup, failover redundancy, and so forth. What they’re interested in is business value. And what Salesforce delivers is the opportunity to create and deploy business value with the minimum necessary overhead. In exchange for a relatively modest subscription price, Salesforce takes care of almost every aspect of the infrastructure needed to run an application. At the same time, they have continued to expand and innovate to make the process of developing functionality easier across a broadening range of applications.

Salesforce began in 1998 with the aspirational goal to create a SaaS customer relationship management (CRM) system that was “as simple as Amazon.”² Since then, they’ve become the fastest growing enterprise software company ever to reach $10 billion. And they lead the market for CRM, service automation, marketing automation, and integration. They’ve been recognized year after year by Forbes as the world’s most innovative company and won their Innovator of the Decade award. Fortune magazine also ranked them the #1 best place to work.³

Salesforce’s mantra throughout the 2000s was “Clicks not Code,” and their logo was the “No Software” image which became embodied as SaaSy, Salesforce’s first mascot. You could be a “declarative” developer using “clicks” alone and build a data model, business process automation, and user interface using drag-and-drop interfaces. This opened the door to an entire new job specialization—Salesforce Admins and “App Builders,” citizen developers who were empowered to directly customize the platform to meet their company’s needs.

As Salesforce grew, they recognized the need to enable custom coding on their platform and launched Apex triggers, followed by Apex classes, and Visualforce in 2008. Admins continued to configure rich business capabilities, while low-code developers and professional developers were empowered to create customizations beyond the scope of what could be built declaratively. Initially, the code developed on Salesforce was rudimentary: a few hundred lines here and there to accommodate unusual calculations and data processing. But gradually, companies began to accumulate tens of thousands of lines of custom code, especially as legacy applications were migrated from other systems. Needless to say, the “No Software” motto no longer strictly applies.

In the decade since the launch of Apex, 150,000 companies have adopted Salesforce and moved a staggering number of legacy systems onto Salesforce. Salesforce now processes billions of transactions per day. Many of these transactions are part of the core CRM and customer service applications, but a huge number relate to custom applications, making Salesforce one of the largest Platform as a Service (PaaS) providers.

What Is Salesforce DX?

Salesforce’s ease of customization has led to an unusual challenge. Whereas developers in most languages have been employing methods such as continuous delivery for a decade or two, most Salesforce customers have been slow to adopt such methods. There are two reasons for this: the Salesforce platform itself and the developers managing it.

First of all, the Salesforce platform behaves very differently from a standard server or custom application. You can’t build a local instance of Salesforce on a developer’s laptop, for example. Instead, Salesforce runs centrally “in the cloud,” and you deploy functionality by updating a specific Salesforce instance. There are limits to what types of changes can be deployed, and tracking changes has been challenging, meaning that developers often needed to log in to a target org and make customizations manually to complete a deployment.

The other reason the Salesforce world has been slow to adopt practices such as continuous delivery is that Salesforce development is a specialized skill requiring declarative/admin skills, with programmatic/coding skills being a nice-to-have addition in many cases. Because most Salesforce developers don’t do custom development on other platforms, this led to a lack of cross-pollination between ideas that were common in the Java, JavaScript, .NET, and Ruby worlds. Even when traditional developers were transplanted into a Salesforce project and reskilled to work on Apex or Lightning, they found that their customary build, test, and deploy tools were largely useless in the new Salesforce world. Instead they were provided with “change sets,” an Ant Migration Tool, and very few examples of how one might build a comprehensive CI/CD pipeline for this platform. The brave few ventured into configuring complex Ant “targets” using XML and triggering them using Jenkins. But by and large, teams cobbled together a mix of manual steps and light automation, tackling deployments one at a time, and as infrequently as they could get away with.

The challenge of managing Salesforce deployments was one factor that led Salesforce to earn a very dubious accolade. In the 2017 Stack Overflow international developer survey, Salesforce tied with SharePoint as the “most dreaded platform to develop on.”⁴ Ouch. Needless to say, that is not one of the accomplishments Salesforce is most proud of.

When companies were using Salesforce solely for sales force automation, it could be a “shadow IT” product managed by the Sales Operations teams. But as its capabilities and adoption expanded beyond CRM, Salesforce has moved to being a core part of companies’ IT infrastructure. An increasing number of CIOs and IT Directors recognized the centrality of Salesforce to their businesses and the growing complexity of their Salesforce implementations. Salesforce was increasingly fielding challenging questions in terms of how companies could adopt DevOps best practices, such as maintaining and deploying all configuration from source control.

These demands eventually led Salesforce to establish an internal tiger team known as “Salesforce DX,” dedicated to improving the Salesforce Developer eXperience. The team was assembled in 2016, with several seasoned groups working in parallel on improving different aspects of the developer experience. At Dreamforce 2017, Salesforce DX went live.⁵

Prior to Salesforce DX, the only way to develop on Salesforce was org-based development, where a Salesforce org itself is the source of truth. Even if teams managed to use version control and automated deployments to update their testing and production orgs, version control necessarily lagged behind the development org. This meant that changes to the development org were often never tracked in version control, and that it was entirely possible to make changes in the development org that were difficult or impossible to track and deploy systematically. Since the org was the source of truth, anyone wanting to see the latest, integrated version of a component had to check the org, since version control could always be lagging behind.

Org-based development meant that even the most sophisticated development teams were trapped in a conundrum: they could provide each developer with their own separate org, or they could have all developers work in a single org. Separate orgs meant it was easy for developers to isolate their changes from the work of others, but orgs quickly got out of sync. Sharing a single org provides continuous integration (developers’ work is always integrated in a single org), but it is extremely challenging to track and deploy one’s own changes in isolation from the rest of the team. Vendors such as Flosum and AutoRABIT offer sophisticated synchronization tools, but the whole system is fundamentally flawed.

The most notable innovation to launch with Salesforce DX is a new type of Salesforce org called a scratch org. For the first time, scratch orgs allow a Salesforce environment to be created entirely from version control. This means that for the first time, version control can be the source of truth, rather than always lagging behind the state of development orgs. Developers can create private development environments at will, and those environments can be quickly updated from version control as other members of the team integrate their own changes.

Salesforce DX thus finally allows for source-driven development. Source-driven development in turn opens the door to adopting most of the other technological and cultural processes known broadly as DevOps. And DevOps has been shown to be a massive contributor to innovation, effectiveness, and corporate success.

What Is DevOps?

This book represents a convergence of two major movements within the IT world: the movement to Software/Platform as a Service (SaaS/PaaS) and the DevOps movement. The goal of SaaS and PaaS is to provide a scalable, global, high-performing foundation for companies to invest in their core competencies rather than having to maintain their own infrastructure. In addition, centralized SaaS applications provide powerful capabilities without introducing software upgrades, version incompatibilities, and the other headaches associated with maintaining your own software.

Salesforce provides SaaS solutions for customer relationship management (CRM), sales force automation (SFA), customer service, and more, while also offering a PaaS platform for deploying custom code (Heroku and the Lightning Platform). Salesforce DX now provides the raw capabilities to enable a DevOps workflow on Salesforce. The goal of this book is to explain how you can build a powerful and comprehensive DevOps workflow for Salesforce. The power of this can’t be overstated: you can finally deploy the world’s most innovative platform using the world’s most effective and efficient techniques.

Within the literature and tooling providers for DevOps, there is a tremendous focus on enabling Infrastructure as a Service (IaaS) as an evolution away from managing your own servers. “DevOps solution providers” include a massive array of IaaS providers (such as AWS, Google Cloud, and Azure), as well as tools for managing software packages, database configurations, application monitoring, and so on. Almost every “DevOps tool” provider is addressing a need in the IaaS space so that organizations with legacy applications and infrastructure can begin to manage those in an efficient and orderly way.

It’s interesting to note that almost all of these “DevOps tools” are helping to solve problems that simply do not exist for Salesforce users. Simply moving to Salesforce solves most every problem with infrastructure, security, monitoring, databases, performance, UI, and more. One reason Salesforce users have been so slow to adopt DevOps practices is that most of them are simply not needed. Sort of.

The reality is that functionality developed on Salesforce simply exists at a higher level: application configuration instead of infrastructure provisioning. You basically never have to worry about Oracle database patches or that Salesforce will lose your data; but that doesn’t solve the problem of how to ensure that your database fields are consistent across all of your Salesforce instances. The exact same principles championed across the DevOps community are entirely applicable in the Salesforce world, they simply need to be adjusted to the particulars of the Salesforce platform.

DevOps can be understood as bringing together the practices of continuous delivery (and all that entails, such as version control) with principles of lean software engineering and an inclusive focus spanning from development to operations. DevOps builds on principles that have evolved over decades in manufacturing and software engineering and brings them together under a surprisingly catchy moniker.

Version control, continuous integration, continuous delivery, DevOps—what’s that all mean? Version control is a mechanism to track and merge changes smoothly. Continuous integration means that teams should develop their work on a common master branch, minimize branching, and run automated tests after every change to the master branch. Continuous delivery means that all the configuration needed to recreate your application is stored and deployed from version control in an automated way. And DevOps means that both developers (who create new functionality) and operators/admins (who maintain production systems) should work together to optimize the flow of valuable work to end users, build software with monitoring in mind, and use the same mechanisms (such as version control) to both maintain and improve applications.

DevOps has been summarized by Jonathan Smart as “Better value, faster, safer, happier.” “Better” implies continuous improvement, always striving to improve the quality of not only our work but also our processes. “Value” means using agile development and design thinking to address and adapt to the needs of end users. “Faster” means using techniques such as continuous delivery to release more quickly. “Safer” means integrating automated quality and security scanning into the development workflow. And “happier” refers to continuously improving both the development experience and the customer experience of users.

It’s worth noting that the “DX” in Salesforce DX stands for “Developer Experience.” The implication is that Salesforce is investing in providing a better experience for those developing on its platform, not just for its end users. Although the Admin/App Builder experience for Salesforce has always been very good, professional developers have historically been an afterthought. As a developer who moved onto the Salesforce platform, I found it confusing and frustrating that version control was not a common practice, and that Salesforce lacked sophisticated tools such as autoformatting and ESLint that make it easier to write good code in JavaScript.

In The Phoenix Project⁶ and The DevOps Handbook,⁷ Gene Kim popularized the idea that there are “three ways of work” or three movements that summarize DevOps. They are continuous delivery, the “left-to-right” movement of features and fixes from development into production; continuous feedback, the “right-to-left” movement of feedback from testers and production to developers; and continuous improvement, the ambition to always improve the “system of work” that is used to deliver the work itself.

Traditionally, software development was depicted as a linear process similar to an assembly line. But the DevOps community often uses variations on a circle or infinity loop as shown in Figure 1-1 to indicate that software development must be iterative and ongoing. Each stage in the development lifecycle flows into the next in an ongoing pattern. By spanning the entire lifecycle from planning and development to operation in production, DevOps promotes collaboration across teams to maximize the entire value chain or flow of valuable work to end users.

The Research on DevOps

Since 2012, Puppet Labs has produced an annual survey and report entitled the “State of DevOps Report.” That report has become increasingly methodical and influential, especially as Puppet Labs was joined by DevOps Research and Assessment (DORA) group. In 2018, the cumulative research from this report was published as the book Accelerate by Nicole Forsgren, Gene Kim, and Jez Humble (co-leaders of DORA).⁸ In that book (as well as in the annual “State of DevOps” Reports), they provide scientific verification of long-held convictions that adopting DevOps practices predicts software delivery performance, positive organizational culture, and organizational performance (both financial and nonfinancial).

Software Delivery Performance also predicts corporate performance. High software delivery performers are twice as likely to exceed their commercial goals (profitability, market share, and productivity) and their noncommercial goals (quantity of goods and services, operating efficiency, customer satisfaction, quality of products or services, and achieving organization or mission goals).

Another long-standing belief in the DevOps community is that positive organizational culture leads to great results for the company. Salesforce themself has emphasized such a positive organizational culture from its outset, and many organizations in the Salesforce ecosystem such as Appirio also embody principles such as openness and philanthropy. The State of DevOps Report confirms the importance of culture for organizational performance. That same survey confirms that the use of continuous delivery itself predicts a positive organizational culture, high job satisfaction, high delivery performance, and employee engagement. The use of continuous delivery (version control, CI/CD, etc.) also leads to less rework, less deployment pain, and thus less burnout.

About This Book

This book is divided into four parts. Part 1: Foundations, provides an introduction to Salesforce and to DevOps concepts. Those new to Salesforce will find Chapter 2: Salesforce to be a helpful overview of the Salesforce platform, including core concepts and challenges that might not be obvious at first.

Those who are new to DevOps will find Chapter 3: DevOps to be a concise summary of the latest best practices and research on this topic. There is nothing in that Chapter that will be new or groundbreaking for those who are very familiar with DevOps, although it may provide a helpful recap and summary. The reason for providing a comprehensive overview of DevOps is to provide a single reference for people in the Salesforce world who may be unfamiliar with these practices. Books such as Continuous Delivery by Jez Humble and David Farley⁹ will allow readers to go much deeper into these concepts.

The last three parts of the book cover the Salesforce development lifecycle, all summarized into three stages: development, delivery, and operations. These three stages are common to all software development, and are in fact common to manufacturing and product development in general. Things are made, then they’re shipped, and finally they’re used. Along the way, they’re generally bought as well, which implies that what is being created has value.

The only reason things are made is in the hope that they will bring greater benefit than they cost to make or buy. The difference between the benefit something brings and the cost of making it is known as value added. Lean software development, and lean practices in general, talk extensively about value creation, value streams, and value-added steps, in contrast to what is known as waste. The goal of DevOps is to reduce waste, and to enable teams to deliver value as effectively as possible.

Thus when we talk about development, delivery, and operations, we are primarily talking about the stages in which value is created (in the form of new software functionality), delivered (including testing and deployment), and realized or experienced by end users. Part 2: Salesforce Dev provides a concise overview of how to maximize the ease of developing on Salesforce and the quality of the work. Of particular interest is how to develop so that the subsequent testing, deployments, and operations can be as successful as possible. The very definition of DevOps implies that developers keep operation in mind. That means that things are developed so they can be delivered as quickly as possible and operated successfully, and that defects can be discovered and features improved in the most efficient way.

Part 3: Innovation Delivery covers the stages in which Salesforce DX really shines. Software deployments in general are painful; and Salesforce deployments have been notoriously painful. The pain of deployments drives people to do them as infrequently as possible. This means that in addition to being delayed to once a week or once a month (or less), deployments are done in large batches. A fundamental concept in lean software development is to develop and deploy in small batches. This enables the highest value features or fixes to be deployed as soon as possible, reduces the risk and impact of each deployment, and opens the door to fast feedback.

Deployments aren’t just about moving functionality into production; moving functionality into testing environments also requires deployments. So delays in deployment imply delays in testing. Delaying the start of testing doesn’t always mean that go-live can be delayed, so the QA and testing process in Salesforce projects is often squeezed. The high pressure to test quickly to avoid further delays in feature delivery has meant that the entire testing ecosystem in Salesforce is generally underdeveloped, with an overemphasis on repetitive manual testing. Part 3: Innovation Delivery provides an overview of how to deploy, test, and release Salesforce features, including both older technologies and the newer capabilities such as unlocked packages that Salesforce DX provides.

Part 4: Salesforce Ops (Administration) is on operations, or how Salesforce capabilities are used in production. As many people have commented, software spends most of its life in production, so it makes sense to consider that phase carefully, including how to measure and detect issues as quickly as possible. On many platforms, operations is equivalent to administration. But in the Salesforce world, the term “Admin” is overloaded to mean both “keeping the lights on” and building new capabilities declaratively. Salesforce’s “Awesome Admins” are thus responsible for the majority of development on the platform, in the form of adding objects and fields to the database, modifying business logic declaratively, and changing the UI through layouts. The tension between developers and operations in Salesforce is ironically the opposite of how it is on most platforms. On most platforms, it is the admins who are screaming to keep the system stable and running, while developers are clamoring to release new capabilities. In Salesforce, however, it is admins who are more likely to make changes directly in production at the behest of users and to be reluctant to follow the disciplined deployment processes that developers are forced to adhere to. Locking admins out of production (at least in the sense of preventing them from changing the database, business logic, or UI) is actually a requirement for realizing the goals of DevOps. But for this to be palatable, there has to be a smooth and admin-friendly process in place whereby small declarative changes can easily be made, committed, and deployed to production. Thus the final section speaks to how admins can participate in the DevOps process.

For some companies who have adopted continuous delivery for Salesforce, the first skill new Salesforce admins are taught is how to use Git, so that they can make their changes in a development environment, but track and deploy them by themselves. And for those who are skeptical whether their admins will ever adopt Git, we’ll discuss the variety of options available to help Admins keep their orgs stable while still churning out business value at the speed of clicks.

Background

This book arose out of a 4-year focus on the Salesforce development lifecycle, especially Salesforce DX, while working at Appirio. Appirio is a consulting company focused exclusively on cloud technologies, primarily Salesforce. From the beginning, the company has emphasized effective development processes and worked hard to bring customers the most value in the shortest amount of time. I joined Appirio in 2014 as a technical consultant and very soon began evangelizing the use of version control and continuous integration for Salesforce. At the time those practices were quite rare on Salesforce projects. But my colleagues and mentors at Appirio regularly encouraged me that this was indeed a critical need across most projects. My focus became how to adapt these practices to the peculiarities of Salesforce and to help others do the same.

In 2017, after 2 years of working on side projects related to code quality and development automation, Appirio agreed to establish an internal team known as Appirio DX to focus on tooling, training, and evangelism to bring DevOps principles to all of our projects. In 2018 we released Appirio DX as a commercial tool that could be used by anyone to help ease the Salesforce development process. In 2019 I joined Copado, one of the leading DevOps tool providers for Salesforce, to work on the next generation of their platform.

I’ve been inspired by Appirio and Copado’s commitment to empowering developers and admins, and am grateful for their providing an environment in which I could learn so much and be free to chase the wild but important idea that DevOps is critical to delivering innovation while building and maintaining trust.