From release to installation
A release starts your version choice.
Follow the planned path from a change summary and signed packages to a version your administrator must be able to approve.
A new version does not install itself
Tomstok is designed to make a released version available without upgrading your environment automatically. You must be able to explicitly choose the version to use in your installation.
Tomstok promises no fixed update cadence. Plan around the specific change and your operations.
Explore your installation and update choicesVersion changes your administrator must be able to approve
Version changes are designed to require approval from one of your administrators. You must be able to choose the timing, including for a security update.
Tomstok’s central administrator access must not replace your approval. You approve the specific transition to the selected version.
Understand the change and identify the package
The plan is for a change summary that distinguishes Tomstok’s central administration from the software running in your AWS account. It should describe the functional changes in the specific version so your IT team can assess the impact.
Signed software packages and unambiguous version references should connect what you choose to what is installed. Unknown versions or incorrect packages must be rejected.
Testing before central administration goes live
For Tomstok’s central administration, the release process is designed to test the actually deployed candidate in the test environment before production, and promotion must use that same tested software package. Human approval before production is planned to be reinstated.
Schema changes in your installation have their own planned process with downtime and checks on the route back.
Read about downtime and recoverySee Tomstok with your products in mind.
Talk to us about your product range and production requirements.