https://www.flosum.

com/release-management-best-practices/
Release Management Best Practices
Resources » Articles » Release Management Best Practices
Release management processes should not be established in isolation. They are complexly intertwined with the business strateg y, business
objectives, change management, governance, and other aspects of the organization. They need to be formed jointly with the steering
committee as well as Center of Excellence (COE) to ensure that everyone is on the same page.
Objective

The objective of release management is to have a consistent set of repeatable, reliable and resource-independent processes to achieve
optimal business value and optimize resource utilization. Given that most organizations are focused on running shorter, high-yield business
projects, it is imperative that the application delivery value chain is optimized to ensure that there are no bottlenecks in delivering the
business value.
Key Tenets
Release management can be broken down into the following tenets:

• Sandbox management
• Version control

• Deployment procedures & tools

• Team structure (including center of excellence, steering committee, executive sponsors)

• Change management strategy

Process
 Consistent Processes
Sometimes, large companies have multiple different release management processes, even for the same org. For one division, the y may be
using one set of processes and for another division, they could be having a totally different set of processes. It is necessary to streamline and
standardize the processes across the various sets of users since they are using the same foundation, platform, and resources to enable their
business. This can lead to a huge failure in governance. Various sets of users need to have visibility into what others are doing. For example,
multiple developers may need to know that they are modifying the same object.
From a governance perspective, it is vital to have visibility amongst different developers, accountability for each action, and a consistent set
of processes amongst the entire team which is supporting the Salesforce ecosystem.

Release Cycles

Centralized Intakes
Customers use multiple systems to manage different sets of requirements. It is imperative to have a centralized system to track all the
requirements, and at one single place so that the entire team has visibility into the changes and features requested by the business.
Many times enhancements, which are most spoken about, get implemented without considering the total cost of ownership or ROI for the
business. It is vital to prioritize those requests that would have the most impact on the business. It is recommended to have a steering team
to review the requirements periodically and prioritize the most impactful changes in the system.
It is highly recommended to have a regular cadence between business and IT to discuss the changes that should be done to the Salesforce
system. Business should present the value that will be showcased by each feature request and IT should present the effort required to
implement that change. Based on the value and the cost of implementing the feature, the steering committee should decide on the new
feature changes.
However, business and IT should stay in touch during the entire implementation phase. It is necessary for business and IT to keep
communicating once the right set of features are decided upon. For ex ample, most customers have a 2-week or 4-week sprint cycle. If
business and IT meet at the end of the sprint cycle to review the changes made by IT, it’s almost guaranteed that IT will not deliver what the
business had in mind. This is the reason the entire team, including QA, business users, and release managers, should stay in touch
throughout the sprint cycle where the developers demo the latest changes and business users approve the changes throughout the sprint
cycle. This requires a mindset shift across the entire organization.
Release Calendar
IT should publish the release calendar of the various dates of the sprint cycle. The calendar should include details such as dates for unit
testing, first QA round, CRP, and final deployment to production system.
Change Management Process
The developers could be making changes or creating the features in their developer sandbox. Also, they could be showing/demoing the
feature from a developer sandbox. Once the feature is fully complete, it could be moved into the QA environment. Here, QA will test the
feature based on the requirements document. After QA signs off, the feature could be moved into your A Unit environment where the change
management process starts. In the change management process, all the components are reviewed together: BRD, requirements documents,
test cases, along with latest production code.
Mitigate Risk
Based on the progress made on different features, business and IT should continuously evaluate the risk of pushing any change to the
production system. Based on our observations, we see many customers working on big, long, complex projects. We recommend that
customers adopt an agile development methodology. This has many benefits, such as reducing the work-in-progress code, improving
development productivity, and continuously delivering business value.
When developers work on a long-running project which is integrated to other parts of the existing system, they need to continuously work
with other developers to ensure that they are not stepping on each other’s toes. This greatly decreases their efficiency. Customers should
consider an alternative approach. With agile development methodology, they should focus on delivering business value in small er chunks.
They could potentially focus on the smallest part of the project which has the most business value.

Start and Iterate

Follow Best Practices

We recommend that customers follow the best practices set by Salesforce. Salesforce has a unique architecture for Cloud and metadata-
based architecture. Following the right processes set by Salesforce will help customers stay in compliance and will improve the
supportability that they will get from Salesforce.
Aligning Your Release with the Salesforce Release
It is often frustrating for many organizations when they have to release their own code while Salesforce is upgrading their changes. The
typical questions are:

• How should we test the changes?

• Should we release our changes before or after the release?

• What is the business value of your changes compared to the business value of the new features released by Salesforce?

• What features do you plan to uptake from the new release?

• How many users are affected by your own internal release?

• How many sandboxes are available for testing your internal changes vis-a-vis Salesforce’s new features?
Most customers release their features early by reducing the scope of the release and deploying their changes before the new features hit the
sandbox.
Alternatively, many customers will test the changes on sandbox for the new release. They wait for the new release to hit the pr oduction org.
Once the new release is in the production org, you can deploy your new features immediately in the production org. The time window
between Salesforce’s release date and your deployment does not have to be fairly long since you have already tested the changes on a
preview sandbox.
In any case, it is recommended to have a gap between your deployment schedule and Salesforce ’s release date.

People

