Salesforce DevOps for Architects E-Book

Rob Cowell

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 413

Veröffentlichungsjahr: 2024

Beschreibung

Rob Cowell is a Salesforce DevOps Advocate with extensive experience as a Salesforce Developer and Architect, guiding best practices for Salesforce DevOps. Lars Malmqvist, a 32x certified Salesforce CTA, has 15 years of experience building advanced Salesforce solutions and is the author of two books, Architecting AI Solutions on Salesforce and Salesforce Anti-Patterns.
As the Salesforce Platform evolves, architects face increasing demand for advanced solutions. This book serves as your definitive guide to mastering effective DevOps practices crucial for successful Salesforce projects. Beginning with cultivating a DevOps mindset focused on collaboration and communication, it emphasizes governance, visibility, and accountability. You'll delve into tools and techniques, leveraging the robust capabilities of SFDX to craft your strategy efficiently.
This book stands out for its practical approach to Salesforce packaging and CI/CD stack creation, guiding you to build a seamless automated change delivery system with freely available software. It addresses critical operational concerns such as ticket management, backups, change monitoring, and data seeding. In the final chapters, you'll discover third-party solutions to expedite your Salesforce DevOps journey, empowering you to deliver sophisticated and efficient projects.

Leseprobe

Salesforce DevOps for Architects

Discover tools and techniques to optimize the delivery of your Salesforce projects

Rob Cowell

Lars Malmqvist

Salesforce DevOps for Architects

Copyright © 2024 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Group Product Manager: Alok Dhuri

Publishing Product Manager: Uzma Sheerin

Senior Editor: Nithya Sadanandan

Book Project Manager: Deeksha Thakkar

Technical Editor: Jubit Pincy

Copy Editor: Safis Editing

Indexer: Manju Arasan

Production Designer: Shankar Kalbhor

Developer Relations Marketing Executive: Deepak Kumar and Mayank Singh

Business Development Executive: Thilakh Rajavel

First published: January 2024

Production reference: 1190124

Published by

Packt Publishing Ltd

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB

ISBN 978-1-83763-605-1

www.packtpub.com

To my wife and daughter, for patiently waiting for me as I disappeared every evening to my desk. To my employer, for their support, encouragement and education.

– Rob Cowell

To Ada, Pino, and Damiana—without whom nothing else makes sense.

– Lars Malmqvist

Contributors

About the authors

Rob Cowell is a Salesforce DevOps Advocate at a leading platform provider in this space. He uses his wealth of experience as a Salesforce Dev and Architect to guide and advise on best practice for Salesforce DevOps. He has gained a unique insight into Salesforce trends and challenges over the years, and uses this to help organizations of all shapes and sizes to optimize their Salesforce processes. Alongside his day job, he is an active participant of the Salesforce community, providing support and sharing experiences to help others thrive.

I’d like to thank my beloved wife and daughter for enduring my long evenings at the desk with patience. Additionally, I extend my gratitude to my employer for their unwavering support, encouragement, and the educational opportunities provided

Lars Malmqvist is a 32x certified Salesforce CTA and has spent the past 15 years in the Salesforce ecosystem building advanced solutions on the platform. Currently, he works as a partner in the management consultancy, Implement Consulting Group, focusing on supporting large Nordic Salesforce clients in their transformation journeys. He has published two books, Architecting AI Solutions on Salesforce and Salesforce Anti-Patterns, both with Packt publishing.

To Ada, Pino, and Damiana—without whom nothing else makes sense.

About the reviewers

Andrew Barrick has been a part of the Salesforce ecosystem since 2015. He has worked at ISVs - firstly as a Scrum Master and Lead Engineer within product engineering teams, and then as a Technical Architect in Professional Services teams designing, building and implementing customisation projects. He is currently a DevOps Architect at Gearset, bringing experiences from across those years to help customers define modern, scalable and resilient Salesforce DevOps practices. Andy has spoken at events across the world on DevOps ideas and ideals, and their application across the software delivery process. He lives on the edge of the Yorkshire Dales with his wife Maria and children Matthew, Samuel and Daisy.

Aidan Harding is the Head of Platform Engineering – Salesforce at Mantra Tech. Before that, he spent 9 years at Nebula Consulting as Technology Director. He regularly speaks at Salesforce community events in the UK including London’s Calling and DevOps Dreamin’. During his time at Nebula, Aidan created various open-source Apex packages including Nebula Core - a set of tools to empower developers to work in a fast and modular manner on Salesforce. Academically, Aidan gained a PhD in Computer Science in 2004 for his work on model-checking systems with game semantics.

