What is Salesforce DevOps?
Development Operations (DevOps) 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 the following:
- 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 the unit, end-to-end, and user acceptance testing;
- Deploying changes across instances with speed, efficiency, and consistency;
- Conducting these activities in alignment with your organization’s maturity and capacity to manage them at the appropriate scale;
Our previous blog series discussed DevOps and CI/CD aspects for development teams, touching on some of the abovementioned mechanics. We covered Continuous Integration on GitHub, GitHub Actions on Continuous Integration, and 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.
This blog post will address some critical pieces necessary for your organization’s 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 will ultimately 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?
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 to 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 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 through industry-standard data integrations. Salesforce is now your source of truth and is very much aligned with your business’s “Big Why”.
Salesforce DevOps is The Next Why
As your Salesforce instances’ 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 daily) need development, configuration, and testing outside 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.
Company Alignment
Understanding the relationship between your business goals and your Salesforce org is the first step towards alignment with 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 will determine your next steps toward 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 with 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 will 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
The Visionary is the individual who champions the ideals of Salesforce DevOps and aligns others with that mindset.
- They are vigilant in looking for opportunities to reinforce the value of the core tenets of DevOps to stakeholders.
- They fight for time and space for technical owners to create concrete processes for the vision.
- They must also keep the team focused and on task, 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 of 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).
- They have a knack for picking up things quickly and won’t get bogged down in the details.
- They can plan and prototype the core CI/CD pipeline for iterative development.
You will likely 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.
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
The Continuity is equal parts interviewer, writer, librarian, promoter, and educator of Salesforce DevOps.
They sit squarely in the middle of change management and understand that DevOps affects people, no matter how silently, robotically, and elegantly it operates. The behavioral changes need to be communicated, reinforced, and constantly justified, 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.
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.
You should anticipate a source control management system, a continuous integration and delivery platform, shell scripts, configuration files, diagrams, and spreadsheets in your tooling repertoire.
While the outputs of well-orchestrated DevOps processes result in automatically storing, tracking, and moving large data and file sets, 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.
Takeaways
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.
We’ve cataloged the key points when considering your path toward Salesforce DevOps to see how these moving parts work together. 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?
