We follow these principles:
We use source control tools to record changes to our software and configuration during development so that our source code and source data is uniquely identifiable.
Our deployable software is created by repeatable and automated builds.
We identify every item of source code and data used to create our deployable artefacts.
We provide a cryptographic checksum of all files we release.
We generate deployable software that is uniquely identified and self-identifying. No two artefacts we generate have the same identification.
We create software products whose environment configuration is externalised hence absent from the deployable software artefacts.
We provide a baseline of the unique identifiers for all parts of a delivery to our customers including software releases, test or production environments, hardware, data or any other delivery.
We record the all changes we make to our test and production environments, including software deployments, configuration changes, and hardware changes.
We only test software artefacts that are uniquely identifiable.
We only test software in environments whose hardware. and software components configurations are fully documented.
We use source control tools to record changes to our software and configuration during development so that our source code and source data is uniquely identifiable.
Our deployable software is created by repeatable and automated builds.
We identify every item of source code and data used to create our deployable artefacts.
We provide a cryptographic checksum of all files we release.
We generate deployable software that is uniquely identified and self-identifying. No two artefacts we generate have the same identification.
We create software products whose environment configuration is externalised hence absent from the deployable software artefacts.
We provide a baseline of the unique identifiers for all parts of a delivery to our customers including software releases, test or production environments, hardware, data or any other delivery.
We record the all changes we make to our test and production environments, including software deployments, configuration changes, and hardware changes.
We only test software artefacts that are uniquely identifiable.
We only test software in environments whose hardware. and software components configurations are fully documented.
3 comments:
Looks good,
I'd suggest you include something about:
Controlling / recording the versions of tools used to produce deployable artefacts
Recording the reasons why all changes were made
Providing methods of validating deployed artefacts / updated environments
Producing audit trails from source to environment
Clarifications / Consistency:
Consistency - 2nd principle 'deployable software', 3rd principle 'deployable artefacts', 6th 'software products', 10th 'software artefacts' 11th 'software'
'provide a baseline of the unique identifiers …' - This principle is a bit convoluted and unclear - eg is it that we identify all items in delivery or that we identify the complete set of things that make a system. Or both. Latter part of principle 'including xxx' is not clear what it is for.
The checksum principle (principle 4) is about the only one to specify a 'how' & not written as a principle.
In support of the comment above, I think something like the "who, what, when, why" a change was made, is short and sharp and something which may "stick" in peoples heads, especially newcomers. Audit would look for audit trails of this type. The words integity, consistency are also important and should be emphasised
In support of the comment above, I think something like the "who, what, when, why" a change was made, is short and sharp and something which may "stick" in peoples heads, especially newcomers. Audit would look for audit trails of this type. The words integity, consistency are also important and should be emphasised
Post a Comment