Table of Contents

Preface

1

A Brief History of Deploying Salesforce Changes

An introduction to the history of Salesforce as a development platform

Custom objects

S-Controls

SOQL

Sforce web services

Workflows

Apex and Visualforce

Sandboxes and change sets

Metadata and Tooling APIs

Metadata API

Tooling API

The Force.com IDE and Mavensmate

The Force.com IDE

Mavensmate

Introducing SFDX

DevOps Center

Summary

2

Developing a DevOps Culture

The need for a DevOps culture

Strongly defined teams

Closely working together

Constant evolution

Collaboration and communication

Adoption and alignment

Questions to start with

Making life easy for your teams

Governance and risk management

Summary

3

The Value of Source Control

Technical requirements

The importance of source control

Collaboration

Traceability

Automation

Continuous integration

Continuous deployment

Continuous delivery (also CD)

Rollbacks

Incremental development

Fundamental Git operations

Commits

Staging

Repositories

Putting source control into practice

Initializing a new repository

Adding new files to the staging area

Checking everything has been added before the commit

Committing changes to the local repository

Connecting your remote repository

Pushing changes to a remote repository

Merging changes from one branch to another

Merge strategies

Creating a new branch

Switching to a different branch

Viewing commit history

Reverting to a previous version of a file

Git rebasing

Effective Salesforce branching strategies

Git as a backup

Trunk-based development

The feature branch model

The protected master branch model

The expanded branching model

Comparing the branching strategies

Summary

4

Testing Your Changes

Technical requirements

The importance of testing

Integration testing

Regression testing

User acceptance testing

Large volume testing

Apex testing

Testing your LWCs

An example Jest test

Running your Jest tests

Testing your flows

Summary

5

Day-to-Day Delivery with SFDX

Technical requirements

Setting up the tools and your project

The Salesforce CLI

Git

VS Code and extensions

Creating a new SFDX project and connecting it to your Salesforce org

The change lifecycle with Git and SFDX

Getting a Git repository to work with

Getting the latest changes from the main branch

Creating a new feature branch

Working on your changes

Committing your changes

Pushing your feature branch to the remote repository

Creating a pull request

Addressing feedback and updating the pull request

Merging the pull request

Updating your local main branch

Sandboxes versus scratch orgs

Sandboxes

Scratch orgs

Summary

6

Exploring Packaging

Technical requirements

Unmanaged packages

Unlocked packages

Org-dependent packages

Managed packages

Development

Testing

Packaging

Security review

AppExchange listing

Installation and configuration

Ongoing support and upgrades

Packaging models’ pros and cons

Breaking up an existing monolithic application

Summary

7

CI/CD Automation

Technical requirements

Introducing CI/CD

Continuous Integration (CI)

Continuous Delivery (CD)

CI/CD pipeline

GitHub Actions

GitHub workflows in action

Jenkins

Salesforce-specific tools

Practical use of the CI/CD pipeline

Summary

8

Ticketing Systems

Technical requirements

The benefits of tracking your work

Transparency

Accountability

Prioritization

Documentation

Collaboration

Reporting and analytics

Potential pitfalls

JIRA

The JIRA project life cycle

A high-level JIRA workflow

Asana

The Asana project life cycle

A high-level Asana workflow

Azure Work Items

The Azure Work Items life cycle

A high-level Azure Work Items workflow

Using an Azure Work Items workflow with GitHub

Summary

9

Backing Up Data and Metadata

Technical requirements

Why backups should be part of your DevOps process

The cost of data loss

Backups limit disruption

Backups complement development

Backups protect against errors

Backups verify releases

Metadata backups

Data backups

The recovery process

Incident and disaster recovery planning

Incident response plans

Disaster recovery plans

Securing backup data

Navigating GDPR and CCPA regulations for data backups

GDPR overview

Insights into CCPA

Data retention considerations

Options for Salesforce backup

No backups

Manual exports

Version control

Native Salesforce tools

Purpose-built backup solutions

Summary

10

Monitoring for Changes

How to manage your Salesforce environments

The need for monitoring

Exploring different kinds of monitoring

Monitoring metadata

Why monitor metadata?

Monitoring metadata in production

Monitoring metadata in sandboxes

A note on scratch orgs

Monitoring data behavior

Why monitor your data?

Monitoring configuration data

