What is Salesforce DevOps?
Simply put, DevOps (short for “Development Operations”) is the alignment of an organization, its people, tools, and behaviors to facilitate technical and behavioral change within its software development practices
Salesforce DevOps is the application of these DevOps principles in the context of your organization’s Salesforce instances. When it comes to Salesforce DevOps, the mechanics revolve largely around:
- Managing the topology of your production and sandbox Salesforce instances;
- Maintaining the metadata (configuration and code) with a level of robustness consistent with the complexity of your environments;
- Planning, executing, and mediating issues related to unit, end-to-end, and user acceptance testing;
- Deploying changes across instances with speed, efficiency, and consistency;
- All of these activities conducted in alignment with your organization’s maturity and capacity to manage them at the appropriate scale;
Our previous Continuous Integration blog series discussed aspects of DevOps and CI/CD for development teams, touching on some of the mechanics noted above. Specifically, we covered Continuous Integration on GitHub, GitHub Actions on Continuous Integration, as well as implementing a specific DevOps tooling implementation with Github Actions.
While CI/CD is a core set of tools and behaviors for a mature DevOps practice to adopt, there are many considerations to make first about your company and the team you have available when devising a Salesforce DevOps strategy. In this article we will address some critical pieces that are necessary for your organization’ game board to give you the correct perspective and guidance to begin a paradigm shift towards continuous improvement for your Salesforce Development Operations.
Start with your Organization’s Big Why
Why bother with Salesforce DevOps? How can it sustain or support growth in your organization? Doesn’t Salesforce just update itself three times a year and take care of everything?
We’ve heard these questions (and many more) when discussing DevOps with our clients. They are absolutely valid and a level of suspicion is a healthy starting point for anyone wondering what DevOps is and how it’s ultimately going to make anything better in your business. Let’s start by taking it up another level: how does Salesforce (and thereby, a Salesforce DevOps strategy) support “The Big Why” of your business’s overall strategy and purpose?
Let’s imagine your business is furniture manufacturing. Your “Big Why” might be to be the premier designer and manufacturer of coffee tables with modern design aesthetics, manufactured with locally sourced lumber harvested with sustainable practices. Your Sales team relies on Salesforce for its day-to-day operations and your production team uses Salesforce to manage capacity and fulfillment of orders. Suddenly, Salesforce has become a part of your “Big Why”, supporting your product catalog, sales lifecycle, and delivery processes.
As your business grows, complexities will settle in. Your product offerings and customers evolve. Selling into new customer bases demands different strategies around pricing, quality, and expectations. More sophisticated coffee table designs requested by customers demand more sophisticated production practices. Your company’s growth has forced a much larger network of suppliers that you must hold accountable to your sourcing and sustainability goals in order to preserve your brand’s authenticity.
Any of these scenarios of intricacy would likely translate into complexity in your Salesforce instance. Perhaps the sales team demands a streamlined user experience to make quotes and orders easier to produce, review, and receive customer signatures. Maybe production is asking for a project management system to better manage tasks and measure the effort to fulfill orders. Or suppliers want to share their inventory data with you in real-time by way of industry-standard data integrations. Salesforce is now your source of truth… and now very much aligned with your business’s “Big Why”.
Salesforce DevOps is The Next Why
As your Salesforce instance’s complexity increases in support of your organization’s Big Why, risk is inevitably introduced. User experiences, packaged and custom applications, and integrations (all things Red Argyle supports its customers with every day) need development, configuration, and testing outside of your production Salesforce instance to assure functionality, quality, and security. This upfront work in a sandbox mitigates risk in your production Salesforce instance, which could otherwise break (and break your Big Why).
But how does all this work in a sandbox make its way to production? How will the work be verified and cataloged for future reference to understand what changed? What if production is configured differently than your sandbox? How long is all of this going to take?
Just as our questions earlier on were answered by The Big Why for your business’s alignment to Salesforce as a platform, answers to these types of questions are the essence of Salesforce DevOps and are answered by “The Next Why”: the need to align to a Salesforce DevOps strategy.
Understanding the relationship between your business goals and your Salesforce org is the first step towards alignment to Salesforce DevOps: you recognize the value that Salesforce brings to your organization and you want to take steps to proactively manage the stability of Salesforce.
Your role in your organization is going to determine your next steps towards company alignment. A CEO, CTO, Engineering Lead, and Staff Developer will have different paths with varying overlaps to articulate a vision, demonstrate the value, demand a budget, and establish and/or become compliant with corporate governance and best practices. Beyond these fundamentals, a Salesforce DevOps strategy also needs to align practically to your project management, change management, and performance management systems, as all will be used to plan, deliver, adapt, and measure the outcomes of your DevOps strategy. Finally (and perhaps most importantly), Salesforce DevOps needs to align culturally to the mindsets of innovation, continuous improvement, curiosity, and perseverance within your organization and its people – standing up DevOps demands experimentation, seemingly endless repetition, and occasional frustration at inanimate objects.
Your DevOps Team
Speaking of people, you’re going to need a team to support Salesforce DevOps that will scale to match complexity, sophistication, and the constraints of reality in your organization. While a team is difficult to categorically prescribe based on these facets, some roles are critical to start a Salesforce DevOps initiative, and other roles become pivotal as scale and complexity evolve.
The Visionary is the individual who champions the ideals of Salesforce DevOps and aligns others in that mindset. She is vigilant in looking for opportunities to reinforce the value of the core tenets DevOps to stakeholders. She fights for time and space for technical owners to create concrete processes for the vision. She must also keep the team on rails, balancing team members’ curiosity and desire to optimize while avoiding side-tracking rabbit holes and “shiny things” that distract processes more than benefit them. Keeping the path clear, straightforward and rewarding is the goal for the Visionary.
The Technical Owner(s)
The Technical Owner is passionate about investigating and diving into new technology (and isn’t afraid of a bit of tinkering). She has a knack for picking up things quickly and won’t get bogged down into the details. She is capable of planning and prototyping the core CI/CD pipeline for iterative development. Odds are, you will have multiple Technical Owners as your DevOps processes evolve and make room for broader technical ownerships and collaboration. You may align technical owners to the systems involved or by the skills they bring to bear.
The Project Manager
While Salesforce DevOps may begin as a grassroots effort with one or two people to prove out the concepts, eventually the efforts will expand and demand coordination and visibility within your organization. Whether you have a dedicated Project Management Office that assigns project managers or you dub a project-minded technical owner with project management responsibilities, someone needs to orchestrate scope, schedule, quality, and people for any DevOps effort beyond nights-and-weekends-skunkworks. Likewise, accountability of Technical Owners (and The Visionary) to a Project Manager should apply just enough pressure to ensure outcomes are defined (even if iteration is intended) and demonstrable progress is made against the goal (which senior leadership and project funders greatly appreciate).
The Continuity is equal parts interviewer, writer, librarian, promoter, and educator of Salesforce DevOps. She sits squarely in the middle of change management and understands that DevOps affects people, no matter how silently, robotically, and elegantly it operates. From a new term in technical vocabulary, to the implications of how it affects the request and rollout of new features in a Salesforce instance, the behavioral changes need to be communicated, reinforced, and constantly justified. While The Visionary and The Continuity defend the value from different angles, both are needed to assure success.
Tooling and Roadmap
While tooling is not our starting point (rarely does just picking a tool without a purpose or people solve a DevOps problem), tooling is critical for a successful Salesforce DevOps initiative, particularly for any aspect of DevOps that demands automation, data and file analysis, and cataloging change beyond human-scale. To these ends, you should anticipate a source control management system, a continuous integration and delivery platform, shell scripts, configuration files, diagrams, and spreadsheets in your repertoire of tooling. While the outputs of well-orchestrated DevOps processes result in the storing, tracking, and moving of large data and file sets automatically, there’s a lot of manual work that your Technical Owners will work through to tie all the points together.
The theme of scale and complexity apply yet again with tooling: you don’t need the ideal tooling solution on Day One. Outline your tooling roadmap with a natural progression of scale and complexity in mind – this will likely have a nice side effect of establishing phases or applying logical constraints to your DevOps project (which will help your Project Manager sleep at night). Frequently reflect on and challenge your roadmap over time: it’s not uncommon for the purpose or feature set of one tool to expand and potentially replace some of the boxes and arrows in your roadmap, reducing complexity or cost.
A successful Salesforce DevOps initiative embodies purpose, alignment, people, and tools. No two Salesforce DevOps implementations will be identical, we hope this post outlines areas for considerations and sparks conversations in your organization.
To visually see how these moving parts work together, we’ve cataloged the key points when considering your path towards Salesforce DevOps. We hope you’ll find this resource valuable and shareable with other members of your organization.
Red Argyle works with organizations of all sizes on Salesforce projects of all sizes. We are supporting more and more clients with their Salesforce DevOps practices by applying the concepts above to match their specific needs – how can we help you?