Overview
We use an issue and bug tracking product for our change management procedures and system development methodology. This product is used in all phases of our product development, security protocols, and bug-tracking and fixing procedures.
The team follows a regimented two-week sprint workflow.
The workflow is as follows:
Migration to the production environment (Separation of Duties (SOD))
Shireburn uses a swapping procedure when deploying the staging build of Indigo to the production build.
All changes and fixes are done to the testing build of Indigo. No work is ever done on any live production builds of the software.
When the test build is developed and passes manual and automated testing, we perform a swapping procedure to the staging build of the product via a production pipeline, where we run smoke tests to verify is stability. When testing is successful, the build is pushed to the live build.
Configuration changes
Configuration changes are handled in the same workflow as listed above in “Migration to the production environment (Separation of Duties (SOD)).”
Emergency changes
Emergency changes to the product follow the same procedure as above but with priority to “top urgent” issues.
Data migration and version controls
Data migration is handled via a distributed version control system that is encrypted and secured by our network.
We use a tool to deploy builds from testing to QA, from QA to staging and live environments. The tool compiles our system, where then, tests are run to help verify the integrity of the system.
Version numbering is as follows:
We use Azure DevOps to compile our system. Tests are run through 3rd party software to help verify the integrity of the system.
System compilation via the cloud is done with Azure DevOps.
Post change/implementation testing and reviews
All changes, updates, and fixes to Indigo undergo manual and automated testing. Our quality assurance team creates test scenarios, perform tests, and monitor and document results.
Test scenarios are documented and organised in a hierarchical tree based on the following characteristics of the software:
modules
page (section)
tabs or widgets (where applicable)
specific features
The team follows a guide on writing test cases. Test cases require detailed navigation steps (instructions on how to reproduce the test), the specific parameters to undertake the test, and details on the expected and actual results. A writing guide accompanies the building of test cases.
A checklist of manual and automated test scenarios are employed in every two-week sprint development.