Any defects or changes will be logged in the Turtle Tasks issue management system. This allows defects and changes to be managed through the development, testing and deployment processes. The Turtle Tasks database is backed up offsite daily.
If additional features or changes to the design are required, the impact on the budget and schedule are submitted for approval by the Client. Changes are tracked in the Turtle Tasks issue management system.
We utilise a cloud-hosted Mercurial source code repository.
The programmers commit after they have finished a change. Changes are unit-tested locally before committing. When committing, changes are merged into the main codebase.
Prior to moving onto the next task, the programmers update their local version by pulling down the latest versions.
We can release when all developers have committed and merged. The team lead pulls the latest version to the development server and tests the changes.
The QA server is updated to the latest version for review by the project manager and client.
Our projects usually do not require automated builds or automated testing. Our releases have a unique release number which is generated by the source code repository. This number should be noted when logging issues in the Turtle Tasks issue management system.
Documents contain the client name, project name, document name and a version number of the form x.y. The major version number (x) is incremented each time the document is released to the client. The minor version number (y) is set to zero when the major version number is incremented and otherwise incremented during internal review cycles. Documents are stored in Turtle Technology's file system and regularly backed up.
Without massive investment, premises, networks and storage cannot be guaranteed to be 100% secured. We take standard precautions.
A user manual and training can be created upon request. However often this is not required. Depending on the system, documentation may be provided containing suggestions on how to look after the website and use it to its full potential.
If we are not hosting the website then the published build files are transferred to the client or to the alternative web server.
