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:

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 are handled in the same workflow as listed above in “Migration to the production environment (Separation of Duties (SOD)).”

Emergency changes to the product follow the same procedure as above but with priority to “top urgent” issues. 

Read more about our emergency changes here.

Data migration is handled via a distributed version control system that is encrypted and secured by our network.

TeamCity is the tool we use to deploy builds from local testing, testing, staging, and live environments.

Version numbering is as follows:

We use TeamCity build management to compile our system locally. Unit tests are run through TeamCity to help verify the integrity of the system. 

System compilation via the cloud is done with Azure DevOps. 

All changes, updates, and fixes to Indigo undergo manual and automated testing. Our quality assurance team employs TestRail as their tool for creating test scenarios, performing tests, and monitoring and documenting results. 

Test scenarios are documented and organized in a hierarchical tree based on the build of the software, the modules of the software, the page of the software, the tabs or widgets of the software, and specific features of the software.

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.