Team Structure
During the planning phase, the release should be broken into multiple categories: Trust, Enhancements, Fixes, and Projects.
For example, the fixes could be done by the production support team.
The enhancements could be done by either the projects team or the production support team, depending on what needs to be changed in
the code line. This could also depend on how long it will take to make an enhancement.
Most customers break up the project team into further categories.
A typical breakdown structure can be seen as follows:
Business self-service team
The Business self-service team is responsible mainly for light configuration changes. This includes creating and managing users, managing
data, managing territories, managing data fixes as and managing page layouts, and assigning layouts to different users based on the
permissions.
Sales and service team
The Sales and self-service team is largely comprised of business users who are responsible for managing the early cycles, change
management processes, working with the quality team to assure software quality, and collaborating with the RFP team.

Enhancement team
The Enhancement team is usually responsible for managing smaller projects such as making configuration changes, making changes to
triggers and Visualforce pages, as well as simple changes to existing integrations. Typically, the changes done by this team are smaller and
isolated, which do not affect the rest of the code base.
Project team
The Project team is usually responsible for long and complex projects. These projects have multiple interdependencies across the rest o f the
ecosystem including affecting integrations with backend ERP systems, are long and varied, involve multiple different resources across
multiple different teams, and affect other systems as well.
Alternative Team Structure & Alignment
Many customers have multiple development teams. These teams are aligned to the different lines of business. For example, one team could
be mapped to the VP of sales and the other team could be mapped to the customer support team. There could be another team that is
responsible for partner sales or the web component.
Each of these teams shares common components and the ownership of components is shared by multiple different teams. For example, the
team members would share common objects such as accounts, opportunities, cases, etc. Also, some of the teams would have their own
private objects and components. For example, the customer support team would be responsible for managing knowledge articles,
entitlement objects, and milestone objects.

Given the shared ownership of the code, metadata and the processes, it is imperative to have an Architecture Review Board. The
responsibility of the Architecture Review Board is to ensure that there is no conflict amongst developers before changes are made. Also, the
Architecture Review Board will analyze any process changes before they are implemented in the system.
Each of these teams is fully responsible for understanding the business objectives of the business organization, as well as coordinating the
changes with the steering team and the change management team.
Separation of Duties
The release team is responsible for making sure that each developer has the latest code and they can access the latest code b ase. However,
the developers are responsible for coordinating the changes amongst themselves and merging the changes with the various features that
are requested. Finally, the developers should create a consolidated package of the changes that should be pushed from the
developer sandboxes to QA to UAT sandboxes to stage and finally into production.

Technology and Infrastructure

Sandbox Management
Many organizations have multiple sandboxes and different types of sandboxes. It is necessary to make the most use of the sandboxes to
ensure the best software quality and consistent processes. For complete details on sandbox management, please refer to this note.
Version Control
Version control provides a source of truth for the code artifacts. Also, it helps to improve the quality of the software. It is vital to have version
control so that multiple developers can manage their code and avoid conflicts. Version control helps coordinate the same file being changed
by multiple developers, thus allowing a developer to change multiple files at the same time. In addition, version control provides
accountability on the developer actions.
Changes Not Supported by Metadata API
Although most of the metadata components are supported by Salesforce APIs, there are some metadata components which are not. In such
cases, it is recommended that developers clearly document all the manual steps that should be done by the release team. These changes
should also be tested on QA, Unit and Stage environments before they are actually done to the production environments.
It is recommended to use source control for both the declarative components as well as the programmatic components in the ver sion
control system. This will ensure that the code quality is better and the governance is improved across the entire organization.
Code Merges
It is a very common problem for even mid-sized customers to have multiple teams working on the same code artifacts. Salesforce has a
really small code base, including the declarative metadata. For example, some of the largest Salesforce customers have less than 10,000
metadata components. These customers typically have 5,000 to 8,000 users in addition to the community implementation, such as partner
communities or customer communities. When you compare this to other platforms such as Oracle and SAP, the code base is really small.
Also, the development team size is very small for managing the Salesforce implementations. A team managing 5,000 to 8,000 users is
typically less than 15 members.
However, these 15 members often work on the same set or sets of files. For example, two developers could be working on different user
stories and modifying an account on an opportunity trigger. Salesforce lacks the tools to provide visibility into what files the developer is
working on.
Flosum helps customers manage visibility.
Maturity Levels

Level Tools Version Control Team Collaboration Generally Used By Size and comple

1 Eclipse Nonexistent Not required Small shops with 1 to 2 Small

administrators

2 Salesforce Changesets In consideration Changes are overwritten Medium shops Medium

by developers.

3 Salesforce ANT Available, not used for consistently Complex Large and Multiple
Migration tool all components and not organizations with more
used than two business units

4 Comprehensive solution Integrated version Complete visibility and complex business Multiple Org
such as Flosum control system collaboration amongst structure
team members.

Conclusion
It takes most organizations several years before the release management processes are mature and solidified. We recommend cus tomers to
start somewhere and to iterate these processes. We have also observed that it is better to have wrong processes than to have no processes.
Wrong processes can be corrected, but organizations which lack certain aspects of governance and change management find it very hard to
implement new processes. We also recommend customers to observe what is not working and make only a fe w changes at a time rather
than rocking the entire boat.