3 Steps to Migrate from Salesforce Changesets for Better Application Lifecycle Management

Though Salesforce changesets offer an adequate, built-in way to deploy metadata changes from org to org, their limited functionality can prove challenging as development projects and teams scale up. If you are an admin or developer in a growing team, take a moment to look back at your recent project experiences. Do any of these situations sound familiar?

A day in the life of a dev team that relies on changesets

• Your team does much of its development and testing in just one or two sandboxes, making it hard to track which team member and what stage of the release process a given change belongs to.
• If your team does track this information about changes, it involves a good deal of manual, data-entry work that takes time away from valuable development tasks.
• In the absence of Salesforce source control, team members can unwittingly deploy conflicting changes or overwrite one another’s changes in cases of irreversible “code clobbering.”
• You frequently spend more time than you’d like on manually recreating inbound changesets for outbound deployment and waiting for changesets to upload to your target orgs.
• Your team makes it successfully through the release cycle, but you can’t shake the overall feeling of chaos that only seems to increase as additional team members come on board and the number of projects in your pipeline keeps growing.

If you answered in the affirmative to any of the above, you would do well to consider a toolchain that’s better than Salesforce changesets for the expanding needs of your team. In this article, we’ll look at the three migration steps that you can take to implement a solution that is faster, more cost-effective, and better than changesets at keeping up with scale, while still letting your less-technical admins create new features and apps using the declarative development tools that Salesforce is widely known for.

But before getting into the details of migration, let’s briefly recap the process of Application Lifecycle Management, which serves as the cornerstone for successfully deploying app releases at scale.

Understanding Application Lifecycle Management (ALM)

Source: trailhead.salesforce.com

To tame project chaos and add order and structure to complex release cycles, Salesforce encourages dev teams to adopt the framework of Application Lifecycle Management (ALM). The stages of ALM are:

1. Plan the Release:
Gather your customer’s requirements, create design specs, and set up the sandbox environments that you’ll need to complete the release.

2. Develop Changes:
Create your metadata customizations using Salesforce’s declarative and imperative development tools.

3. Test Changes:
Test and verify the functionality of each customization discretely, before integrating the change into the overall app.

4. Build Release:
Assemble all your customizations into the integrated bundle or app that represents the release you’ll be delivering to the customer.

5. Test Release:
Run full regression, performance, and user acceptance tests on the integrated release build.

6. Deploy Release:
Deploy the final, approved release package to your customer’s production environment.

Now that we’ve reviewed the basics of the release lifecycle, let’s take a closer look at how each step of the migration from changesets ties in with the ALM model.

Migration Step 1: Automate your audit trail with a development tracking tool

Instead of manually tracking your team’s customizations with unwieldy spreadsheets and email threads, use a dedicated project management tool like Atlassian Jira or Basecamp. These tools will help you get your list of project issues under control and give your team members a centralized platform for messaging, collaboration, and review.

For example, Jira software is designed to integrate nicely into an Agile scrum or Kanban workflow and lets you easily keep track of information such as:

• What stage of the AML process is a change currently at?
• Who is assigned to develop or test the change?
• Does the change have any dependencies or impact on other release components?
• Which sandbox currently contains the change, and when was this change implemented?

By maintaining the audit log for each change in a single place, your development tracking tool serves as the source of truth for your team’s project development tasks.

Migration Step 2: Use multiple sandboxes for your ALM

Sandbox environments provide an effective way for you to organize the logistics of your development workflow.

When your team was first starting out with one or two admins, you may have done just fine developing, testing, and compiling all your changes in a single Developer sandbox. Now that your team has grown, here are some best practices for you to optimize the tasks at each ALM stage using multiple sandboxes of differing types:

• Set up a separate Developer sandbox for each team member for the Develop Changes and Test Changes stages.
• For the Build Release stage, set up a shared Developer Pro sandbox to receive and integrate all the customizations from individual Developer sandboxes.
• Use a Full Sandbox, which contains a full replica of production data, to run your user acceptance tests (UAT) during the Test Release stage.
• During the Deploy Release stage, you can make your UAT sandbox available to your customer as a training environment. This Full Sandbox is a great way for your end-users to try out the new features on a copy of production data while the real data remains untouched in the production environment.

Migration Step 3: Incorporate source control into your development workflow

To manage the challenges faced by a growing team tasked with developing many features concurrently for a shared release, you can no longer rely on the cumbersome functionality and limited awareness of changesets. With so many team members working in and around shared Salesforce sandboxes, you need a true version control system to impose order on your many streams of development.

A source control system like GitHub or GitLab serves as your team’s single source of truth for metadata code and gives you the ability to:

• Maintain the master code for your release in a single repository that can be accessed by any team member from any location.
• Create feature branches that allow individual team members to work on customizations without impacting the master code during the Develop Changes and Test Changes stages.
• Check for conflicts between new and existing changes.
• Merge approved features branches with the master for integration at the Build Release, Test Release, and Deploy Release stages.

Now that you’ve put in place the three best practices for migrating to a toolchain that’s better than changesets, you need one last thing: a deployment tool that pulls these best practices together into a single streamlined solution.

ClickDeploy vs changesets

ClickDeploy.io is an intuitive, easy-to-use DevOps tool that lets you implement your Salesforce release process ten times faster than with Salesforce changesets. Headquartered in Sydney, Australia, ClickDeploy is a fast-growing Salesforce App Exchange Partner that is trusted by thousands of companies around the world.

To see why top development teams are choosing ClickDeploy to deliver their releases at scale with lightning speed, use your Salesforce login to sign up for a three-week trial. Since ClickDeploy is secure and 100% cloud-based, you can safely try it out for free without installing anything on your existing orgs.