Insights

A Sensible Approach To Technical Change Management: The Software Development Lifecycle

Welcome to Part 3(a) of our Ultimate Delivery Machine series. If you’ve missed our previous articles, we recommend reading Part 1 and Part 2.

If you’ve implemented the strategies in the previous sections, you’ve established a good governance framework that works for your organization and you’ve begun to craft the business backlog – the lists of ‘asks.’

It’s time to deliver! Following a thoughtful technical change management plan is how you do it.

What is Technical Change Management?

Technical change management is the application of best practices for designing, implementing, improving, and managing software solutions. At its core, technical change management includes the following processes:

  • Following a software development lifecycle
  • Managing changes through technical governance
  • Establishing a release approach and cadence

In this article, we discuss how to select and stick with a software development lifecycle that works for your Salesforce needs.

Following a Software Development Lifecycle

A Software Development Lifecycle (SDLC) defines the process of developing and testing a solution. It involves answering questions like Where will changes be developed? Where will changes be tested? How will changes be migrated and tracked?

Establishing an SDLC starts with a clear understanding of your current state. Take the time to document your current processes around managing change. What are some of the challenges you are facing? What is the complexity of your org and do you have the resources to support the change initiatives your implementation faces? A comprehensive understanding of your current state will allow you to identify areas to improve. That understanding will also help you avoid over-designing a process that is unrealistic to maintain.

After documenting your challenges, establishing an SDLC typically begins with defining a sandbox strategy. At a minimum, at least one sandbox should be provisioned for each phase in the development lifecycle. Each sandbox should be seeded with a recent copy of Salesforce production metadata, reflecting the most recent release.

Design and Development

Use a Developer or Developer Pro Sandbox

  • Refresh Interval – 1 Day
  • Storage – 200MB – 1GB

Integration Testing

Use a Developer Pro or a Partial Sandbox

  • Refresh Interval 1 to 5 days
  • Storage 1GB to 5GB

UAT Testing

Use a Partial Sandbox or a Full Copy Sandbox

  • Refresh Interval-  5 to 29 days (Full)
  • Storage – 5GB or Same as your production environment for full

Training

Use a Full Copy Sandbox

  • Refresh Interval – 29 Days
  • Storage – Same as your production environment

Your exact environment strategy will depend on the size of your org, the number of developers working in the environments and your release cadence. A longer list of deliverables with multiple initiatives and business processes will require more sandboxes, more testing, and more clearly defined processes. Salesforce Architect resources dives more in depth here. A helpful output is a flowchart or diagram that depicts how changes move through your environment. There are many tools to help build flow charts like the one below, such as LucidChart, Draw.io, or Visio.

salesforce sandbox

Sample Environment Diagram

In most cases, development is done in a developer sandbox, integration testing (testing the entire release) is done in a shared partial sandbox, and UAT is done in a full copy environment identical to production.

The key is adhering to a defined lifecycle process, relegating changes and activity to their respective environments. Substantial changes in functionality should always be done in a development sandbox. These can include schema changes like adding a custom object, or changes to automation using ProcessBuilder, Apex or other tools.

While we advise making all metadata changes in a developer sandbox and following the process each time, there may be a valid business, timing, or process reason not to do so. For example, a validation rule may be causing problems in production and need to be deactivated.

Besides the full sandbox, which is the same as Production, each sandbox has separate data and file storage limits.

When determining your sandbox strategy, refer to Salesforce documentation as some may not be available depending on your license.

Moving and Tracking Changes

The most time-consuming part of technical change management is the movement and tracking of changes. There are multiple ways to migrate changes between environments. They involve either using standard change sets, a third-party deployment or dev-ops tool, or managing changes in local environments and using tools such as VS Code and the Salesforce CLI (command line interface).

Change Sets

Salesforce’s out-of-the-box, declarative method to move metadata is through change sets. A change set is a grouping of custom metadata that can be moved between environments.

