The Release Lifecycle and Managing Changes Through Technical Governance

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

If you plan to deliver consistent and value-adding enhancements to your Salesforce environment, you need to establish a framework for managing technical change.

Utilizing technical governance allows changes to be managed with thoughtful processes in place that increase the likelihood of success. If you’re part of a team responsible for making lasting and positive changes to your Salesforce organization – this post is for you.

What is Technical Governance?

In a previous post in this series, we went into depth about what I’ll call “Big G” Governance – meaning the process of establishing a vision, deciding on a model to manage organizational change, and maintaining that structure to support thoughtful change over time.

In this post we talk specifically about technical governance, a component of technical change management, which is the process of managing the actual system changes from release to release and ensuring changes are properly documented, developed, and tested according to defined processes and standards. Establishing and following a technical governance process involves:

• Defining a release process
• Assigning roles and responsibilities
• Applying standards

Defining a Release Process

Document Current Release Processes

Your first goal should be to get clear on your existing release process. As with any other process improvement, first document what is, or in other words, your current state. How are changes currently managed and moved through environments? Is there a common set of steps that are followed every time? Which environment(s) are used for testing? What types of testing (e.g., integrations)? Which team or person deploys changes?

If the current process is not documented well (or at all), this exercise will help identify gaps as we go through what should make-up an end-to-end release process.

Establish a New Release Cycle

The release cycle defines the stages of development from initial planning to eventual release into your Production org. Usually this is best represented as a cyclical-type of diagram. In our last post, we developed a Sandbox strategy. Think about the sandbox strategy in parallel with the release cycle.

The following diagram marries the sandbox strategy with a release cycle:

After you’ve defined each step in the release cycle, break down the steps involved in each of them. The result can be a checklist for each phase that instructs team members on what must be done to move an enhancement, such as piece of new functionality, to the next stage.

Definition of Start

When do you start the work on an enhancement or new feature? A Definition of Start defines exactly that. Just because something is requested does not mean you are ready to commit the necessary resources. A Definition of Start makes sure that the release team has everything they need to ensure a change is scoped well and delivered thoughtfully. Below is an example Definition of Start. Each of these steps needs to be completed before the team starts work.

1. Requestor has documented a clear business use case (Output: Documented use case)

1. Business analysis has been performed and requirements document created (Output: User story and requirements documented)
2. Work does not overlap with existing work
3. Definition of ‘Done’ has been defined
4. Work has been estimated (Output: Level of Effort, or LOE)
5. Governance team has signed off (Output: Signed and/or documented approval to build out the requested functionality)

Definition of Done

You’ll notice that the Definition of Start includes the Definition of Done (i.e., acceptance criteria). This is no coincidence. When a Definition of Done is missing, disagreements on scope often arise between the build/development team and the business team(s). Even seemingly simple enhancements can lead to hours of unnecessary back and forth.

The Definition of Done is collaboratively defined by both the build/development team and business users. The business wants to make sure the functionality meets their specific business need, and the build/development team wants to ensure that the change is technically sound and fits within the existing org structure. The release manager (often within the build/development team) may want to verify that the build work went through the appropriate approval processes prior to deployment.

Let’s look at an example Definition of Done:

Business Definition of Done

• When a sales manager closes an opportunity, an email is sent to the sales team, notifying them that an opportunity has been closed. This email includes a link to the opportunity in question.

Implementation Team Definition of Done

• When an opportunity is edited to Closed/Won, an email is automatically sent from the Opportunity Closed Record Trigger Flow. The flow should successfully identify all team members of an opportunity and an email should be sent to each member. If no team members are listed, an email is only sent to the one who initiated the process.
• When regression testing is successfully performed, there are no negative impacts to existing functionality.

Release Manager Definition of Done

• When the business has reviewed and officially signed off on the implementation.
• When an end user has tested and validated functionality meets business needs.

The takeaway is that the Definition of Done is established through collaboration with other parties with different vested interests in order to set clear expectations.

Assigning Roles and Responsibilities

The release team is responsible for reviewing, analyzing, prioritizing, and ultimately delivering changes with minimal production disruption. A release team typically consists of a Change Advisory Board, a Release Manager, and a Release Engineer.

Change Advisory Board (CAB)

The change advisory board is responsible for authorizing system changes. Their responsibilities include:

• Analyzing, reviewing, and prioritizing requests for change
• Verifying business needs align with proposed changes
• Determine change approval process
• Prepare and contribute to documentation
• Communicate system changes to stakeholders and end users
• Analyze and measure change effectiveness

Release Manager

The Release Manager keeps the train running on time. The Release Manager oversees the entire release cycle and works with the governance team to plan, manage, and implement system changes. They are ultimately the person who ensures the proper change management processes are being followed.

Release Engineer

The Release Engineer is the technical arm of release management. The Release Engineer develops coding standards, environment strategy, source control, and release management processes.

It’s perfectly reasonable that members of the CAB include the Release Manager and Release Engineer, or that the Release Manager also engages in release engineering. These roles are only provided to show that consistent and thoughtful release management takes many skillsets.

Applying Standards

Whenever possible, apply standards. Whether your changes consist of declarative changes, like a new field and a screen Flow, or something programmatic, such as an Apex class or a Lightning Web Component, you should implement and follow standards.

Consider the following when developing your standards:

Naming Convention: How will resources be labeled and named? Will Apex or Flow variables utilize camelCase or SNAKE_CASE? There is no right or wrong answer. Rather, the important thing is that your team is aligned and committed to consistency. Naming conventions should also be concise and clearly explain the purpose of the resource.

It may be determined that some elements, such as a workflow rule or an approval process, follow one naming convention, while field names follow another.

Example Workflow naming standard: ObjectLabel_Action (Opportunity_SendEmailToManager)

Example Apex class name: sendEmailToManager

Metadata Description: Most components allow for a description to be provided, including on custom fields, Flows, and Process Builders Flows. Define a description standard that can easily convey the purpose of your elements. At a minimum it should include:

• The date the last change was made
• The purpose of the element and how it is populated (if via automation) and/or how it is used as a reference for other dependent functionality
• Trace back to requirement or design document

Development Standards: Developers recognize good code when they can quickly determine what the code does. Development standards help guide this and should also include things like:

• Performance: How efficient is the code at doing what it does? Is the code bulkified?
• Automation: Can testing be automated with third party testing tools?
• User Experience: Is the user experience consistent with the rest of the application?
• Commenting: Is the class appropriately commented out so that it is clear what each code block seeks to accomplish?
• Testing: Has proper code coverage been achieved?

For more on development standards, check out this great post on the Salesforce Architect site.

Establishing a framework to manage technical change is an important step toward creating your ultimate delivery machine. Take the time to plan this process and you won’t regret it!

Author: Grant Ongstad, Senior Salesforce Consultant

Read more of the Ultimate Salesforce Delivery Machine series:

Part 1: The Backlog

Part 2: Governance

Part 3(a): The Software Development Lifecycle