Monitoring data anomalies

Monitoring data quality

Monitoring data volumes

Summary

11

Data Seeding Your Development Environments

Technical requirements

The benefits of accurate data for development and testing

Seeding data in your environments

Working with production data

Challenges and constraints in loading production data

Generating test data

Importing test data

Data load automation

Handling relationships

Considerations for test-data management

Protecting sensitive data with data masking

Understanding data masking

Implementing data masking

Compliance and best practices

Tools and resources

Summary

12

Salesforce DevOps Tools – Gearset

Technical requirements

Gearset overview

Gearset’s strengths

Gearset’s weaknesses

Summary

13

Copado

An overview of Copado

Platform

Version control

Build integration

Deployment

Environments

Change management

Administration

Robotic testing

Understanding the strengths of Copado

Exploring the weaknesses of Copado

Summary

14

Salesforce DevOps Tools – Flosum

Technical requirements

A Flosum overview

Deployments

The Trust Center

Backup and Data Migrator

Integrations and customizations

Flosum’s strengths

Flosum’s weaknesses

Summary

15

AutoRABIT

An overview of AutoRABIT

AutoRABIT platform overview

ARM

AutoRABIT Vault for data protection

AutoRABIT CodeScan for static analysis

Understanding the strengths of AutoRABIT

Exploring the weaknesses of AutoRABIT

Summary

16

Other Salesforce DevOps Tools

Salesforce DevOps Center

Other commercial tools

Salto

Panaya

Prodly

Elements.cloud

Opsera

Open source tools

Happy Soup

SFDX-Hardis

DX@Scale

CumulusCI

Summary

17

Conclusion

A summary of Salesforce DevOps

The field of Salesforce DevOps

Key learnings from Salesforce DevOps tools

Looking ahead – the future of Salesforce DevOps

Common pitfalls to avoid

Implementing a successful Salesforce DevOps strategy

A DevOps implementation checklist

Final thoughts and recommendations

Index

Other Books You May Enjoy

1

A Brief History of Deploying Salesforce Changes

With Salesforce’s own delivery model coming in the form of three major releases per year, the platform has evolved substantially since it was first made available back in 2000. From its early days as a predominantly sales tool, Salesforce has evolved to become a development platform in its own right. With this change came the need to bring true development best practices to your customizations and the need to deliver them effectively.

In this chapter, we’ll be looking at the history of making and delivering changes on the Salesforce platform, to understand the current shortcomings of the built-in tools. This will help set the context for the necessity of a DevOps process and where the current state of the art sits today. We’ll be covering the following main topics:

The beginnings of customizing SalesforceApex and VisualforceSandboxes and change setsSFDX and scratch orgsDevOps Center

Unlike the rest of this book, this chapter does not necessarily provide actionable steps or best practice guidance that you can apply to your Salesforce implementations. However, one of the fundamental principles of being a good Salesforce architect is to understand the why of our decisions. By looking at the history of Salesforce as a development platform, and how it has continued to steer toward contemporary software development approaches and tooling, we can better understand the need for DevOps in the Salesforce ecosystem.

An introduction to the history of Salesforce as a development platform

For any sufficiently complex IT system, it is important to consider the full range of architectural considerations in both the implementation phase and the day-to-day running of the system. These considerations are not just technical aspects but those that sit at the business level as well – strong governance, accurate and up-to-date documentation, definable metrics, and a demonstrable return on investment to the business.

As Salesforce has grown, so has the need to apply these architectural factors to the work we do on the platform. Salesforce has become a first-class citizen in many organizations, acting as the digital hub to run a business. A proper change management process is therefore critical to avoid interruptions of service, and DevOps is the perfect approach to that requirement. DevOps promises faster, more accurate software releases, fewer errors, less downtime, and a faster path to recovery when problems occur.

We can reasonably pinpoint Salesforce first becoming a development platform in 2003. At the company’s inaugural edition of Dreamforce, their flagship conference that continues annually to the present day, they announced a fundamental shift in how customers can customize the platform. Dubbed sforce 2.0, it was initially positioned as an on-demand application server and included some key capabilities, which we’ll explore next.

Custom objects

The first major innovation introduced at this time was the ability to create additional custom objects, much like database tables, to complement the built-in objects provided by Salesforce for their core CRM capabilities. These custom objects could themselves contain custom fields and together provided the early framework for developing custom business applications on the platform.

