Last week I gave you an overview of our process for Salesforce release management and documentation in this blog post. This week I will be diving deeper into how we handle Salesforce deployments for full application releases and managed and unmanaged packages, as well as version releases and patch fixes to live applications.
Salesforce Deployment Plan
With our new Salesforce deployment plan, the first thing we do is compile all the details of the project. We write out every single apex class, Visualforce page, component, static resource, custom object, custom field, and profile that is to be included in the change set. We write out what backups need to happen, include scripts that needed to be run in order to update legacy data, and even include .csv files to insert new data or update existing data. Finally, we include the test scripts that we’ve written and performed for internal and user acceptance testing so that they can be performed for production verification. Upon completion of a requirement, deployment plans are updated to ensure that each component is included.
Since adopting this approach to information collection for all of our Salesforce deployments, almost nothing is being left out of the change sets. That means validations and deployments are passing on the first try, saving us hours of pulling our hair out over what might be missing, one component at a time. Our deployments are being completed in an average of 4 hours, including writing the deployment plan, building the change set, validating, deploying, and production verification. This is a significant reduction in time compared to the 2-3 days that it took us for some larger releases in the past.
Release Schedule
The next part of the process we needed to address was creating a schedule around the entire release. We had previously scheduled development for requirements over a period of about one to two weeks, or about as long as an agile sprint. To add structure and remain consistent, we set up a few main rules for preparing the schedule. First: Never, ever, deploy on a Friday, because no one wants to monitor over the weekend. We decided on Wednesday for most deployments. Next, we decided that the Dev needs to be complete 72 hours, or 3 business days, before deployment. That means that by the end of the day on Friday before deployment, no more code should be touched or updated. Come Monday morning, we are starting to build the change set and validate it, so that by Wednesday, we can just push the button and deploy. This also gives us time to get our unit test coverage up to at least 75% to pass Salesforce requirements, even though our developers strive to hit at least 85%. This 72-hour period also allows us to get every little detail from the deployment plan ready to go. We can even perform regression tests during this time, just to make sure that we didn’t happen to break that one part of the app. The final part of the schedule is monitoring and optimization. For one week following the deployment, we have one ear to the ground, listening for anything that might have slipped through our fingers and fixing it as quickly and efficiently as we can, or adding it to the next release if it needs a longer look.
User Notifications
A new requirement for one of our more consistently updated projects is that all users are notified by noon the day before deployment that we will be working and that they should save all work before the time specified for deployment. Our deployment time is usually around 8am to 9am, before the main part of the workday begins. We also notify users if there is a delay, when the deployment is completed, and when they can continue working again without worry of losing unsaved data. This obviously isn’t necessary if you are building a brand new system with no active users, but should be taken into consideration if the system is currently online and being used. Even if active users are only in the office from 9am to 5pm and the deployment is taking place at 6am, you never know who may be getting a headstart on the day, so don’t forgo this important notification process.
Test Scripts
Another change we made at Red Argyle is that we started writing test scripts to match the user stories that were defined during the discovery of requirements for the project or release. These test scripts can be written at different points in the process and are performed many different times, but that is another lengthy discussion that I will write about at another time. Test scripts are still an important part of the deployment process though. We do not deploy until our QA team has tested them internally and the client has performed User Acceptance Testing, and we both have determined it to be successful. Then, our internal team and the client perform them again in production after the deployment. Our QA team performs the tests before the deployment is ever considered complete, and the users and client are notified. The client then performs the tests during the monitor phase of the deployment and gives us the sign-off once everything has been confirmed in production. This has saved us a lot of headaches with missing pieces of functionality that were promised and never delivered.
And finally, the very last step of deployment is to update the changelog and set the version to “released” in JIRA. Even though this may seem like a lot of documentation and planning, trust me when I say this will save you hours of rebuilding change sets and fixing errors that you hadn’t planned for. I’m not saying those things won’t happen; I’m just saying you’ll be ready for them. If you’ve had success updating your own release management and deployment processes, share your tips and ideas with us below.
