Whenever you deploy changes to production, you need to be very careful because end user will get effected if something goes wrong. Whenever you are deploying changes to production, you need to follow some strategies.
Preparation for Deployment and Roll Back plan:
1) Before you deploy your changes to production, you should first deploy the changes to full copy sandbox and validate your changes.
2) Prepare a list of manual steps.
3)Always backup your production data.
4)Make a roll back plan.
Schedule your release with following steps:
1) Before you deploy your changes to production, you must announce a maintenance window.
2) Stop all setup changes on production.
3)Create a staging environment
4) Switch environment dependencies and services from testing to production values.
5) Lock users out of the application.
6) Deploy to production
7) Unlock the production org.
Inform users about the new changes:
Once you are done with deployment, you have to update your users about these changes. For example, if you have enabled chatter, then make a chatter post. Notify all the users via email about the new changes. Prepare a document of the changes. If needed, you should also set up a training session with the users.
AJ Levinson
7 Aug 2018I cringe when I see “manual” mentioned as part of any deployment process. With today’s tools and best practices, much of a deployment pipeline should be fully automated. Ideally, if costs and resources allow, there should be dedicated environments that should only need incremental upgrades (e.g. updated environment variables) available for all stages in the pipeline. For instance, for one of my clients, I have a single development environment (my AWS resources), and then automation in place to deploy to their QA environment. Upon successful completion, another automation is in place to deploy the same code to their Stage / UAT / INTG environment. For production, maintenance windows are announced to let users know of possible degraded performance and/or availability, but it’s rare (read: never) for me to lock users out of an application completely. Instead, I use blue/green deployments, so that only some of the resources are taken down and can be smoke-tested in isolation before being returned to the production cluster.
For environment variables and properties, I will fully externalize these instead of embedding them directly into the application artifact. This ensures that a simple restart is all that’s required in the event that a property has changed. In some rare occasions, it may be required to have maintenance windows that do have the system completely unavailable (though this too can be avoided if done properly). Some examples might be OS level patching or Database changes when there’s only a single instance versus being setup to run in HA mode.