Suddenly, Salesforce had moved from being just a sales CRM system and started moving toward becoming a platform to develop custom business applications. Salesforce teams were now able to start tailoring processes and applications to the core needs of their business, regardless of which industry they worked in. For example, some Salesforce customers would leverage this capability to start building out the ability to handle support cases for their business – something that didn’t become a core platform capability until the announcement of Service Cloud in 2009.

S-Controls

S-Controls (initially called sforce controls) were one of the two programmatic elements of the new customization capabilities. Combining both functionality and user interface elements in one container, S-Controls could contain any items that could be displayed in a browser, such as Java applets, ActiveX controls, and web forms.

While they’ve been long since deprecated, S-Controls were the first method made available for developers to customize the platform in a programmatic way, and they allowed them to bring skillsets and programming languages from other non-Salesforce development into the platform. They enabled Salesforce developers to harness HTML and JavaScript for the creation of custom pages and user interface components. In this sense, they could be potentially viewed as an early forerunner of Lightning Web Components but without much of the best practice we use today.

SOQL

Sforce 2.0 also introduced Sforce Object Query Language (SOQL), which provided a means of querying data from both standard and custom objects, with a syntax like the industry standard, SQL. This provided developers with a powerful mechanism with which to query the data in their Salesforce organization programmatically and act upon the results of these queries.

If we were to look at SOQL from an architect’s perspective, we can see how this aligns with the need to ensure that your data quality is of as high a standard as your metadata. Clean, actionable data to drive business decisions should always be one of the key deliverables for an architect. SOQL provided an additional means of working with this data, whether operationally for the day-to-day business or as the beginning of a means to extract data from the platform for archival purposes. This latter use case is something that we’ll explore later as we look at the importance of backups in a well-architected Salesforce DevOps strategy.

Sforce web services

One of the other fundamental new capabilities of sforce 2.0 was the ability to integrate Salesforce with other platforms, thanks to the exposing of the object model and business logic via web service APIs. Using the standards at the time, SOAP and WSDL, it was now possible to interact with your Salesforce organization from more traditional development environments and systems, over a network.

Workflows

The last major element introduced with sforce 2.0 was a business process automation engine called workflows. By defining workflow rules that responded to changes in your data, business logic could be triggered for things such as escalations, notifications, and automatic updates to data in response to events. Workflows were still very much a config, not code, means of delivering functionality, but as we’ll see later, being a low-code solution does not mean that it should be ignored when it comes to DevOps.

Apex and Visualforce

At the 2006 edition of Dreamforce, Salesforce’s flagship conference, co-founder Parker Harris revealed the most significant change to the Salesforce platform to date. Customers were now able to develop custom solutions using Salesforce’s own programming language, called Apex, right within Salesforce itself.

A variant of the popular Java programming language, Apex enabled automation through code for the first time. Originally limited to triggers only, developers could now take a programmatic approach to responding to data changes.

Later in the evolution of the platform, Apex would adopt more of the object-oriented paradigm with the arrival of Apex classes, allowing developers to build a more structured, decoupled implementation than triggers alone could deliver.

Alongside Apex, the other major innovation to the Salesforce platform was Visualforce, introduced in 2008. Taking cues from other contemporary UI languages such as ASP or PHP, Visualforce blended HTML with programmatic elements and markup that connected back to your logic written in Apex. Visualforce went on to quickly supersede the S-Controls that were previously introduced, becoming the standard way to write custom user interfaces and pages in your Salesforce implementation.

With all these advances in the platform for development and customization, Salesforce then turned its attention to how to deliver them. Let’s look at how this was initially introduced in the next section.

Sandboxes and change sets

As Salesforce continued to mature, the need to be able to safely make changes outside of production and move them across when ready became obvious. However, the pace of DevOps innovation did not seem to keep up with the rise of Salesforce as a development platform.

Sandboxes were introduced in the winter 2006 release, allowing customers to try out changes and enhancements in a safe environment away from production – but with a catch. The original implementation of sandboxes did not allow you to move those changes back to production, meaning that you had to recreate those changes again in your production environment manually. This would be both time-consuming and error-prone.

In recognition of this shortcoming, change sets were initially introduced in beta for the winter 2010 release, some four years after sandboxes, and finally, they became generally available in the Spring 2011 release. Change sets finally allowed the code and configuration work done in sandbox environments to be packaged up and moved between environments, whether from sandbox to sandbox, sandbox to production, or even production to sandbox. This opened up new possibilities to plan Salesforce environments as part of a mature application development life cycle – you could now have dev, QA, UAT, and staging environments ahead of production go-live. This was the first significant step toward achieving a DevOps process that matched those on other development platforms.

