Most enterprises err by establishing Salesforce release management best practices in isolation.
It closely connects with the business strategy, business objectives, change management, governance, and other aspects of the organization. Therefore, best practices in release management need to be formed jointly with the steering committee and the Center of Excellence (COE) to ensure that everyone is on the same page. In the blog, you’ll learn how to simplify and succeed in release management. Let’s dive right in.
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 focus on running shorter, high-yield business projects, it is imperative that we optimize the application delivery value chain to ensure that there are no bottlenecks in delivering the business value.
Salesforce Release Management Best Practices
Release management best practices can be broken down into the following tenets. We will touch on each of them in the following paragraphs.
- Salesforce release process
- Release cycles
- Change management process
- Mitigating Risk
- Starting and Iterating
- People
- Technology and Infrastructure
Salesforce Release 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 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 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 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 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 that customers follow the Salesforce release management best practices. 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 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
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 of 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 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 right 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 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 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
LevelToolsVersion ControlTeam CollaborationGenerally Used BySize and complexity1EclipseNonexistentNot requiredSmall shops with 1 to 2 administratorsSmall2Salesforce ChangesetsIn considerationChanges are overwritten by developers.Medium shopsMedium3Salesforce ANT Migration toolAvailable, not used for all components and not usedconsistently Complex organizations with more than two business unitsLarge and Multiple Orgs4Comprehensive solution such as FlosumIntegrated version control systemComplete visibility and collaboration amongst team members.complex business structureMultiple 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 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.
