... | ... | @@ -13,15 +13,13 @@ end note |
|
|
note left of RP
|
|
|
These repositories contain the current merged revisions
|
|
|
of the Standards, Requirements, and Code for the project.
|
|
|
In addition, any other artifacts submitted to the system
|
|
|
for consumption during the workflow will also reside here.
|
|
|
end note
|
|
|
AM -down-> RP
|
|
|
frame "Patch Review" {
|
|
|
[Patch Tracker] as PT
|
|
|
[Continuous Integration] as CI
|
|
|
|
|
|
() "Reviews" as RS
|
|
|
() "Comments/Votes/Artifacts" as RS
|
|
|
() "Patch Status" as PS
|
|
|
() "Candidate Patches" as CP
|
|
|
RV -> PT
|
... | ... | @@ -50,12 +48,48 @@ CD -> COM |
|
|
![Trustable Software Workflow](https://mustard.trustable.io/renderUML/https://gitlab.com/trustable/overview.wiki.git:TrustableSoftwareWorkflow.md)
|
|
|
|
|
|
|
|
|
This diagram details a model workflow for software that can be considered 'Trustable'.
|
|
|
|
|
|
The project's requirements, standards with which it must comply, and source code are held within Repositories.
|
|
|
This diagram details a model workflow for software that can be considered
|
|
|
'Trustable'. The goal of the model is to ensure three aspects of the project:
|
|
|
|
|
|
When a Developer creates a revision (to any of the above), it is submitted to a Patch Tracker. The Patch Tracker keeps a record of the developer that has submitted the revision, as well as the accompanying commit message explaining why the revision is necessary and which requirement/standard it satisfies, if any. The Patch Tracker passes candidate patches onto a pre-merge CI system, which reviews the patch automatically to ensure that it does not violate pre-determined rules (dictated by both requirements and standards) or 'break the build'. At this stage, the patch is also reviewed by human Reviewers, and comments/suggestions/artifacts are submitted back to the Patch Tracker. The Patch Tracker also reports the status of the patch, and once it has passed review, it (along with the submission data) is consumed by an Automerger.
|
|
|
* Auditability of patch provenance, patch approvals, etc.;
|
|
|
* Machine-readable requirements/standards;
|
|
|
* Delivery of sufficient metadata during rollout to support compliance review.
|
|
|
|
|
|
If necessary, the Automerger then submits the revision to Testing. Results from testing inform the CI, and passing test results are automatically merged into the Repositories along with the latest revision.
|
|
|
It is in effect a collection of best practices which, when complied with, ensure
|
|
|
that these three requirements are met.
|
|
|
|
|
|
A Continuous Deployment system then deploys the source code to production. Simultaneously, the requirements, standards, submission data and passing test results are consumed by an automatic compliance document generator (such as [Compliance Masonry](https://gitlab.com/trustable/overview/wikis/opencontrol-compliance-masonry-example)) to produce an up-to-date Compliance Document. This document shows which requirements/standards have been satisfied, with a narrative consisting of the relevant patch(es), the developer responsible for them, evidence of passing tests, and the commit messages at time of submission. In this way, the compliance documentation is consistently updated as the project progresses, and is traceable to the source code and developer. |
|
|
\ No newline at end of file |
|
|
The project's requirements, standards with which it must comply, and source code
|
|
|
are held within Repositories. The requirements and standards are encoded in a
|
|
|
machine-readable format, such as yaml.
|
|
|
|
|
|
When a Developer creates a revision (to any of the above), it is submitted to a
|
|
|
Patch Tracker. The patch inherently carries a record of the developer that has
|
|
|
submitted the revision, as well as an accompanying commit message explaining why
|
|
|
the revision is necessary and which requirement/standard it satisfies, if any.
|
|
|
The Patch Tracker passes candidate patches onto a pre-merge CI system, which
|
|
|
reviews the patch automatically to ensure that it does not violate
|
|
|
pre-determined rules (dictated by both requirements and standards) or 'break the
|
|
|
build'. At this stage, the patch is also reviewed by human Reviewers, and
|
|
|
collective comments, votes and artifacts (such as test logs from the CI system)
|
|
|
are submitted back to the Patch Tracker. The Patch Tracker also reports the
|
|
|
status of the patch. This status is monitored by an Automerger, which then
|
|
|
submits the revision to Testing when all pre-merge criteria have been met.
|
|
|
Results from testing inform the CI, and the logs are retained in the Patch
|
|
|
Tracker. This review metadata is referenced using links in each revision of the
|
|
|
code that is merged to to the Repositories.
|
|
|
|
|
|
A Continuous Deployment system then deploys the source code to production.
|
|
|
Simultaneously, the requirements, standards, submission data and passing test
|
|
|
results (obtained using the links to the metadata in the Patch Tracker) are
|
|
|
consumed automatically to produce an up-to-date Compliance Document. This
|
|
|
document shows which requirements/standards have been satisfied, with a
|
|
|
narrative consisting of the relevant patch(es), the developer responsible for
|
|
|
them, evidence of passing tests, and the commit messages at time of submission.
|
|
|
In this way, the compliance documentation is consistently updated as the project
|
|
|
progresses, and is traceable to the source code and developer.
|
|
|
|
|
|
(This parallel CD/documentation pipeline is primarily for deployment to a given
|
|
|
production target, however this may be one of several such pipelines, such as
|
|
|
when multiple versions of the code are deployed to independent targets that each
|
|
|
need compliance documentation.) |
|
|
\ No newline at end of file |