Metadata and Tooling APIs

To open the platform to better tooling for development and deployment, Salesforce introduced two important APIs – Metadata API in the Spring 2008 release and Tooling API in the Spring 2013 release. While they both fulfilled similar functions, there were some important differences in their aims and functionality.

Metadata API

At the simplest level, metadata is data that describes the structure of your data, but for the Salesforce platform, that is a bit of an oversimplification. The term metadata covers many of the configuration and customization elements of Salesforce as well – at the time of writing, Salesforce’s own Metadata Coverage Report, available at https://developer.salesforce.com/docs/metadata-coverage, indicates 601 metadata types in the platform, the vast majority of which are covered in Metadata API.

Metadata API can be used to move this metadata between environments. You can retrieve the metadata as XML files from one Salesforce organization and deploy it into another. Much like change sets, the source and target for these operations can be sandboxes, production, or, as we’ll learn about shortly, scratch orgs.

Additionally, Metadata API allows you to create, update, and delete metadata within a Salesforce org, and this unlocks a fundamental capability for both Salesforce development and to adopt a DevOps approach on the platform.

The Metadata API underpins most DevOps tools on the platform, whether that’s Salesforce’s own SFDX, the new DevOps Center, or the various third-party Salesforce DevOps solutions available. They all leverage Metadata API to coordinate the movement of your code and config between environments.

Tooling API

While Metadata API did much of the heavy work of managing metadata, Salesforce introduced Tooling API to provide further capabilities that better aligned to DevOps practices, such as smaller and more focused metadata retrieval and deployment, the ability to run unit tests and view both the test results and the associated code coverage, and support for some additional code debugging capabilities.

Being able to manage unit test cycles makes Tooling API another strong candidate for use in DevOps processes and tools. As architects, we need to ensure that we not only deliver code quickly but also that it is of the right quality – it doesn’t break in isolation, it doesn’t break existing code, it fulfills the requirements for which it was created, and it deploys between Salesforce organizations seamlessly. These are all factors of the Change Failure Rate, one of the fundamental DevOps metrics that we’ll explore in the next chapter as we look at what the key considerations to develop a DevOps culture as architects are.

Tooling API is primarily targeted at those wishing to create additional development tools or apps for the platform, and its arrival heralded Salesforce development support in some of the popular IDEs of the day, which we will look at next.

The Force.com IDE and Mavensmate

With new tools that leveraged Metadata and Tooling APIs, it was no longer necessary to develop for the Salesforce platform from within the platform. To assist developers with this approach, Salesforce started looking at how best to deliver a standardized developer experience that matched the standards of the time. Let’s run through the tools available at that time.

The Force.com IDE

One of the early IDEs that took advantage of this was Salesforce’s own Force.com IDE.

Built on top of the modular plugin architecture of the popular Eclipse development environment that was predominantly used for Java, the Force.com IDE took advantage of the new APIs to allow developers to not only code with a proper editor but also to save their changes back in their development organizations, directly from the IDE, without having to switch back to the Salesforce user interface.

The Force.com IDE became very popular very quickly, as it was the first attempt to provide a modern environment for Salesforce developers, with some of the niceties that developers on other platforms such as Java or .NET had come to expect. However, it developed a reputation for being slow and unstable equally as quickly.

Mavensmate

As an antidote to the heavyweight installation of Eclipse and the plugin, and as a potential means to improve speed and stability, 2013 saw the arrival of another development tool for Salesforce – Mavensmate.

Mavensmate took the same plugin approach as the Force.com IDE, in that it effectively extended another editor called Sublime Text (and later, support was added for the rival Atom editor), but both the underlying editor and the Mavensmate plugin on the top were considerably more lightweight. This made working with Salesforce development easier, faster, and more stable than ever before, and Mavensmate became the choice of Salesforce developers everywhere on the basis of its speed and ease of use – not just for development but also to deploy changes, thanks to the use of the Metadata and Tooling APIs.

Introducing SFDX

The state of Salesforce change management had largely remained stable for several years. For the majority of Salesforce developers and admins, change sets remained the definitive means of delivering change from sandbox to production.

All this changed again when Salesforce released its SFDX toolchain in 2018. SFDX offered the promise of modern development and deployment practices, seen on other platforms, delivered through a command-line tool. Suddenly, the potential existed for advanced, scriptable deployments, more robust IDE integration, and a new way to manage changes. Most importantly, it represented the move toward a source-driven development model for Salesforce, rather than the traditional organization-based model.

