Decouple releases from deployments
What if you could release a feature to different groups of users without deployments? Is there a way to effectively test features in production and immediately roll them back if needed? Is there a way to deploy a half-developed feature in a hidden way, so that it will become visible only when it’s done?
I answer all those questions with Feature Flags. Sometimes also called Feature Toggle or simply Switches. Feature Flags are conditions that encompass feature code that allow you to flip them on and off at will.
They provide many benefits as:
- Separate deployments from releases.
- Mitigate deployment risks.
- Testing in production (yes, the last and necessary round).
- Manage access to specific users on beta releases (specially on Salesforce communities).
- Dark launches: features that won’t be used in production until they are finished and working properly.
- Canary release: release a feature for just a few users to test it in prod.
You can even sell this idea to marketing for A/B experiments on Partner Communities or Customer communities.
Let’s say there’s a financial company where the requirement is creating a LWC to show the accounts credit scoring. The scope includes to list a few fields and show a bar chart comparing the client score and the media score for that industry. But off course, it can’t be done in just one Sprint (usually 2 or 3 weeks), because it needs to query a webservice to get the MediaScore … So we can approach this with a layered solution.
- First, we can deploy the MVP (minimal valuable product) which includes the LWC and a few fields.
- Second, we can deploy whatever we finished on the chart part.
- And third, we can modify the chart to show the queried media score (on this topic, I created and deployed in a free host, a tiny webservice made in Rust that returns the media score per industry)
This example illustrates the use of Feature Flags. You can read on code (accountDetails LWC, scoreChart LWC, ScoreChartController and ScoreChartControllerTest apex classes) how the author implemented the project. In the README file you can find more information.
Of course, everything comes always with a price… In this case, the price to keep all your CoE in sync with the same Feature Flags library, educating the DevOps admins, the developers and the product owners on the FF mindset. Also, to wisely remove the FF when their mission is accomplished, because it could become a management hell. In short, FF also have a lifecycle and it needs management.
What is DevOps?
DevOps has become a trending topic in the tech industry many years ago. Developers, C-managers, QA and Agile specialists kept an ongoing discussion about how to accelerate the software time-to-market while keeping the software quality and stability, as a condition for surviving the actual business velocity.
This discussion is a result of a process of Continuous Improvement (CI), inspired by the Japanese process of kaizen. The idea behind this, is that you can begin now, adopt a discipline of CI, while you get fun innovating and experimenting. This CI should not be confused with CI of Continuous Integration, also strongly connected with DevOps as well.
DevOps is a term that brings together the terms “Dev” (stands for Development) and “Ops” (Operations), as a way that embraces the collaboration between those teams in a corporate IT environment.
The end goal for Devs include fast bug fixing and creating new features., whereas for their “Ops” counterparts, might be to maintain stability on the system, along with close-to-continuous server uptimes. These goals can often be in conflict with each other, leading to inefficiencies and finger-pointing when things start to go wrong.
Then, DevOps comes to rescue, making both teams accountable for facilitating innovation while still ensuring stability; building a culture of collaboration, better communication and automation. As a consequence of it, by extension, it involves collaboration with QA teams, security teams, business owners and subject-matter experts for the benefit of all. Here is where CI (Continuous Integration) comes into picture, for integrating changes from different developers in an automated way, detecting breaking changes and merging/solving them earlier in the deployment process.
The foundation for implementing DevOps (and continuous delivery concepts) is the use of version control. VC is a mechanism to track changes in text files and merge changes smoothly. DevOps is based on the practice of continuous delivery which maximizes the throughput of valuable software and the stability of the systems at the same time. The mantra here is “move fast and don’t break anything!“, ensuring better time-to-market.
In short, the benefits …
- Shorter development cycles and faster innovation.
- Reduced deployment failures, rollbacks and time to recover.
- Improved communication and collaboration
- Increased efficiency.
Why do we need it in Salesforce?
Creating customizations in Salesforce is really fun and straightforward, and there is amazingly array of learning sources available on Internet. Salesforce itself has an incredible help, Trailhead is in my opinion the best interactive platform for learning Salesforce and related topics from the theoretical and practical standpoints, there are thousands of presentations from Salesforce and their community groups all over the world, not to mention the wealth of books, tweets, blogs, StackExchange posts to educate yourself or to untagle complex problems.
No matter if you create them using point-and-click or coding, everything in Salesforce is described, behind the scenes (meaning, behind the front-end) as metadata components. They are files that can be retrieved from the server and usually are largely stored XML, although some are code, and some new types are JSON. Because of this, that metadata representation of your Salesforce Org, can be stored, tracked, updated and deployed onto a version control system (Git, Gitlab, GitHub, Bitbucket and so on). And even better, they are the basis for automated processes such as static analysis and automated deployments.
How to implement it?
Before implementing DevOps tools and connect them to your Salesforce orgs, it’s important to have a Release Management Plan. As someone wise said “who fails planning, is planning to fail”, so first things first.
In continuous delivery, release management remains the critical connector between development and production. Release management verifies the integrity of code and makes sure that it functions as planned. It is done through peer reviews, static code analysis and automated/manual testing. Agile methods break down silos often seen with waterfall methodologies, but Agile requires thorough documentation, so processes are clear.
But, what are the steps to build a Release Management Plan?
- First, you must start with the “Why”. Why are we implementing this on our Salesforce environment? What do we try to enhance/fix? Are we creating new apps/features in our Salesforce orgs? for internal or external customers? in a shape of an AppExchange app or only for internal use / partners use?
- Second, you should sketch out a plan (the “who” and “when”): on this step, you should define the team: (who’s going to design, deploy, test and deploy and on which environments). Do we have a roadmap (“how”)?
- Third, once you defined the why, the who and the when, it’s time to think in the what. Once you have high-level agreement on your plans, you have to make it actionable. This means writing product requirements for your development team to work from. Writing requirement is not the main focus here, so the main thing is including requirements as part of the overall release planning so developers can easily reference them. Once the product requirements are done, you map them to user stories (assuming you’ll use scrum or some other Agile methodology). You may use Jira or some other tool for that.
- Fourth, you should create a branching and a sandbox strategy. Branch is a term used in version control jargon and means “pots” where you store a specific version. You can add in the mix, if your team is mature enough, scratch orgs and 2nd generation packages (like unlocked packages) as well. Then, connect the orgs with the VC, so that every time your developers finish some work, they can “push” the work to some branch and (maybe depending on the branch) fire some CI processes in your selected tool (see below). Don’t forget previously to set a backup tool to keep your org safe !!
There are many custom tools/suite of tools that can help on this, native or custom built (more on that hereafter).
One more thing … many things related to configuration management needs to be considered as per application itself. For instance, Salesforce CPQ or Industry Cloud stores their configurations in a specific way and would be interesting to consider how to store it on your VC tool as well. Some providers considered it on their offering.
Native
- Salesforce DevOps Center: recently added to the release management tools in Salesforce, this introduces best practices to the entire community, regardless of where you fall on the low-code or pro-code spectrum.
- Flosum: this provider offers a wide range of solutions, from Salesforce DevOps to backup, migration and security framework.
- Copado: This provider offers a wide range of solutions, that meets every stage on the software lifecycle management, covering DevOps, Release Management, Testing & QA, and so on.
- Gearset: This provider offers deployment tools, DevOps, Test Data Management and Backup. It also provides solutions for specific clouds like Revenue Cloud and Industries.
Custom Built
- Jenkins: This app started as an Apache Foundation Open Source project. Is written in Java and is “de facto” tool for DevOps in many stacks and companies. In this article you can find how to configure the CI of Jenkins to create CD pipeline for Salesforce.
- CumulusCI: CumulusCI helps build great applications on the Salesforce platform by automating org setup, testing, and deployment for everyone — from developers and admins to testers and product managers. There is an outstanding Trail in Trailhead for CumulusCI that deserves some attention.
- Azure DevOps. You can use this Zapier addon to send info between Azure DevOps and Salesforce with no code, or you can follow this recipe.
- Gitlab Pipelines. This tool is the standard choice from Salesforce to integrate on their DevOps center, so you can check this Trailhead module on Building Automated CI/CD Pipeline with GitLab.
- GitHub Actions. On this outstanding article you can find how to set up gitHub actions for creating pipelines for Salesforce.
- AutoRABIT: This is another provider who offers an extensive set of tools for ARM (Automated Release Management), Vault (backups) and CodeScan (static Code analysis and many more related topics).
- SFDX-hardis by Cloudity: this is an open source and free CLI tool for defining a complete CI/CD pipeline for your Salesforce project/s. This option is for people who has time and enjoy defining the process (and a restricted pocket maybe?).
What about SecDevOps?
Nowadays is pretty straightforward to implement security on your release management plan. If you opt for a turn-key solution, it doesn’t need to be considered appart: many of them ask for certificates and need to set up during initial configurations. If you have a passion for mechanics and want to make your own adjustments, that’s a different thing but then I suggest you to look for some specific articles related to encryption, hashing and so on.
Summary
The article is not intended to be an informative compendium, just introductory material to the Salesforce-oriented discipline of DevOps.
We could say DevOps is a set of process and a culture that brings together development and operations to complete and enhance software development and deployment.
It consists primarily (in Salesforce) in a creation of a Release Management Plan, which contemplates Continuous Integration (how to merge code from minor environments with Production/Master Branch at regular intervals), Continuous Delivery (CD) (CI plus simple automatic release creation) and Continuous Deployment (CI plus CD plus production deployment). Also consists on the definition of why we do this, which teams will be responsible for what, and when they will do that.
Finally, we listed some useful tools and providers that can help on this process, with well-tested applications on the Salesforce ecosystem.
Recommended Readings
- Mastering Salesforce DevOps: A Practical Guide to Building Trust While Delivering Innovation by Andrew Davis
- Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren, Jez Humble, Gene Kim
- The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
by Gene Kim, Kevin Behr - Gitlab + Salesforce: DevOps Made Easy.
- Package Development Model in Trailhead.