Let Innovation Flow with Continuous Delivery
Learning Objectives
After completing this unit, you’ll be able to:
- Define continuous delivery.
- Set up your delivery pipeline to guide the flow of changes.
- Automate the flow of changes to every org in your pipeline.
Continuous Delivery
When organizations first start building on Salesforce, teams often make changes directly in production. Salesforce is a robust and flexible platform, and you can make changes quickly and easily. But you have to make every change carefully. You’re not going to break Salesforce, but you can definitely break your own customizations.
To reduce risk, you have to strictly limit which changes are made directly in production. Build features in development environments, move them to a test environment for review, and only then move them to production.
This is the safe way to work, but it can be slow. If deployments are difficult and time consuming, your team won’t do them more often than they have to. They may wait until the end of the week, month, or quarter to deploy, further delaying the delivery of features.
Continuous delivery (CD) builds on top of continuous integration. While continuous integration focuses on sharing work frequently across development teams, continuous delivery focuses on sharing work frequently with end users. Just as CI systems trigger automated tests to revalidate code every time it’s updated, CD systems also automate deployments every time the code or config is updated.
In the words of Jez Humble, co-author of Continuous Delivery, “Continuous delivery is the ability to get changes of all types... into production safely and quickly in a sustainable way.”
Just as automated tests help identify flaws in logic, automated deployments quickly reveal deployment errors, such as those caused by missing metadata. When you deploy infrequently, you make larger deployments, with more metadata and more complexity. Large deployments can require dozens of attempts, each taking many minutes or hours. When you change hundreds or thousands of components at once, you risk breaking your customizations, and failures are harder to debug.
You can automate deployments all the way to production every time code and configuration change in version control. But unless you have great confidence in the automated tests you run along the way, you should configure continuous delivery to automate the flow of changes to testing environments, but pause for manual testing and approval before finally deploying to production.
Your continuous integration tests should take just a few minutes to complete. Ideally, these tests focus on the most critical or brittle subset of logic. You want these tests to run quickly so you don’t slow developers who are synchronizing their development orgs down. During continuous delivery, however, you run a more comprehensive set of automated tests to increase confidence in the validity of each change.
Being a SaaS platform gives Salesforce advantages in the practice of continuous delivery. Salesforce maintains the underlying systems and validates every deployment, which helps you avoid breaking changes. Many changes require only small configuration updates, so you can make small batch deployments. Some metadata types may be safe enough to bypass tests and approvals.
But as the complexity of your org grows, it gets harder to make small, safe deployments. Establishing clear, long-lasting boundaries between the metadata maintained by different teams can help you keep deployments small and safe. The package development model is the most promising way to do this. We talk more about package development and modular architecture in the Continuous Innovation with Copado module.
The next section explains how to practice CD using the org development model.
Creating a Delivery Pipeline
Tony, the release manager, begins onboarding a new developer, Tam, to help automate and improve the team’s delivery process. Tony wants a complete picture of all the different environments so he can build a continuous delivery workflow for the team.
He knows all the sandboxes, but he doesn’t have a way to visualize how various teams’ work flows through these environments into production.
Tony decides to set up a delivery pipeline using Copado. Copado provides a pipeline setup wizard that lets him authorize connections to his development, testing, and production orgs. The pipeline shows each org, and guides how changes flow through the various orgs in the development process.
That visualization shows how changes from the support team are merged with changes from other teams into an integration environment before being sent for testing. Creating a pipeline that flows from development to production is called “building a walking skeleton,” and is the first step in configuring continuous delivery.
Automating Deployments
The team is now comfortable tracking their metadata in version control and tying that metadata to user stories: the foundation they need to start moving toward continuous delivery.
Right now, they do time-consuming monthly releases. One of the main complaints from the support department is how long it takes to get work from the development team. But they also complain that almost every deployment causes something to break.
Because monthly deployments are so large, when something breaks it’s difficult to determine which component caused the failure. Each failure becomes a small research project, and it takes several hours to roll back the change.
The testing team doesn’t like how long it takes to move work from development to testing orgs. They sometimes spend days waiting for work to test. These delays create pressure to complete testing as quickly as possible, and the team often works nights and weekends.
The team uses change sets, and Tony uses the Salesforce CLI from his laptop to deploy. That gets the job done, but he does a lot of manual work to identify metadata for each release. His own workload is inconsistent, and he often works through evenings and weekends to support big deployments.
Tony likes the saying, “Slow is smooth, smooth is fast,” which reminds him of the Lean principle of seeking flow. Sometimes slowing down and having a smoother process makes the overall process faster.
Tony begins using Copado to deploy metadata changes to the testing org automatically when the associated user story is marked complete. Deployments to the testing environment get smaller and more frequent, so testers don’t have to wait for updates.
Automating deployments to testing means most stories are deployed without delay or intervention. Tony simply monitors the pipeline and assists if a deployment error occurs. Copado updates the user story status automatically, so the flow of work is visible to the business.
Adopting continuous delivery means testing and production environments will change more frequently. Tony knows this will increase the likelihood of failures unless the team also improves their automated testing.
He identifies some metadata like fields and layouts that change frequently but rarely break anything. The team decides it’s OK for user stories with only those changes to deploy automatically to the testing and staging environments, without requiring tests or approvals.
He then begins segmenting other metadata based on type and name, setting different testing and approval rules for each. Copado continuous delivery lets him automatically run different tests and approvals depending on the metadata in each user story.
Copado uses a sophisticated Git branching technique that treats each user story as a feature branch. These branches are dynamically merged and managed, so each user story can be deployed independently across the different orgs.
Tony and his team decide to automatically deploy small, safe changes to production, without review. If there are deployment errors, developers get an alert. With less work requiring approval, Tony can focus more on training and enablement, since he doesn’t have to release every story himself.
Testers can start testing sooner, be more thorough, and get feedback to the developers before the end of the sprint.
Making Your Environments Consistent
Joan learns about another small crisis. The latest deployment introduced a bug. Tony has been up all night trying to help the team recover, and rolling back the change takes hours.
Joan gets in touch with Simone, the QA lead, to find out how the failure got into production. Did the QA team test that scenario?
Simone explains that they did test this scenario in every testing org but didn’t encounter the problem.
During their post-mortem meeting, the team determines that a tiny bug in a validation rule caused the failure. The rule had been created directly in production but hadn’t been deployed to testing or development environments.
Tony explains that not only are testing environments out of sync with production, the testing and development environments aren’t in sync with one another. It’s still quite a mess.
Because developers and admins don’t always know what metadata to include with their changes, they often log in to the testing and production environments to complete changes manually.
With so many manual changes, environments that are supposed to be identical gradually drift out of sync, increasing risk.
Since Copado can deploy almost every type of metadata, and even deploy data used as configuration, Tony realizes that the problem here is a lack of training.
The team decides to require every change to go through the delivery pipeline—no more manual changes. They make sure everyone is using Copado, and they begin a chat group where the team helps each other with deployment and metadata issues.
After the team is comfortable with the process, they take the final step: Tony revokes the team’s admin privileges in testing orgs. He’s not trying to inhibit their ability to make changes; he wants to ensure that changes are tracked and made consistently.
It’s All About Flow
In this module, you learned about the main challenges you experience in the Salesforce org development model, and how to use DevOps principles to address them. The First Way of DevOps is to enable the flow of innovation from development to production. The practice of continuous delivery—getting changes into production easily, quickly, and sustainably—helps you achieve this flow.
The greater your flow of innovation to production, the more important feedback and continuous improvement become. To learn more about these DevOps practices, and how to move to the package development model and automated testing, check out the Continuous Innovation with Copado module.
Resources