Thou Shall Backup Production before Deploying
Enterprise Development, as I stated in the introduction, must effectively coordinate the efforts of a development team. By organizing around a source code repository, you have a source of truth than enables you to always know what is in production, helping your team to quickly replicate your production environment.
Another powerful practice is to back up your production environment before deploying any new changes. This seemingly simple practice is necessary to mitigate against the risk of production deployments that don’t go according to plan. I have personally witnessed production deployments that tested fine in development, QA and UAT environments not work in production due to configuration and/or data discrepancies. When this happens, having a plan of action to be able to roll back to a previous configuration is critical to minimize downtimes for people using the systems.
Backing up production before migration becomes even more important when you cannot completely automate the migration process. On the Force.com platform, because there is no way of extracting a complete representation of configuration and code that describes a Salesforce.com organization, there will be certain types of configuration that will need to be done manually. This means that certain configurations may not exactly match how the lower environments were configured and cause problems in production. And if you don’t remember the exact steps, or have incomplete or missing documentation, you would like to be able to roll back to a known good state.
Unfortunately, the ability to backup and restore a Salesforce organization is not available on the Force.com platform. (You can schedule a weekly backup of your data, but not your configuration and code). Instead, if you want to test your deployment before moving to production, you are forced to create a full copy sandbox and test your deployment process within the sandbox. Sounds like a great alternative, except for one, minor detail. You can only refresh a full copy sandbox every 29 days. So if you manage to screw up a deployment and want to test it again, you will need to wait until you can refresh it.
I did find a suggestion at ideas.salesforce.com that speaks about having the ability to restore salesforce.com using a snapshot metaphor. If you think that this would be a valuable addition to salesforce.com, I encourage you to vote on it here.
In the meantime, what practices have you invented for minimizing the risks of failed production deployments within the force.com platform?
Improving Enterprise Development in the Cloud – Part 2
Enterprise Development, as I stated in the introduction, must effectively coordinate the efforts of a development team. By organizing around a source code repository, you have a source of truth than enables you to always know what is in production, helping your team to quickly replicate your production environment.
Another powerful practice is to back up your production environment before deploying any new changes. This seemingly simple practice is necessary to mitigate against the risk of production deployments that don’t go according to plan. I have personally witnessed production deployments that tested fine in development, QA and UAT environments not work in production due to configuration and/or data discrepancies. When this happens, having a plan of action to be able to roll back to a previous configuration is critical to minimize downtimes for people using the systems.
Backing up production before migration becomes even more important when you cannot completely automate the migration process. On the Force.com platform, because there is no way of extracting a complete representation of configuration and code that describes a Salesforce.com organization, there will be certain types of configuration that will need to be done manually. This means that certain configurations may not exactly match how the lower environments were configured and cause problems in production. And if you don’t remember the exact steps, or have incomplete or missing documentation, you would like to be able to roll back to a known good state.
I did find a suggestion at ideas.salesforce.com that speaks about having the ability to restore salesforce.com using a snapshot metaphor. If you think that this would be a valuable addition to salesforce.com, I encourage you to vote on it here.
In the meantime, what practices have you invented for minimizing the risks of failed production deployments within the force.com platform?