Software Release Protocol

Hard (user affected) Software Releases

This the protocol for releasing software updates to the production environment when the software updates affect the user.

1. Standard system tests – As the changes and bugs are fixed in the staging environment, the staging environment needs to be tested as the new changes are implemented on a piecemeal basis.
2. Create release notes – Create a list of the particular issues (software changes) to be included in this software release and draft a “Release Notes” document. This “Release Notes” document should include the software version number (e.g. 3.01) and contain a list of each change with the Unfuddle ticket number, title, and brief description of the change from a user perspective.
3. Draft “Software Update” vrMIS User Manual appendix – As an appendix to the vrMIS3 User Manual, a “Software Update” document needs to be drafted. This document will inform the users of the changes from the user experience perspective. So, changes to be included in this document should include any changes to the UI or process flow. Each change should mention separately and should include screenshots giving the user a visual representation of the change. Not all changes will need to be included in this document. Changes that affect the background operations and do not affect the user in any way do not need to be included in this document. This document should be written with a user orientation.
4. Customer communication – Communicate the intended release to the responsible HSG staff member and send the “Release Notes” document. Ask HSG staff member if there is a preferable date to schedule this release.
5. Schedule release date – Together with responsible HSG staff member, schedule a date at least 10 days in the future. This buffer will allow time for step 6 and step 7.
6. Finalize “Software Update” vrMIS User Manual appendix – Send the draft of the “Software Update” document to the responsible HSG staff member and request any feedback. Once that feedback is incorporated into the document, the “Software Update” document should be finalized.
7. Final round of Quality Assurance testing – After the release date is scheduled, a final round of QA testing needs to occur in the staging environment (all changes should be in the staging environment and already have gone through numbers rounds of bug testing) to ensure a bug is not being introduced into the production environment. Additionally, the production database should be copied and imported to the staging environment. This will test the production’s database with the new code.
8. Quick fixes of small bugs (if needed) – If there were any new, small bugs discovered during the last round of QA testing, then these bugs can be fixed before the scheduled release. The buffer time included in the scheduled release date is designed to account for these small bug fixes. If there are any bugs found and then fixed, another round of QA testing will be required.
9. Promote changes to Production – Once a full round of QA testing is successful without any new bugs, the changes are ready to be promoted to production. The changes should be promoted to the production environment by 9:00PM PST the day prior to the scheduled release date.

Soft (user not affected) Software Releases

This the protocol for releasing software updates to the production environment when the software update changes don’t affect the user.

1. Standard system tests – As the changes and bugs are fixed in the staging environment, the staging environment needs to be tested as the new changes are implemented on a piecemeal basis.
2. Create release notes – Create a list of the particular issues (software changes) to be included in this software release and draft a “Release Notes” document. This “Release Notes” document should include the software version number (e.g. 3.01) and contain a list of each change with the Unfuddle ticket number, title, and brief description of the change from a user perspective.
3. Customer communication – Communicate the intended soft release to the responsible HSG staff member and send the “Release Notes” document. Ask HSG staff member if there is a preferable date to schedule this release. Even though the user will not be affected by these changes, the responsible HSG staff member should be kept in the loop on changes in the system.
4. Final round of Quality Assurance testing – After the release date is scheduled, a final round of QA testing needs to occur in the staging environment (all changes should be in the staging environment and already have gone through numbers rounds of bug testing) to ensure a bug is not being introduced into the production environment.
5. Promote changes to Production – Once a full round of QA testing is successful without any new bugs, the changes are ready to be promoted to production.