Answering the question: "How long does it take to implement?" can be clarifying.
Sometimes we feel bad for Salesforce developers and admins looking to implement DevOps for their Salesforce implementation. First, there are so many options! Do I build something myself using Jenkins and Git and SalesforceDX? Do I look at one of the commercial tools on the market? Do I just stick with change sets? (Hint: the answer is no 😂)
Facing decision fatigue, what can help us cut through the noise? We’ve found one helpful question: how long does it take to implement?
Speed to successful implementation is a good proxy for how quickly you can show value and how streamlined and optimized the solution is for Salesforce.
At Blue Canvas we target getting a typical Salesforce team of admins and developers using Git and Salesforce DX in one day and using DevOps best practices like code reviews and CI/CD in little more than a week.
How? Blue Canvas is designed from the ground up to get Salesforce teams using best practices in as little time as possible. We’ve do this through a mix of technology, design, and training. Our opinionated platform allows you to accomplish the twin goals of DevOps and release management (faster deploys with fewer issues) without having to change a lot of things about your day-to-day flow.
Git lies at the heart of Blue Canvas. Your team will be using Git within the first few minutes of connecting to Blue Canvas. In our first meeting, we create a Git repo for customers and we connect sandboxes and production environments as branches in that repo. From this initial connection, we are automatically tracking changes in each environment and updating the Git repository. We even attribute changes to the user who made the change in Salesforce.
This frees admins from the time-consuming burden of having to learn what a Git commit is and remembering to do them. As changes happen, they automatically make their way into Git without manual (i.e. error prone and infrequent) intervention.
This allows us to make good on our promise of getting your team up and running with Git in a day. Even admins who don’t know what Git is can do their work with the safety of having real time backups for all changes. And release managers and product owners can get visibility into who is changing what with a smart, Git-based audit trail of changes.
Sandboxes have historically made branching in Git a challenge to Salesforce teams. That’s why we’ve built the simplest branching model possible.
Each environment is a branch, and “features” are managed as “pull requests” via cherry picking. When I have a bundle of changes that I want to push forward, I create a pull request. This is intuitive for admins and devs and removes the complexity of thinking in terms of complicated branches.
There is an inherent tradeoff here. You can certainly invent more complicated branching strategies for Salesforce. But in our experience working with hundreds of Salesforce teams, we find that most branching strategies are so complex that they don’t gain widespread adoption.
Because our branching mirrors the sandbox model of development, admins and devs can use pull requests and cherry picking through our Git UI with minimal paradigm shift. They can adopt a nice Git flow that feels similar to change sets from a branching perspective. This is why most teams are able to get up and running after a single training.
Converting to Salesforce DX involves a lot of time and tradeoffs. It’s much easier for a greenfield project, but even then you have complications. First, DX introduces a new “source driven” model built around scratch orgs rather than sandboxes. This necessitates learning traditional Git tools via the CLI. It also remove the sandbox as a fundamental aspect of the development process.
One of the core value props of Salesforce is the sandbox model. Salesforce provides developers and admins with a fully managed environment that handles dependencies, auth and execution of functions.
Still, DX is the future and we want to help users quickly transition to a modern stack while getting the performance upside of DX. Blue Canvas transparently and automatically converts your metadata format into the new DX standard. This makes your orgs future proof and provides some of the performance benefits of DX, without requiring your team to give it a second thought.
Accordingly, your team will be using DX after your first orgs are connected on Day 1 whether they know it or not!
Familiarity is important when learning new things. That’s why we’ve built our platform using the Lightning Design System. Anyone who has seen or used Blue Canvas will note how familiar it looks. This prevents the need for switching context or learning new design quirks. This again makes onboarding very quick, especially for admins.
Blue Canvas is not a self-service platform. Every customer receives a free onboarding call with a dedicated technical account manager.
We do this because technology and design are only part of a successful rollout of a new release management process. Yes we can make major gains by making the tool simple and intuitive as described above, but there is always a human element when you are introducing a new way of working.
We’ve been helping teams get started with DevOps for Salesforce since 2016. We have trained experts available to ensure your success, answer questions, and provide advice on best practices. All of our customers get a personalized onboarding in which we help you think through your goals and the steps to achieve them. Everyone starts their DevOps journey in a different place. Having training and advisory services built into the platform (at no additional cost) is the final piece in assuring a quick and successful implementation.
One feature we don’t have but have long waned to build is static code analysis. It would be so cool to generate report cards for your code and then prevent deployments that didn’t meet a certain grade, right?
But when we started doing research on this feature, we noticed a pattern. The teams that had static code analysis for their Salesforce teams didn’t really use it effectively. Often, they were working on legacy orgs with routine linting errors such as having the wrong letter-casing on their Apex code. Every deployment this would trigger dozens or hundreds of errors, which teams had no time to fix and would simply ignore to get their release out. The business was waiting after all! Accordingly, we decided that providing static code analysis would provide unnecessary clutter for the vast majority of Salesforce teams without providing significant value. Those that could truly benefit from static code analysis on their Apex could build their own tooling using SonarQube.
We’ve made these kinds of streamlining, opinionated decisions throughout the product to ensure we deliver value as soon as possible.
The value prop of Salesforce is pragmatism. It’s “clicks not code”. We believe that a DevOps and release management platform for Salesforce should be equally pragmatic. A good heuristic for that is asking the question: “how long it will take to implement?”
How long do I have to wait before I need before I see the results? How long before I get faster releases with fewer issues? Ideally, the answer is a day for smaller teams and a week or two max for larger teams.
The goal is to accomplish those goals with minimal overhead. Let your business move faster, more safely. And then stay out of the way.
.png)