During my time here I have seen Revium grow its client base and range of services significantly. Like any other growing company Revium has had to adopt new processes for managing the ever expanding workload and new methodologies had to be formulated to properly manage software requests from the time of receipt to the eventual release to the client. It has been a great learning experience being involved in our release management process and since it has proved effective in its implementation I would like to share this process with our readers.
Our Release Management Process
Work requests from clients are analysed and allocated to developers by way of individual tasks. These tasks are managed in our Work Register where progression is visible throughout the incident’s lifecycle. Once the incident has been resolved and the client has authorised implementation in the live environment, we will identify all incidents which can be grouped into releases. Each release will be assigned a Release ID and we will negotiate a release date with the client.
Before we perform the upload to a live production environment we will ensure that thorough testing has been conducted on all incidents scheduled for release. Test documents will be filed and requirements will be checked against specifications to ensure the delivery of high quality assured solutions to clients. Once this has been confirmed and we have familiarised ourselves with possible knock-on effects post production implementation, we will use database tools to compare database structures and highlight file differences between the staging and production environments so assist us in identifying required data and parameter updates. Furthermore we will consider web service configuration changes and alternations to access permissions before freezing the release (i.e. no further updates to the staging environment is permitted) and performing the upload to the production environment.
Post production we will perform some testing to ensure the live environment is still working as expected. The incidents will be updated on our work register and all technical components (eg. dll’s, parameters, security permissions etc) will be recorded against each incident to ensure we can always track changes if errors occur. The client will be provided with release notes detailing all the changes implemented and impact on users. The issues will subsequently be closed on our work register and the staging environment will once again become available for uploading of new solutions.
It would be reckless to suggest that our process encapsulates all possible tests to be performed during incident implementation. Experience has taught us that unforeseen errors can occur and that it is very important to learn from them. To try and prevent errors from re-occurring our checklist is therefore ever expanding.