The SFDX command-line interface (CLI) was coupled with the introduction of scratch orgs. These are ephemeral development environments that can be spun up and torn down easily from SFDX, created using different configurations (or org shapes), and populated with test data. The ability to create them from a command lent itself to a new era of automated testing, as we shall see later, but it also reinforced the principle that organizations are now secondary to source code. If a scratch org expires, it’s not a major issue because another one can be easily recreated from the source code.

Finally, Salesforce had recognized the need for tight integration with development tools and provided extensions for the popular Visual Studio (VS) Code environment, easing both development and deployment on the Salesforce platform, right from the IDE. Additionally, by building on open standards such as the Open Command Line Interface Framework (OCLIF), it opened the tool up to extension via plugins, which were contributed from both inside and outside Salesforce, extending the capabilities of the SFDX CLI and filling some of the gaps that the tool didn’t cover natively.

SFDX continues to be the Salesforce-recommended approach for developers working with the platform, especially around integrating it into CI/CD pipelines and other automation. As of December 2022, Salesforce is continuing a drive toward a unified CLI that combines the SFDX command line and the newer SF command line, which introduced a newer structure and a cleaner approach. This consolidation will hopefully result in an even more efficient command-line toolset that will increase the ease of building a robust DevOps pipeline.

DevOps Center

Salesforce has long acknowledged that the platform has outgrown change sets, but SFDX was (and still is) perceived by its customers as a tool solely for developers and those comfortable with the command line, despite the VS Code extensions that made it easier to work with. A considerable ecosystem of third-party providers such as Gearset, Copado, AutoRABIT, and Flosum had sprung up to provide platforms for robust DevOps that better matched the wider IT industry’s best practices. These tools gave Salesforce developers and admins capabilities such as organization-to-organization comparisons, version control capabilities, static code analysis, and deployment pipelines.

Salesforce entered this space with the release of DevOps Center, which became generally available in December 2022. While not as feature-rich as the incumbent solutions from the third-party ecosystem, it represented a change of messaging from Salesforce to all users – a move away from change set deployments to something that was easy enough to work with, whether you were a low-code or pro-code admin or developer.

We’ll be exploring the specifics of DevOps Center (and indeed, the leading solutions in the third-party Salesforce DevOps space) in a later chapter, but it’s important to see how much of a fundamental shift in thinking this new product is, particularly when viewed in the context of the history of creating and delivering changes to the platform described earlier.

DevOps Center introduces much of the best practice in Salesforce DevOps that’s slowly been established, incrementally, over the years and packages it up in an easy-to-understand native interface, right within the platform:

It guides Salesforce practitioners toward a model in which source control is the version of truth for changes, rather than sandbox organizationsIt encourages the concept of isolated, incremental change through work items, or user stories – a concept popularized by the agile movement and popular in the DevOps strategy of many other platforms and organizationsMost importantly, it gives better visibility and accountability for change delivery

These are factors of the overall architecture of a DevOps process, which we shall delve into later in this book. It doesn’t cover every aspect thoroughly in the initial release, and it should very much be considered a DevOps tool rather than a DevOps solution, but as a means of educating Salesforce users on the basics of DevOps and weaning them off change sets, it’s a very solid start.

Summary

In this chapter, we looked at the history of Salesforce as a development platform and saw how features were added over the years. We also explored the approach to delivering those changes on Salesforce, from change sets, through the various APIs and tools that utilized them, to the arrival of DevOps Center.

Armed with this knowledge, we can not only better appreciate how far the platform has come but also understand the reasoning behind some of the design choices we have today, gaining a little knowledge of older implementations, which can often prove useful when faced with having to work on older Salesforce organizations.

As architects, it’s important to not take DevOps tooling for granted, and having the ability to work with a variety of different approaches and solutions, no matter how old, will help us to work with and improve the state of Salesforce DevOps for the implementations we deliver. In subsequent chapters, we’ll look at some of the most recent tooling and, more importantly, the techniques and processes that shape modern Salesforce DevOps.

2

Developing a DevOps Culture

The core of a successful DevOps implementation does not lie with the technology and tooling used. Instead, getting the surrounding team culture in place and aligned with a new way of working is the most essential element that underpins DevOps.

