AppOps: The Next Generation of DevOps?
Remember the cellphone you had in 2014? How high tech did it feel? How smart was it? Did it make your previous phone look like something from a time capsule?
At the time, it’s likely that it felt cutting edge, and you couldn’t imagine anything better. It’s also why you most likely gave it a pass for lacking features that are standard today.
But compare that phone to the phone you have now. Is it still up to date? Is it still the best way for you to make calls, texts, watch TikTok, and all the other things a phone can do? Or is it missing some key features?
What about other innovations in tech? Are there technologies that didn’t make the improvements phones did in the last decade? Have we gotten used to some level of stagnation in our tech?
DevOps for Salesforce
About a decade ago, DevOps emerged as a potential way to manage Salesforce. DevOps apps attempted to bring the core concepts of DevOps — CI/CD, version control, automated code promotion — to the Salesforce platform. It promised to give developers the ability to manage Salesforce like software. Yet, it would still be years before DevOps tools would gain real traction with Salesforce customers because Salesforce is a “clicks, not code” platform primarily managed by admins not developers.
As we look through some of the key evaluation points of DevOps tools for Salesforce, it feels like things are a bit stale. In the years since the creation of the DevOps for Salesforce, is this the best we can do? Why are there still rigid configurations and bottlenecked developer-lead deployments? Why are admins, business analysts, and project managers excluded from the conversation because they don’t have the same level of experience with DevOps? Where is DevOps for 2021?
Low-Code DevOps for Salesforce
Salesforce gives anyone the ability to build powerful solutions with a couple of clicks, but these solutions are no good if you can’t get them into production. Unfortunately, with traditional DevOps solutions you can only complete Salesforce change requests as fast as your developer team can work, which creates a bottleneck in your release cycle. What’s more, wasting expensive developer hours on Salesforce configurations that could easily be made by less technical users if given the right tools and guardrails really adds up.
To unblock the release process and empower more people to innovate on the platform, we need to change how we think about DevOps for Salesforce. It’s time for a new set of rules:
1. Time to Value is Everything
Every industry is undergoing a digital transformation, and companies are rushing to meet changing customer expectations faster than their competitors. Like any new tool, implementation time is a large factor of success. Salesforce teams with growing backlogs cannot afford to waste months implementing a tool. They must be able to begin running deployments and tests within days, or even hours.
2. Easy Enough for Even an End User
DevOps makes it easier to manage Salesforce workflows. But code-heavy DevOps tools are complicated, and inaccessible to most Salesforce administrators let alone business users. It’s not realistic to expect non-developers to use a command-line interface or navigate a version control system. Instead DevOps tools should be designed with the least technical user in mind with an intuitive, point-and-click UI that enables the whole team to manage their workflows directly within Salesforce.
3. Must Work Out of the Box
Every customer tailors Salesforce to their unique needs and business processes. Just as you wouldn’t buy an eSignature tool that would require you to completely redesign your sales process, you shouldn’t have to upend your existing processes or make changes to your data schema to use a DevOps tool. Your DevOps solution should fit you, not the other way around.
4. Flexibility is the Key to Agility
The types of solutions built with Salesforce are endless, so rigid tools just won’t cut it. A DevOps tool needs to work for your process today, and as your team grows. As your process becomes more fine-tuned, so must your DevOps. Don’t settle for a tool that forces users to go through the same rigid and heavy-duty process regardless of the size or nature of the update. DevOps should work to deploy your changes how you want, not force you to use their rigid process every time.
5. It Has to Scale
Speed is the name of the game, and repetitive, manual tasks cost valuable time. What good is automating a process if it can’t be reused? Salesforce teams can save time by determining the data and metadata to deploy once and then reuse, copy, and tweak the template. And as you customize Salesforce with new apps and functionality, your DevOps tool must be smart enough to understand the underlying schema changes and keep everything in sync. Another note to consider as your team scales is that the easier it is for end-users to make changes, the more efficiently your DevOps can scale as well.
AppOps: Next Gen DevOps for Salesforce
No one is using a phone from 2014 anymore. So why settle for a DevOps tool from the past? Prodly AppOps is DevOps built for today. AppOps removes the rigidity and clunkiness of traditional DevOps solutions to help teams be more efficient and self-sustaining and support you as you grow. A low-code solution for managing Salesforce changes, AppOps is easy enough for even end users to use, but powerful enough for the most sophisticated developer needs. In exchange, your team gets more power to make Salesforce work harder for them.