Elevating your Salesforce DevOps in 2021
Do you have a process in place for improving and expanding your Salesforce instance? Is leadership properly investing in Salesforce DevOps? It’s amazing what your team can accomplish when you receive buy-in, implement effective processes, and create alignment across the company. Our panel of DevOps leaders comprised of Salesforce Solution Architect at BigCommerce, Ezra Kenigsberg, Director, Digital Transformation at PTC, Brian Wainwright, Senior VP of Technology at OpFocus, MJ Kahn, and Director of Salesforce Development at OpFocus, Jason Curry discussed the impact Salesforce DevOps can have on growth. It’s time to set your users up for success in 2021!
what is DevOps?
Let’s set the stage by defining what we mean when we say Salesforce DevOps. For our purposes, DevOps is the set of processes and tools an organization uses to build and deliver solutions; both on the Salesforce platform and in the greater operations ecosystem. It’s not just about development, but about the realization that every change you make impacts the system as a whole. For this reason, every change needs to be made with forethought and consideration about whether it’s good for the organization. DevOps is a journey, not a destination.
risks and benefits
Part of the DevOps journey is having the right mindset. Your stakeholders may not understand the technical methods you use to make improvements to the system, but they do need to endorse the functionality you’re building. Brian elaborates, “What’s self-evident to you as a technologist may not be self-evident to everyone.” Instead, consider how you’re delivering value to the organization by enabling features to end-users.
Ezra adds that “DevOps is an art, not a science.” He uses the “fail fast” mindset which prompts your team to be proactive about change. By constantly improving DevOps processes, you’ll provide value to both the end-users and the organization as a whole. This approach creates a DevOps process that’s unique to your team. Two companies that look similar on the surface may require different approaches.
MJ mentions that although processes will be unique to your organization, there’s a basic tenant that applies to all companies “think before moving forward.” Rather than have a large number of System Administrators who can make arbitrary changes in Production at will, limit System Administrator powers to a small set of people you trust to follow your processes. These processes should include, thinking before acting, triaging requests rather than simply acting on them, and testing changes to confirm they have the desired result(s).
why do teams need Salesforce DevOps?
As an enterprise platform, Salesforce holds mission-critical information about your customers. For this reason, it’s crucial you take steps to ensure the stability and integrity of your system and your data. As you change and customize Salesforce, it’s important to ensure every change works properly and doesn’t break anything. Proper DevOps ensures there’s a process in place to test, evaluate, and implement changes with consideration for all parts of the platform.
getting started with DevOps
How large does your team need to be before you can implement DevOps? Not large at all. Even if you only have one part-time system administrator, you will benefit from having processes and tools in place to control how functionality is built and deployed. Start the DevOps process immediately, then improve it as you go.
Below you can find Ezra Kenigsberg’s 7 Salesforce Commandments he suggests every DevOps user adheres to. Commandments 2-7 are all principles you can apply when thinking about how your DevOps process works.
Although these commandments provide a solid starting point, MJ has an idea for commandment 8; “Thou shall document your work.” You’re likely not the only person that will work in your Salesforce instance and proper documentation is helpful to others. Ezra disagrees, stating that IT departments move quickly, and creating documentation is a low priority. Instead, he prefers to use Jira for ticketing. Jira tracks interactions and design ideas automatically. “That serves as very good documentation to refer to.” Brians team uses Capado which he loves since it bundles up user stories that he can reference later. Regardless, your DevOps should enable end-users to use Salesforce effectively. If they can’t, you aren’t providing value.
When should you start using tools as part of your DevOps process? If you are using sandboxes and Change Sets, you’re already using tools! As your organization’s needs grow and change, you may need to move to more advanced tools. Once your team feels the technology you use is no longer meeting your needs, it’s time to discuss a change. Ezra’s team uses GitHub as well as GearSet, both of which he recommends.
Receiving buy-in is another problem teams face when getting started with DevOps. MJ suggests documenting issues you encounter because you don’t have a solid DevOps process or toolset. Then start to gather metrics about these issues like the amount of system downtime or the amount of work that’s lost. Build a list of best practices and requirements your team members need to confirm before going to production. Then create limits to what can be done without this approval. Eventually, this list will transform into a formal DevOps process.
how can I convince my team to adopt a more formal process?
What Brian loves and hates about Salesforce is how accessible it is to users. “Somebody with a little bit of knowledge can be very dangerous in the platform.” He suggests asking yourself, “does your team want to spend all day fixing problems or would they rather be making meaningful changes for your users?” Before blindly making changes because a request came in, take a step back and consider what the outcomes might be. Remember to standardize the process so everyone’s on the same page.
Ezra, recommends setting up a ticketing system. Collect requests, then put them into organized packets that you can start addressing. Then work with business leaders to identify how to prioritize these requests. Building out a system for ticketing requests, breaking down requirements, and prioritizing them are the first steps in creating a more structured process.
how to help your organization mind-shift from giving orders and solution design to thinking about the Salesforce team as a trusted solution partner?
Brian stresses “you have to have someone responsible for understanding the needs of the business and the outcomes they are trying to achieve, and that’s an objective voice to make the decision on what should be prioritized.” It’s difficult to align people when there are many opinions, having a dedicated decision maker eliminates this concern. He notes there’s a general move taking place towards companies creating product teams that support particular capabilities in the organization rather than Salesforce Admins being responsible for everything.
Ezra’s top tip is to ask questions. “When someone comes to you and says we need to do something, ask why.” MJ has the same advice, she personally uses the “5 Why’s” technique. This helps her dig deeper into the root cause of a request. Once this is identified, she can solve the problem more effectively. This technique also trains your team to expect these questions and gets them thinking about root causes ahead of time. As a result, your internal customers will think of you more as a strategic partner than an order taker.
what are products you use now, wish you had, and would never touch?
Ezra’s team uses Jira, GitHub, and GearSet which he’s been impressed with thus far. He’s also looking at Spekit which delivers documentation in a more visually appealing manner. Brian also uses Jira and GitHub, as well as Copado and Selenium. MJ suggests investigating a platform called Elements Cloud. Products that are right for one organization may not be right for another. Your DevOps team will find its own combination of tools that maximize your specific workflow.
conclusion
Salesforce DevOps has a ton of value and elevates how your team operates. When you get the buy-in from stakeholders, create a process that works for your team, and align your team, there’s no limit to what you can do. Looking to standardize your processes and develop maturity in deployment? Reach out to someone at OpFocus for best practices and elevate your internal operations!
