Deployment is considered as the critical phase of the project.
They also determines the overall success of the project. The purpose of release
and deployment planning is to; Define and agree release and deployment plans
with customers/stakeholders. Then ensure that each release package consists of
a set of related assets and service components that are compatible with each
other. The ensure that integrity of a release package and its constituent
components is maintained throughout the transition activities and recorded
accurately in the configuration management system.
Ensure that all release and deployment packages can be
tracked, installed, tested, verified, and/or uninstalled or backed out, if
appropriate. Ensure that change is managed during the release and deployment
activities. Record and manage deviations, risks, issues related to the new or
changed service, and take necessary corrective action. Ensure that there is
knowledge transfer to enable the customers and users to optimise their use of
the service to support their business activities.Ensure before the deployment we
have prepared the deployment schedule
and have a sign-off on availability of various stakeholders involved in the
deployment. It is important that the deployment schedule is prepared while in
UAT phase and not have the deployment activities. It is suggested not to have
new requirements/enhancements implemented after the completion of User
Acceptance testing. They can affect the
deployment schedule.
Never do the deployments on Friday, we encourage the major deployments to be done on Monday so that we have a full week to monitor the new changes in production. During the preparation phase of the deployment few points to be considered pre-deployment are Creating Users in production, Setting up Org wide defaults for the standard objects,Installing any 3rd party AppExchange apps, Salesforce configurations like setting default workflow user, lead owner, Case owner, enabling Chatter, Email deliverability, Salesforce to Outlook configurations, Enabling multiple currencies, configuring IP ranges for the organisation etc. Other steps include Creating and Publishing communities, Taking backup of the existing data, Ensure the code coverage is more than 75%, Prepare a checklist of all the items to be deployed, Prepare change management document, Turn off the email notifications sent automatically via workflows and so on.
Never do the deployments on Friday, we encourage the major deployments to be done on Monday so that we have a full week to monitor the new changes in production. During the preparation phase of the deployment few points to be considered pre-deployment are Creating Users in production, Setting up Org wide defaults for the standard objects,Installing any 3rd party AppExchange apps, Salesforce configurations like setting default workflow user, lead owner, Case owner, enabling Chatter, Email deliverability, Salesforce to Outlook configurations, Enabling multiple currencies, configuring IP ranges for the organisation etc. Other steps include Creating and Publishing communities, Taking backup of the existing data, Ensure the code coverage is more than 75%, Prepare a checklist of all the items to be deployed, Prepare change management document, Turn off the email notifications sent automatically via workflows and so on.
The most important
process is to create the change sets with all the components involved in
deployment and get the change set verified in production. If the deployment
activities are well planned ahead of time, it gives the team sufficient time to
verify all the components of change set before actual deployment to take place.
Have to send out a notification to all
the users suggesting down time before the actual
deployment. It is necessary that the users are communicated beforehand of
the downtime along with the new changes/enhancements they might expect when
they login post deployment.
If the change sets are already validated in production as
part of preparation process, it just needs to be deployed for the actual
deployment. The deployment may take few hours since all the test classes will
run against the new enhancements in some complex org. Please have sufficient
buffer time for the actual deployment.
We would do the sanity testing in production to ensure if everything is working
according to the requirement and in line with the user stories provided during
the requirements. The post deployment sanity checks also helps in identifying
if there was any miss during the deployment.
The users should be notified after the sanity testing so that
they can start using the live environment and so on. It is must that the system
should be monitored for a week before getting sign off on the deployment. There
is no foolproof process to follow the deployment process. Following these steps
will definitely reduce the risks assoicated with the deployment and will ensure
a successful deployment. For more
No comments:
Post a Comment