In this chapter, we will cover the importance of the offline aspects of DevOps, and how a culture of collaboration and communication is fundamental to DevOps success. We’ll see ways in which to drive adoption and alignment with best practices in your organization. Along the way, we’ll explore the following:

Why culture is key to a DevOps transformation and how we can start building itThe need to strive for strong communication that drives collaborationWays to drive adoption of and alignment to a DevOps approach

The need for a DevOps culture

The history of software development and its delivery has been long and ever-changing. As the landscape of technology has changed, so has the need for businesses to get that technology into the hands of customers. DevOps represents a drive to deliver according to that need, replacing monolithic software releases, lengthy project cycles, and opaque waterfall methodologies.

When we look at DevOps as a way of delivering change, it’s very easy to get pulled into looking at the software tools first, but this should not be where your DevOps journey begins. It’s equally important to keep in mind that any DevOps transformation should not be prescriptive; instead, it should align with you and your organization’s way of working. This approach is equally important for those that have had prior DevOps experience with other teams or systems – there is no “one size fits all” approach to DevOps, and while experience can be brought to bear on building a DevOps culture with a new team, you should be mindful of tailoring it to fit the team.

However, there are some common elements that work consistently for high-performing DevOps teams, so you should contemplate making these a part of your plan to bring DevOps culture to life. Let’s begin by looking at some of the characteristics of successful DevOps teams and the elements of DevOps culture they have adopted, before diving deeper into how to deliver them.

Strongly defined teams

As the name suggests, DevOps teams are a hybrid of IT Development and IT Operations teams, but the reality is not as straightforward. Successful DevOps teams comprise teams from the full end-to-end spectrum of software delivery, from business analysts gathering the requirements and architects designing solutions to those requirements through to developers implementing those solutions and operations delivering those requirements in your Salesforce environments.

It is within this cross-functional team structure that you need to establish strong buy-in for DevOps. A team that does not understand or appreciate the value of a process is unlikely to adopt DevOps – and it only takes a few shortcuts or out-of-process releases to damage the good work the rest of your DevOps team has done. It is vital that the entire team aligns and engages with DevOps as a way of working, to make the initiative successful.

A team that aligns with DevOps practices has shared responsibility for the entire application life cycle, from planning to deployment and maintenance, thus reducing standoffs and finger-pointing over who is responsible for fixing bugs or test failures. Additionally, DevOps encourages product teams to be more involved in the development process, ensuring that their input and expertise are considered throughout the application life cycle.

As architects, we need to convey the value that DevOps brings since for most teams – whether technical or on the business side – this tends to be the key factor that gets people on board. By showing how DevOps benefits everyone along the development journey we have outlined, we stand a better chance of getting teams on board with DevOps, compared to a hard enforcement of processes.

Companies that have yet to adopt a DevOps culture for software delivery may have lost trust in their delivery teams, bringing in heavyweight processes in an attempt to prevent the risk of future failures. Part of adopting a DevOps culture is restoring that trust by providing tools and processes that empower teams to succeed and allow any failures to be small, rather than bogging everything down by trying to avoid failure entirely.

In general, one of the benefits of DevOps and Agile is to be able to take small steps safely. DevOps and Agile methodologies advocate for small, incremental releases rather than large, monolithic deployments. This approach allows teams to identify and fix issues more quickly, reducing the risk of catastrophic failures. It also enables them to respond to changing requirements or market conditions more effectively. As a result, trust in the team’s ability to deliver accurate results and adapt to change grows.

Closely working together

Hand in hand with strong teams is the need to collaborate and communicate with each other. This may seem an obvious need in all working teams, not just DevOps, but the principles of clarity, visibility, and cooperation really come to the fore with DevOps and are essential for its smooth running.

To break down the siloed approach to software delivery and work toward a common goal, the entire team needs to be aware of how projects are being delivered. Techniques such as Agile and tools such as Jira or Asana will certainly help with this, but that’s only part of the picture of collaboration, as we’ll explore shortly.

Constant evolution

No matter how mature a DevOps team may be, the highest-performing teams are always open to change and improvement. Through a continuous cycle of measurement, enhancement, and re-measuring, these teams are able to pinpoint areas where performance and accuracy gains can be made and then address them. The most common metrics they tend to focus on are based on the DORA metrics, as follows:

Deployment frequency: How often a team releases to productionChange lead time: How long it takes for a specific feature to reach productionChange failure rate: The proportion of deployments that either fail to deploy or cause errors in productionMean time to recovery: How long it takes to recover from a production error or another issue

