Let’s talk about project go-live! Exciting and nerve wrecking time for everyone involved. As the project managers or product owners are working on executing the project plan, release managers need to start planning for successful deployment of the project.

Why is it important to plan for a deployment?

There is a lot going on during project execution, no matter what software implementation methodology you follow – Agile or Waterfall. The delivery teams are busy coding/configuring, unit testing, code reviewing, the QAs are occupied testing, analysts are busy documenting and capturing more upcoming work, the project managers or product owners are busy ensuring everyone is headed in the right direction. Everyone has a full plate and strict deadlines.

People often think that once the work passes test scenarios and UAT gets sign-off that is a big burden lifted. But that is not always true. The deployments that are carried out without a proper plan can encounter situations such as last-minute failure of change set validation, unforeseen issues surfacing, resource unavailability, missed delivery deadlines, delivery team having to work extra hours, and even unhappy customers. No one wants to be in those situations. So, it is best to have a checklist of items that must be completed as you are approaching the deployment date. 

You can use the checklist below and thank me later.

1. Ensure UAT sign-off is received.

First thing you will need is to make sure the work items have received a sign-off from business users. This will include QA (Quality Assurance) testing, UAT (User Acceptance Testing), making sure all the acceptance criteria and definition of done for all user stories are met and are complete. That is – business users are happy with what the delivery team has built for them.

The release manager must work closely with the delivery team to get answers to following questions:

a. What is the sandbox for conducting UAT?

— That is, the name of the UAT sandbox. 

b. What is the sandbox for pre-production? That is, from which environment the changes will be migrated to production?

— Name of the sandbox. 

c. What are the types of these sandboxes?

— Ask if they are dev, devpro, partial copy or full sandbox. Depending on the type of the sandbox the space for data and metadata varies. This will give you an idea of how the testing will be carried out, if there is any pre UAT work that would need to happen, etc. 

d. Does the UAT sandbox have the right data in order for users to perform testing?

— If there is no data present, work with the delivery team to plan adding test data under the objects that are involved in the process. If this step is missed, it can possibly delay or postpone the UAT sessions. Another thing to keep in mind here is that it is not always easy to schedule time on the calendars of business users at the last minute. The UAT sessions should be scheduled by Product Owners or Project Managers months before the UAT start phase.

e. Is the pre-production environment in sync with production? Make sure they are in sync.

— If the pre-production and production environments are not in sync, test results may not be accurate. Or something that passes in the pre-production environment may fail in the production environment. 

f. Do we have a list of all users who will be participating in the UAT session?

— Ensure that these users have access to the applications. 

g. Do all the users who will be participating in UAT have access to the UAT sandbox?

— This check will avoid last minute confusions, questions, delays. 

h. Are users able to login?

— Ensure SSO (if enabled) is working for them, ensure they have their credentials, login links etc. ready in order to avoid last minute delays during UAT. 

i. What other platforms would users have to login to test the functionality?

— For other platforms or applications involved, work with those dedicated teams and ensure user access.

2. Prepare a sequence of events.

When there are multiple teams and applications involved in the business process, the execution of events may be dependent on each other. You need to prepare a list of action items in a sequence of order when they should be executed based on these dependencies.

Example: The Account needs to be scanned to do some check by application A. The results of this scan should reflect back on the Account page so that users can see the results of the scan. This scan must happen only when an account rep makes the Account Active. That is, an API call should be sent out to scan after the Account flag is switched to Active. Any can result before the Account was placed on Active is incorrect.

While putting together the sequence of events, add an owner/s with each event. And make sure these resources will be available on those scheduled dates/times.

3. Change Management.

Most organizations have a change management board that meets certain days of each month and reviews the changes ready for production for all their different platforms. This team is responsible to ensure that the changes that are going to be deployed will not negatively impact any existing functionalities or will not overlap with each other. The Salesforce release manager must ensure your list of deployment items is shared with this board.

Another way to track or submit your changes is to add the details of your changes to a platform such as SharePoint. Following information can be captured in your log:

a. Details of work item – link to your item onboard, title of the work item 

b. Names of developers who worked on the change

c. Names of business users who provided the sign-off

d. Names of architects who reviewed the change

e. Salesforce objects impacted

f. Integration details (if applicable)

g. Names of other applications or databases involved (if applicable)

h. Results of unit testing, regression testing

i. Check of backups

4. Keep stakeholders in loop.

It is best to send an email to all stakeholders and inform them about the changes that will be deployed to production during the subsequent release cycle. This would be especially helpful in case if users are working on any testing in your staging instance. Also, this email will inform them about changes that they need to expect around the deployment dates.

5.  Backups.

Ensure there is backup taken of data/metadata. This backup will be handy in case unforeseen scenarios are surfaced in production. Backup can be taken using tools such as ANT, Eclipse IDE, Copado, AutoRABIT, etc.

6. Deployment.

This is the deployment stage. At this stage the delivery team is packaging all the work and deploying it to production – either using change sets or any of the other deployment tools available on AppExchange. The actual deployment date must be known by the release manager. The release manager should know who is responsible for deployments. Items such as validation of change set, etc. can be done prior to the actual deployment start time.

This will save time for the delivery team in case there are any issues such as test class coverage failure, any conflicts with other implementations, or any missing components in the package.

7. Post-Deployment Steps.

For some changes there could be post deployment steps. These steps must be listed out by a developer after the story passes QA and unit testing. The release manager should ensure that the developers have this list ready before production deployment.

Example of manual change: The profiles in staging and production environments are out of sync, therefore the field level security on newly created fields must be manually changed after the deployment.

8. Smoke test.

It is always a good idea to do smoke testing post deployment to ensure that everything looks and works the way it is expected. Either the business analysts, product owners, business users, or the QAs can perform this smoke testing. The release manager should ensure this step is completed. In some cases, the developers do the smoke test to ensure everything is deployed correctly. 

9. Inform stakeholders.

After you ensure that the functionality is ready for users to start using, send an email communication informing all business groups about the deployment. In this email it is best to include details such as user story names and their board links.

10. Closing of work items.

This step should include closing the work items, adding the actual deployment date to the cards that are getting closed, tagging appropriate team members informing that the items are closed. Closing the completed card will reduce the clutter from your work management board.

Bottom Line

Deployments can go a lot more smoothly if planned right. The release manager should be proactive and start putting the deployment plan together while developers are working on implementing the code. The first draft of the plan may not be accurate but share the draft with your delivery team and make regular updates to it, taking timely feedback from the team.

Wish you the best for all your future deployments!

Shamli Nikam