Outbound Change Set – A change set being sent from the source environment

Inbound Change Set – A change set being received and eventually deployed into the target environment

Building change sets allows you to use an easy, though limited, interface to identify and select metadata. You can also see dependencies based on the metadata selected. For example, if you choose a custom field on a custom object to deploy, the dependency will show the related custom object.

Keep in mind, change sets do not show you the differences between environments, nor do they contain a method to track what has changed. You’ll have to keep track of what has been changed in the dev sandbox in order to add it to an outbound change set. It is for this very reason that it is typical for the admin and/or developer to keep detailed notes (often in a spreadsheet) about the changes they’ve made in their development environment.

Be forewarned: change sets are notoriously slow. Not only is the process of locating and selecting the metadata to add to a change set time-consuming (due to limited list views), but the time required for an uploaded change set to surface in the target org is reminiscent of dial-up internet.

Third-Party Tools

Some third-party tools are like change sets on steroids. Tools like ClickDeploy and Gearset allow you to connect Salesforce orgs to other source-control repositories like GitHub. Those tools enable you to quickly build a collection of metadata, validate against the target org, run Apex tests, deploy, and more.

With these third-party tools, you can also see and compare differences between environments and schedule continuous integration jobs.

One of the most valuable aspects of using these tools is that they are markedly faster and more robust than standard change sets, while only moderately more complicated to use.

Metadata Deployments

Tools like the Salesforce extension for VS Code and the Salesforce CLI allow developers to use the Metadata API to retrieve metadata from a sandbox, make changes locally and deploy to a target org. In this method of deployment, the output is a collection of XML files containing metadata. 

Tracking Changes

With most deployment models, it’s up to the admin or developer to manually track changes they make. This can be done in a spreadsheet or a notepad-type tool. The admin or developer then must refer to their list and add their changes to their deployment as well as take note of any configuration changes they’ve made that may have to be done manually in the target system. You can find sample templates online that provide example deployment plans. These are typically step-by-step instructions that list the components and configuration changes needed to deploy from one environment to another.

Many teams choose to use a source control repository like GitHub to track and manage changes. Regardless of your team’s technical skill, it is important to include source control in your deployment strategy. Since this can be intimidating for newer admins, we recommend the Git and GitHub Basics module on Trailhead.

Take some time to consider how your team should approach the Software Development Lifecycle. The output should answer the following questions:

Sandbox Strategy

  • How many sandboxes should be provisioned?
  • Where will work be developed?
  • Where will the work be tested?
  • Where will UAT be performed?

Metadata Migration Process and Tools

  • What tools will you use to support your deployment approach?
  • How will changes be tracked?
  • Will you utilize source control?

It’s important to remember that you don’t have to take an all-or-nothing approach to any deployment strategy. It may be perfectly acceptable to use change sets for certain changes, and a more formal deployment methodology for others. Focus on defining your organization’s process and stick with it.

Author: Grant Ongstad, Senior Salesforce Consultant

Read more of the Ultimate Salesforce Delivery Machine series:

Part 1: The Backlog

Part 2: Governance

EightCloud has been an amazing partner to work with. They are really great about helping you maximize the functionality you are paying for before considering adding new features or other solutions. They are also great about helping us position and communicate the value of Salesforce and Pardot to leadership and have worked closely with us through multiple organizational shifts. Without EightCloud, I probably would have pulled all my hair out - they have helped us prioritize and execute our needs across our entire business."

- Ryan Redd, Envestnet MoneyGuide

Let us craft a custom solution that will meet your current and future Salesforce needs and make your life easier.

Insights

Rotate Your Device

Partners and friends, we are proud to share the new EightCloud brand and website with you. Our transformation reflects our commitment to helping you achieve Salesforce excellence through a focus on efficiency, expertise and genuine partnership.

We wish you the best and look forward to connecting with you soon!

Show me the new site!