Support Collaboration with Continuous Integration

Learning Objectives

After completing this unit, you’ll be able to:

• Define continuous integration.
  
• Explain how to select continuous integration tools.
  
• Explain how to synchronize sandboxes using back-promotions.
  

Continuous Integration

We know that with physical work, such as building construction, there are activities that can’t be done in the same area at the same time. With software development, however, many developers—even many teams—can work in parallel on overlapping functionality. This helps make the most efficient use of everyone’s time, since teams don’t have to wait for each other. Version control makes simultaneous work easier, since work can be done in branches and, in many cases, merged automatically.

Be careful when you merge, though. The longer you go without merging, or integrating, the harder the integrations become, because you run the risk of breaking other people’s changes. You can check for conflicts manually, but this adds time and might not add much value.

How can you save time by working in parallel branches without risking complex and tedious integrations? Integrate early and integrate often, and build good automated tests into your process. This practice is known as continuous integration. The State of DevOps Report found that continuous integration improves team performance.

Each time you merge, you can run automated unit tests to make sure nothing has broken. If a test fails, the team should fix that broken test before continuing to develop. Tools that automate processes like running tests when code is merged are sometimes called continuous integration (CI) tools, but don’t confuse the use of these tools with the actual practice of CI.

If you use the package development model and work with scratch orgs, you can practice continuous integration by collaborating on a common trunk in version control. Learn about that practice in the Continuous Innovation with Copado module.

The next section explains continuous integration in the org development model.

Adopting CI Tools

Anitha and Praveen are struggling to resolve a tricky bug. Praveen was refactoring the code, and sometime over the last 2 weeks, he broke functionality in an app that Anitha had built. Luckily, they have version control, but it’s still hard to unravel the logic that’s causing this issue.

If this bug had appeared in production, they would have noticed it right away, since support agents use this process daily. But in development, there’s no feedback when something breaks.

Anitha realizes that continuous integration tools can help. When the code changes, the CI tool can rerun unit tests and alert them to a problem fast.

There are many general-purpose CI tools that can automate processes for almost any type of code or platform. The main function of these versatile tools is to trigger jobs and track their status.

Usually the jobs are custom scripts, so if you can write a script for something, you can run it in a CI tool. Scripts can run tests, compile code, build packages, do deployments, and more.

You can get started with some popular CI tools by checking out the Salesforce DX Developer Guide, which provides simple examples that might work for small teams. But your complexity and requirements will grow over time.

Writing scripts to manage your development lifecycle is a significant project, like building a custom application. Fortunately, there are tools like Copado, built specifically to enable continuous integration on Salesforce.

Joan’s team wants a tool that’s easy for admins, testers, and managers to use, collaborate on, and customize. The team’s core competency is building on Salesforce, not maintaining custom scripts, so they decide to use Copado for continuous integration to minimize their total cost of ownership.  

Copado is an enterprise-class DevOps platform that integrates with external tools but can be customized as easily as Salesforce. This choice gives them confidence the tool will support their present and future needs, so their team can focus on supporting the business.

Continuous Integration Between Sandboxes

One of the admins, Scott, tells Joan that his work has been overwritten by someone working in the same sandbox. He planned to track his work in version control, but they overwrote his work before he had a chance.

When Joan asks why Scott uses a shared sandbox, he explains that working in separate sandboxes makes it hard to collaborate. Sandboxes get out of sync, and synchronizing and refreshing them takes time. Yet working in the same sandbox exposes the team to unpredictable changes. It seems like there’s no good option.

Joan asks Tony, the release manager, why synchronizing developer sandboxes takes so long. Tony explains that creating scripts to automate the process is complex and risks overwriting developers’ work.

Joan learns about back-promotions, a capability of Copado that automatically migrates work between developer sandboxes. They create a shared integration sandbox, and when developers finish their user stories, the release manager automatically deploys the related metadata to the integration environment.

From the integration environment, they schedule or automate back-promotion of user stories to other developer environments. They can take developers’ time zones into account, and developers can trigger back-promotions to their orgs manually if they want to.

Automating back-promotions allows the team to practice continuous integration. They make sure changes are synchronized daily between different developers and across different teams.

Back-Promoting Changes from Production

Anitha comes to Joan to report another issue. She spent a week working on a piece of functionality, but as soon as it was deployed to production, she discovered the fields she relied on had been redefined.

Several months ago, one of the support managers made urgent changes to these fields directly in production. But Anitha’s developer sandbox wasn’t refreshed, so she didn't have the latest changes.

Joan's team has been asking the business not to make changes directly in production, but sometimes urgent priorities override that request. And the business team isn’t familiar with following a development process, so they keep making changes in production.

The team refreshes all developer sandboxes every quarter, but developers have to pause work during the refresh and perform manual setup steps.

Ideally, no one would make changes directly in production. But Joan knows it’s hard to prevent right now.

The team realizes that they can capture production changes as user stories after the fact, and use back-promotion to move them to development environments.

If the support manager can configure Salesforce, they can use Copado. Any emergency changes are logged as a user story, and back-promoting the story ensures all environments stay in sync.

Using version control is good, but it’s the practice of continuous integration that brings version control to life. The ability of developers and teams to temporarily work in parallel while regularly synchronizing their work unlocks the opportunity for enormous creativity without enormous cost. Tools that orchestrate continuous integration provide the platform for all further automation. Using a tool like Copado, designed specifically for Salesforce DevOps, brings substantial return on investment.

Resources

• Trailhead: Unit Testing on the Lightning Platform
  
• Salesforce DX Developer Guide: Continuous Integration
  
• External Site: Learn more about DevOps with Copado
  
• External Site: Trunk-Based Development