Deployment Planning

In this chapter, we will learn about release planning, also known as deployment planning. The term release planning can also be used to refer to the planning of the whole release cycle but, in the context of this book, we are referring to the planning and execution of moving the new configuration into the production environment and how and when to make it live for users. We will also review the importance of the post go-live period, as this transition period is when users form their opinions about the system.

We’re going to cover the following main topics in this chapter:

• Deciding how and when to deploy
• Creating a deployment plan
• Going live
• Post go-live support

Supporting tools and information

A release or deployment plan is a business process that has a technical deployment component. The business process component can be captured by standard business tools. Use the tools available to you; no special tools are needed for this purpose. A deployment checklist is most typically captured on a spreadsheet.

The deployment itself will use technical tools, the same tools that were used to deploy the functionality between test environments. The people carrying out the deployment will need skill and access to these tools. They will also need System Administrator access to the Production environment. This may have been restricted until this point.

Deciding how and when to deploy

How and when to roll out your new implementation, or update your implementation, depends on the scale of the change. The obvious answer is as soon as testing and pre-go-live training is complete. This may be the case if your new implementation or updates impact a single set of stakeholders, for example, a single sales division. If your implementation impacts a large number of users or involves multiple teams or locations, you might want to consider rolling out access in phases. The benefit of enabling the functionality or access for a small number of users first is that any issues can be identified and resolved with a limited impact on users. Once in a live environment, any issues that were either not identified in testing or are the result of the deployment can have an impact on live data, which will need to be corrected. This is easier to do if it impacts a limited dataset.

If you are considering a phased approach, the first point to determine is...

Creating a deployment plan

It is very important that your deployment goes smoothly because delays and issues in this final step can overshadow all the great work that has been done up to this point. This is particularly important if the time you have to deploy is limited, that is, out of office working hours. The best way to achieve this is to have a detailed plan that everyone involved agrees with. This means that the deployment window is simply about executing tasks, not about working out what the tasks are. You will also want to agree what happens if something doesn’t go according to plan. This includes who gets notified, what additional expertise might be brought in, and what happens if the problem can’t be resolved during the deployment window.

As with all the plans we’ve created during the implementation, the deployment plan includes what you’re trying to achieve, how you’re going to approach it, who’s going to be involved, the schedule...

Going live

In this section, we look at what happens during the actual go-live and the considerations. The aim is to carry out all the detailed planning and get agreement from all involved in advance, as we have discussed. This means that the go-live is just about executing a plan.

The following are some additional practical points that you may want to consider to ensure your deployment goes well:

• Shared artifacts: It is essential that all members of the deployment team have access to the deployment checklist and other artifacts, so they are clear on the actions. Ideally, the deployment checklist will be a shared file that team members can update in real time.
• Location: It is beneficial if you can get everyone involved in the deployment in the same room. This ensures that communication is as efficient as possible. It also creates a sense of team.
• Remove distractions: If the deployment is happening during the day, it is essential that all of those involved are 100...

Post-go-live support

It is tempting to think that once the deployment is complete and the system is live, that is the end of the work. However, the post-go-live period is critical. Users are forming their opinions about the system that will have a lasting impact. It is recommended that you plan how the system will be supported directly after go-live rather than working out a course of action once you get there.

Note

The aim is always that that there will be no issues post-go-live but, in reality, issues do occur for a number of reasons. Users use the system in a way that wasn’t tested, data anomalies occur that cause errors, and things get missed in the deployment and data migration.

There are a couple of elements that you will want to have in place. You will need a communicated method of capturing, triaging, and resolving system defects. This includes agreement about the environment defects will be resolved in and the frequency with which they will be deployed. These...

Summary

In this chapter, we have learned about the importance of planning your go-live in order to support users, including how to approach the activities associated with deploying the functionality and plan how to support users during the time immediately after go-live. All of these benefit from careful planning to ensure minimal disruption to the users of the live system. For post-go-live support, we learned that this is a smaller-scale version of the testing function that was carried out before. And there’s a lot of the processes and planning that can be applied on a smaller scale.

In the next chapter, we will move beyond the foundation and explore Enterprise Territory Management. This functionality enables sales functions that have more complex territory assignment requirements to create a model based on their needs and assignment rules.

Further reading

• Change Set Deployment:

  Change Sets: Create, Add Components, Validate, Deploy

  https://youtube.com/playlist?list=PLFNbZmUNjID5Wej5SE0ron nj5m61cJjS2&si=xD4ZTZELykNx09bq

• Salesforce Certification: Development Lifecycle and Deployment Architect:

  Architect Journey: Development Lifecycle and Deployment

  https://trailhead.salesforce.com/users/strailhead/trailmixes/architect-dev-lifecycle-and-deployment