® White Paper DevOps for Salesforce: Choosing Between a Build and Buy Approach Even in the ecosystem surrounding Salesforce (which was We are living in the not a focus of DevOps activity early on), organizations Age of DevOps. are now looking for ways to leverage DevOps and CI/CD. This can be challenging, because a CI/CD solution for Salesforce needs to address unique challenges that do not exist in the context of generic DevOps. Those challenges include issues such as how to integrate Salesforce (a decades-old platform that was first released well before anyone was talking about DevOps) into a CI/CD pipeline from a technical perspective. They also include questions related to managing Salesforce metadata, parent-child relationships, and auditing, which standard DevOps tools are not typically able to address. With these challenges in mind, this white paper walks through best practices for implementing a Salesforce- friendly DevOps solution. In particular, it focuses on how to make the right decision regarding whether to build a CI/CD pipeline for Salesforce by implementing your own toolchain or adopting a ready-made solution. In other words, we address the build-vs.-buy question of Salesforce DevOps. To learn more about AutoRABIT and find out how you can set up an AutoRABIT Playground to test the product for free, visit autorabit.com. Build vs. Buy Considerations Resources • Do you have the headcount to create what you need? • Can you outsource if necessary? • Maintenance? Timeline • How soon do you want/need functionality? • Can you afford to wait? Uniqueness • How “out-of-the-box” are your needs? • Do your research Competition • Consider the business landscape your company operates in • The prize is smaller for second & third place 2 ©2019 AutoRABIT Inc. ® The Components of a DevOps Solution Terms such as DevOps solution or CI/CD toolchain refer to the set of steps that organizations must perform in order to release software in a way that meets the goals of DevOps culture. DevOps culture emphasizes constant communication across the team responsible for software delivery, an embrace of automation wherever possible, and a commitment to efficiency and continuous improvement. To put those principles into practice, DevOps teams look for tool sets that automate and streamline all of the steps required to take code from design through to deployment and management within production environments. The goal of a DevOps toolchain should be to make the various stages of software production fast and continuous. It should help organizations avoid unnecessary delays or wastes of time, as well as help them achieve maximum visibility into the state of their software delivery process. Salesforce for DevOps Is Different The market for DevOps tools in general is saturated. There are a wide variety of code management, integration, and release automation solutions available, from both open source projects and commercial vendors. For organizations that build Salesforce applications, however, few of these tools are useful. That’s because DevOps for Salesforce involves a variety of unique challenges and special needs. • Generic DevOps tools, such as open source CI servers and build tools like Jenkins, lack critical features for enabling automation and efficiency within Salesforce delivery pipelines. For example, generic DevOps build tools require an entire XML file for every deployment, instead of being able to detect only which parts of the XML file have changed. That’s highly inefficient for Salesforce apps, whose XML structure typically changes with each deployment. • Similarly, most DevOps build tools have a limited ability to understand Salesforce object hierarchies during data migration. As a result, they require manual effort on the part of admins to ensure smooth migrations to target environments. Manual effort is something that DevOps aims to minimize. • Deployment rollbacks — important for deploying DevOps effectively in fast-changing Salesforce environments — are another feature that is missing in most DevOps build tools. Without extensive manual scripting efforts, they cannot automatically roll back a problematic deployment in order to minimize disruptions to end-users. • Additionally, in order to use generic DevOps tools for Salesforce application delivery, organizations must manually update build scripts constantly. The tools can automate builds, but they can’t automatically keep up-to-date with changing Salesforce metadata components, API versions, and so on. • Finally, open source CI servers and build tools are not designed with the needs of the enterprise in mind. Most are hampered by cloud infrastructure restrictions, which severely limit deployment options and throttles release speed. Such solutions lack cloud security and offer little in terms of compliance. DevOps for Salesforce: Choosing Between a Build and Buy Approach 3 The Challenges of Building Your Own DevOps Solution for Salesforce Consider the following: Building your own DevOps toolchain for Cost Salesforce software delivery can seem On the surface, building your own Salesforce CI/CD toolset may seem cost-effective, especially because you tempting. This is especially true because can acquire some generic CI/CD tools for free. However, many of the tools for building a standard when you factor in the costs of employee time, cost savings CI/CD pipeline (such as CI servers, version- can quickly evaporate. control systems and release automation Even with a pipeline that incorporates free tools, employees tools software) are free and open source. will need to spend considerable time modifying those tools to be compatible with Salesforce. Build tools need to be However, for a Salesforce application customized in order to be able to understand and address in particular, building your own DevOps the requirements of the metadata API. Deploy tools must solution is often challenging, and understand Salesforce dependencies. Tools for managing ultimately not worth the time, money and visualizing source code must be tailored to keep in sync with the ever-changing requirements of Salesforce itself. or risk. Organizations will also need to write some custom tools to address tasks that open source tools cannot cover, such as Salesforce-specific application monitoring. And they will need to maintain these tools on an ongoing basis. As a result, a self-built Salesforce DevOps toolset could easily end up costing millions of dollars in upfront expense, if it requires the full-time effort of multiple software engineers who command salaries of $150,000 or more per year. It could also cost hundreds of thousands of dollars per year in employee time to maintain the solution on an ongoing basis. Efficiency of use A Salesforce DevOps pipeline that you build yourself is not likely to be highly efficient. As noted above, it will lack awareness of Salesforce-specific requirements, like how metadata impacts deployment. This means that the solution will impose a form of technical debt on your organization, because using it will require extra effort, as compared to a solution that is designed to be Salesforce-aware from the start. 4 ©2019 AutoRABIT Inc. Challenges (continued) ® Functionality gaps Maintenance As noted above, some of the tools required to All software has to be maintained. But software that build a standard CI/CD pipeline are available for free; for depends on Salesforce imposes an extra-heavy maintenance example, there are a number of open source CI servers, burden. such as Jenkins and Travis CI. The problem with these Salesforce issues three releases every year. Every release tools for doing Salesforce DevOps, however, is that none of includes new metadata types, or changes to existing ones. them were designed to address the unique requirements of For example, Permission Sets behavior completely changed Salesforce software. As a result, they leave many functional in Salesforce API 40.0. Similarly, FlexiPages sees changes to gaps that must be filled via manual effort and maintenance. metadata structure in almost every release. There are also important steps in the CI/CD process that Keeping a DevOps toolchain compatible with Salesforce’s free tools don’t address at all. For example, you will be ever-changing metadata types and other updates requires a hard-pressed to find an open source tool that can automate significant investment of ongoing resources if you build the application deployment, especially for a multi-branched DevOps solution yourself. Salesforce application in which understanding metadata and Distraction from main business dependencies is critical for efficient deployment. Given the amount of custom tooling required, cre- Consider, too, the fact that Salesforce is a continuously ating your own DevOps solution will require you not just to evolving platform. In recent years, Salesforce has introduced commit developers to write the code, but also to hire release tools like Salesforce DX, which need to be integrated into a engineers to manage the process. Even if you already have DevOps solution. Thus, even if you manage to build a DevOps such employees on staff, asking them to oversee a DevOps solution that provides all of the functionality you require for project will distract them from performing the core Salesforce Salesforce today, the same might not hold true tomorrow. development work that powers your business. Time-to-use Technical debt The pressure to leverage DevOps is high, and Technical debt refers to time or resources that you waiting on software development and customization in waste repeatedly whenever performing a given task due to order to begin implementing a CI/CD pipeline can place your underlying problems that, if they were resolved, would free organization at a disadvantage. This is why building your you from having to incur this extra cost on a continual basis. own solution can be risky; it may take months, or even years, Building your own Salesforce DevOps solution leaves you before the solution is ready for production use. at risk of saddling yourself with technical debt. The solution will not likely be as efficient as one created by a team that specializes in this type of solution.