Everyone knows that release day can be stressful. No matter how much you tested your changes, moving something from sandbox to production brings fears of red deployment circles and user complaints. This does not have to be the case. With the right amount of preparation and planning, release day can go from deployment fish to done in peace.
Developing for Release
The first step to a successful Salesforce deployment is developing the changes with the release in mind.
- Keep track of the changes you are making in a change set as you go so that you don't have to waste precious release hours remembering what you developed weeks or months ago.
- Take note of any manual steps that will need to be taken pre or post deploy while you are performing those steps in development.
- Are you deploying page layouts or do you need to update page layouts manually after deploy?
- Who needs permission to what you're developing? Who should never have permission to what you're developing?
- Am I deploying any picklist values or do I need to manually add them?
- Do I need to create custom setting records?
- Do you need to run any data updates with data loader, an apex script or a batch class?
Testing for Release
Getting new functionality to work can be incredibly exciting, but that does not mean that it is ready to be released. Testing is very possibly the most important action you can take in order to set yourself up for a succesful release. Both the developer and the end users are responsible to test to ensure that the requirements were met and will work as expected. Here are some suggested ways for both developers and end users to test with release success in mind:
Developer Testing
- If there was any apex written, the developer is required to write tests for code coverage but should also ensure there are great assert statements that test the goals of the project.
- The developer should also walk through the affected processes to see if the functionality works in a real scenarios using the UI.
End User Testing
- End users should test the new functionality exactly as they expect to use it once it is released.
- End users should test all of their standard business processes in the testing envrionment to ensure that the new functionality does not break any unexpected areas of their work.
- End users should test with real world examples, not only test data. Test data is great for developing, but test data often is not set up the same way that real data is set up.
The importance of testing well before a release cannot be stressed enough. No matter what size of the project, testing should be completed by both the developer and the end users in order to ensure that when the functionality is released, nothing unexpected happens.
Preparing for Release
Even though you have developed with release in mind and tested for release success, it is also important to prepare for release day. The best way to prepare for release day to make sure that your change set(s) are validated before the day of release. This will help you identify missing change set items, fix erroring tests and remove the need to wait for validation on day of release. Another great way to prepare for release day is to document the steps that you will take. Answering the following questions and writing down your answers will help you make sure that you have thought through everything that needs to be done:
- Are there any steps that I need to take before I deploy the change set(s)?
- Will I need to split the items being deployed into multiple change sets?
- After the change sets are deployed what else do I need to do before I can begin the testing in the new environment?
- If data loads are required, what order should they be done in and where are the files that are to be loaded stored?
Not only do these questions help you to feel more confident about what needs to be done, but it also makes it possible for you to hand off the release to someone else if an emergency arises.
Release Day
Now, you have done all the work needed to have a smooth release day and the last item to figure out is when you will release.
- Setting up a rolling release schedule weekly, bi-weekly, or monthly depending on what works out best for your company is best practice. Having a schedule like this helps to set cut-off dates for what items will be released and will also help users get used to what they should expect when new features are being released.
- It is recommended to run all releases after business hours to avoid interfering with users as functionality changes and if a lot is changing, releasing over the weekend can be wise so that you have the proper time to test everything.
Releases can be stressful, but if you begin to develop, test, and prepare for a release in these ways then your releases will be successful and your end users will be happy!
If you are trying to plan out a succesful project, make sure to also check out our article on the incredible drawbacks of mixing Salseforce technologies.
