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.

Understanding Application Lifecycle Management (ALM)

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.

  • 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?

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.

  • 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.

  • 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.

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.