Release Management Best Practices

Release management processes should not be established in isolation. They are complexly intertwined with the business strategy, 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

Objective

The objective of release management is to have 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

salesforce-banner

Process
Consistent Processes

Sometimes, large companies have multiple different release management processes even for the same org. For one division, they 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 for 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 example, 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. This is where the change management process starts. In the change management process, all the components are reviewed together: BRD, requirements documents, test cases, alongside 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 customers to 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 smaller 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 customers to follow the best practices set by Salesforce. Salesforce has a very 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?
  • Well, the answer to this question really depends on many different factors. For example, what is the urgency of your changes versus the new enhancements from Salesforce?
  • 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 either 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 production 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

This team is responsible mainly for light configuration changes. This includes creating and managing users, managing data, managing territories, managing data fixes as well as managing page layouts, and assigning layouts to different users based on the permissions.

Sales and service team

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

Sales and service team

Enhancement team

This team is usually responsible for managing smaller projects such as making configuration changes, making changes to triggers and Visual force 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

This team is usually responsible for long and complex projects. These projects have multiple interdependencies across the rest of the ecosystem including affecting integrations with backend ERP systems. These projects are long and varied and 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 share 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.

Alternative Team Structure & Alignment

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 are 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 base. 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, these 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 version 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 typical 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 complexity
1 Eclipse Nonexistent Not required Small shops with 1 to 2 administrators Small
2 Salesforce Changesets In consideration Changes are overwritten by developers. Medium shops Medium
3 Salesforce ANT Migration tool Available, not used for all components and not used consistently Complex organizations with more than two business units Large and Multiple Orgs
4 Comprehensive solution such as Flosum Integrated version control system Complete visibility and collaboration amongst team members. complex business structure Multiple Orgs
Conclusion

It takes most organizations several years before the release management processes are mature and solidified. We recommend customers to start somewhere and to iterate on 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 few changes at a time rather than rocking the entire boat.

^