In the context of Salesforce, measuring against these metrics can be a bit different since it’s a cloud-based platform with specific features and limitations. Metrics such as deployment frequency, change lead time, and mean time to recovery can be determined easily enough, especially if you have a ticketing system such as Jira or Asana for managing new work.

The change failure rate can be a little trickier, though, since it involves tracking unsuccessful deployments and the number of incidents or defects related to those deployments. There are a few ways you could approach this – we’ll cover Salesforce-specific DevOps solutions and platforms in later chapters, but as an example using on-platform features, you could try the following:

Use Salesforce’s deployment history, available on the Deployment Status page, to track the success and failure rates of deployments. Identify failed deployments and the specific components that caused the failure.Keep a record of all production incidents, including those caused by recent deployments. You can use the Salesforce Case object to log and track incidents.For each failed deployment or production incident, analyze the root cause and determine whether it was due to a recent change. You can use the Salesforce Developer Console, debug logs, and test results to pinpoint the root cause of the issues.Divide the number of failed changes (deployments causing incidents or defects) by the total number of changes made during a specific period. Multiply the result by 100 to get the change failure rate as a percentage.

The origin of the DORA metrics

The DORA metrics came from a group called DevOps Research and Assessment, which was founded in 2015 by Nicole Forsgren, Gene Kim, and Jez Humble (and later acquired by Google in 2018), to better understand what factors led to high-performing DevOps teams. Since that initial research, these four metrics have become an industry-standard set of measurements of DevOps success.

Now that we’ve determined the need for, and elements of, a strong DevOps culture, let us look in more detail at some techniques for creating this culture.

Collaboration and communication

In an ideal DevOps team, the whole team works in the same way and toward the same goal – there should be a shared responsibility for the successful delivery of changes. Fundamental to this collaborative approach is strong communication, and this can take many forms, from the more formal approach needed for governance of the overall change management process down to the daily interactions that form part of your usual workflow.

Communication should be clear, informative, and present at every step of the delivery life cycle. For example, when using version control, teams should endeavor to always provide meaningful commit messages and comments on peer reviews. These aid teams to carry out the next steps of any change delivery process with context, not just the specifics of the change itself. There is often a balance needed between providing sufficiently detailed information and relevant information, and you should iterate on this level of detail to find the sweet spot that works for you and your team.

While this book is not an exploration of Agile principles, there does seem to be a strong correlation between successful DevOps teams and Agile practitioners since both disciplines foster these same principles of regular, clear, and concise communication to drive projects forward. Such techniques encompass all team members involved in delivering change so that everyone is informed and aware of the process and progress of work.

Equally, tools will help bring visibility and clarity to daily work. Software for managing features as they go through your DevOps process, such as Jira, Asana, Azure DevOps, and so on, can bring this overview to your processes when used properly and they integrate in some way into most DevOps tools to complete the picture. Many teams have started to eschew email as an internal communication medium, instead favoring the immediacy of messaging platforms such as Slack or Teams as a further means of breaking down siloes and removing barriers between cross-functional teams.

The necessity of adapting to remote work has led to an increased reliance on digital communication tools and has changed the dynamics of team interaction in a number of ways. With teams distributed across various locations and time zones, it is essential to have tools that enable real-time collaboration and offer instant communication, file-sharing, and integration with other tools. In remote work, it is not always possible to gather everyone at the same time for discussions. Asynchronous communication tools, such as project management platforms, shared documents, and threaded discussions on messaging apps, allow team members to contribute at their convenience and keep everyone informed of progress.

With every adaptation that needs to be made with the shift to remote working, balance is key. With the shift to digital communication, remote workers may face an influx of messages and notifications. Messaging platforms have adapted by offering features such as channels, threads, and snooze options, allowing team members to prioritize and manage their communications effectively. However, it is equally important to maintain a sense of connection and engagement between team members. Messaging platforms facilitate informal interactions, such as virtual water-cooler conversations, quick check-ins, and social activities, helping teams stay connected and fostering a positive team culture.

Remote work has made it necessary for teams to communicate effectively without the context provided by face-to-face interactions. Modern methods of communication for distributed teams encourage team members to be more concise and clear in their communications, as well as more intentional with their responses.

Finally, as remote work relies on digital communication tools, ensuring data security and compliance with industry regulations becomes critical. Technological solutions have responded by offering end-to-end encryption, data storage options, and compliance features tailored to different industries.

Adoption and alignment

As we’ve seen, the