|
|
<!---
|
|
|
@startuml
|
|
|
|
|
|
title Trustable Software Workflow
|
|
|
|
|
|
[SSP]
|
|
|
[Compliance]
|
|
|
[Requirements]
|
|
|
[Standards]
|
|
|
[Testing]
|
|
|
[Production]
|
|
|
[Patch Review] as PatchReview
|
|
|
[Continuous Integration] as CI
|
|
|
[Test Artifacts] as TestResults
|
|
|
[Auto Merger] as AutoMerger
|
|
|
[Continuous Deployment] as CD
|
|
|
[Code]
|
|
|
|
|
|
Requirements -left-> Compliance
|
|
|
Compliance -left-> SSP
|
|
|
Requirements -right-> Testing
|
|
|
Testing -right-> TestResults
|
|
|
PatchReview -down-> Code
|
|
|
Code -down-> CI
|
|
|
CI -down-> Testing
|
|
|
Standards -down-> Requirements
|
|
|
Standards -down-> Testing
|
|
|
TestResults -down-> CD
|
|
|
Standards -right-> PatchReview
|
|
|
Standards -down-> Compliance
|
|
|
TestResults -right-> AutoMerger
|
|
|
AutoMerger -down-> CD
|
|
|
CD -down-> Compliance
|
|
|
CD -right-> Production
|
|
|
() "Revisions" as RV
|
|
|
:Developer: -> RV
|
|
|
note bottom of :Developer:
|
|
|
The Developer will encode Standards and Requirements as well
|
|
|
as writing implementation code.
|
|
|
end note
|
|
|
[Automerger] as AM
|
|
|
[Test Environment] as TE
|
|
|
() "Repositories" as RP
|
|
|
() "Testing" as TS
|
|
|
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
|
|
|
() "Patch Status" as PS
|
|
|
() "Candidate Patches" as CP
|
|
|
RV -> PT
|
|
|
RS -down-> PT
|
|
|
PT -down-> PS
|
|
|
PT -> CP
|
|
|
RP -> CI
|
|
|
PS -up-> CI
|
|
|
CP -> CI
|
|
|
CI -up-> RS
|
|
|
PS -right-> AM
|
|
|
}
|
|
|
AM <-> TS
|
|
|
CI <-> TS
|
|
|
TS <-> TE
|
|
|
:Reviewer: -down-> RS
|
|
|
[Continuous Deployment] as CD
|
|
|
[Production Deployment] as PD
|
|
|
[Compliance Documents] as COM
|
|
|
RP -down-> CD
|
|
|
CD -down-> PD
|
|
|
CD -> COM
|
|
|
@enduml
|
|
|
-->
|
|
|
|
|
|
![Trustable Software Workflow](https://mustard.trustable.io/renderUML/https://gitlab.com/trustable/overview.wiki.git:TrustableSoftwareWorkflow.md)
|
|
|
|
|
|
|
|
|
The process starts by capturing requirements (for example in a [mustard](https://gitlab.com/trustable/overview/wikis/report#mustard) yaml file). These requirements are written in such a way that the individual rules of a standard are encapsulated where possible, and they must be both machine testable and human readable. They are contained in the project repo.
|
|
|
This diagram details a model workflow for software that can be considered 'Trustable'.
|
|
|
|
|
|
A patch review system is put in place, which ensures that each revision is traceable to the developer (this will require careful implementation). If the code within the patch satisfies a previously unaddressed requirement or introduces a new feature, this must be expressly stated in the commit message. The enforcement of this aspect can be partially automated (patches that do not have an explanation message, or the correct credentials, can be rejected, for example), however the commit messages are primarily for ease of human auditing, and will be retained as metadata for consumption downstream in the process when documentation is generated.
|
|
|
The project's requirements, standards with which it must comply, and source code are held within Repositories.
|
|
|
|
|
|
The patch tracker is integrated with a CI system, which ensures that a submitted patch does not break any features. This means that code which implements a particular requirement of the system can be shown to function as expected, as well as being directly linked to specific SLOC and the developer who merged it. Often, a standard will dictate its own rules regarding patch review, which can be integrated at this point.
|
|
|
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.
|
|
|
|
|
|
The CI runs tests on the code, and test results are produced as a standalone artifact. An automerger is configured with both human and machine reviewing, which creates a branch consumed by a continuous deployment system.
|
|
|
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.
|
|
|
|
|
|
The CD system runs a script which consumes the requirements yaml, as well as the test result artifacts and information from the patch tracker to generate an output with a compliance narrative for each individual requirement/standard control (including the patch commit messages), their accompanying test results, and information about who submitted the patch(es). This is updated every time there is a revision to the code, requirements or standard. This output can be consumed by an automatic compliance document generator (such as [Compliance Masonry](https://gitlab.com/trustable/overview/wikis/opencontrol-compliance-masonry-example)) to produce consistently up-to-date compliance documentation as the project develops. |
|
|
\ No newline at end of file |
|
|
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 |