We are not considering features for DTGov 2.0, and have decided to take a usecase driven approach, with the following being an initial set. Please feel free to comment on these use cases as well as suggest any further ones that may be of interest.

One of the goals of these usecases is to reduce the burden on develpers, so they don't need to explicitly deal with additional governance technology. The aim is to inform them when issues have arisen that need to be dealt with, provide them with an 'appeal' procedure if they consider the issue to be unwarranted, but at the same time ensure that only validated artifacts are promoted through the deployment lifecycle and eventually into production. So although some users may still have the ability to upload artifacts into sramp, an organisation should be able to decide that they only want binary artifacts that have passed certain governance policies to be uploaded.

DTG2-UC-1: Create a project

• Create “project” representation to encompass artifacts of interest. This will include the location(s) of the source of the project (e.g. GIT repo, other SCMs, Dropbox, Drive, filesystem, etc).
• Configure appropriate event publishers for those source locations (e.g.  “commit hook” and “PR submitted hook” in GIT repo), to report events to DTGov.

DTG2-UC-2: Validate file in GIT repo (e.g. WSDL for WS-I profile compliance)

• When file of interest is changed, “commit/PR hook” sends event to DTGov to trigger validation policies (e.g. WS-I profile conformance validation on WSDL).
• If no issues are found (across all triggered policies), then any existing markers should be cleared (markers stored as internal knowledge against the artifact).
• If issues are found, then:
  • if new issue (i.e. no existing marker for same artifact and issue type), then create a marker and notify relevant user (supplying artifact, responsible user and event information)
    • note: would be good if notifier module can understand that artifact is in git repo, and event is related to a commit or PR, and therefore determine that it can inform the user by annotating the commit/PR. i.e. Use context based knowledge to work out the most appropriate notification mechanism. [May also require git repo authentication access?]
    • default notification to users should be configurable - e.g. email by default, but also text, twitter, etc.
  • if known issue, then depending upon configuration, can potentially ignore (so don’t continuously inform user of known situations). If using comments on commit/PR, then may need to apply each time, to ensure user does not forget to fix the issue.

DTC2-UC3a: Request waiver for highlighted issues

• If a PR or commit is commented upon, to highlight an issue with an artifact, the developer can simply fix the issue and recommit/submit PR to clear the issue.
• However, they may wish to request a waiver for the issue, to allow the issue to be ignored. With the git integration, it should be possible for the developer to respond to the command with a simple command, e.g. Governance: <command> - such as “Governance: waiver because I want one”.
• This will trigger further policies in DTGov to obtain the appropriate approval or denial, which will be returned as a further reply to the commit.

NOTE: Other communication channels may also be used in the same way, e.g. twitter?

DTC2-UC3b: Issuing a waiver for ignored issues

• Git repo is tagged, event reported to DTGov.
• If known issues still exist with artifact(s) contained in the project (i.e. git repo), then human task should be created for appropriate authorised person to determine whether the project should be permitted to proceed, or whether it will be rejected pending the outstanding issues being fixed. (May be could be handled by the person listing the outstanding issues in a UI and marking them individually, or as selected groups, as waived).
• If outstanding issues remain with no waiver, then “workflow” should terminate with a suitable messaging being sent to the project manager.
• Otherwise project should proceed to the next stage.

NOTE: The relevance of this usecase is that there may be an ordering (dependency) between different ‘policies’ executed for a particular event. This particular policy would be evaluated prior to DTC2-UC4, to determine if the project should be built and uploaded to SRAMP.

DTG2-UC-4: Tagged source to release binary artifact

• If GIT repo is tagged, and version is not a snapshot, then trigger workflow:
  • trigger release build CI job (this job should only be triggered explicitly via workflow)
  • once job completed, if successful, then upload binary artifact into SRAMP

DTC2-UC5: Obtain an overview of a project and its issues

• UI available to enable users to review outstanding issues with a project, and who the responsible individuals are. Project configuration should also identify stakeholders, and managers for the individual areas of responsibility, to help with escalation procedures.

NOTE: We may want to include support for external issue management systems (e.g. jira) to provide tracking of some or all of the issues detected.