IT:AD:Continuous Delivery:SAD:05. Functional View

• (UP) – Previous (User View) – Next (Information View)

The solution is comprised of one or more custom Extensions uploaded into an online Extension Catalogue (the Visual Studio Marketplace) configured to minimize the effort required of individual project teams – whether internal or external to the organisation – to configure their Build Management Service to meet organisation accreditation expectations.

The solution is designed to take advantages of as much of the functionality already available within the organisation specified ALM Service's Build Management Service, while remaining highly uncoupled from the underlying infrastructure.

The Application Lifecycle Management (ALM) Service provides several key services required for continuous delivery of valuable and tested software to end users.

These services include:

• Work Item Management Service: to manage Agile Work Items (Epics, Features, Stories, Tasks, Bugs).
• Version Control Service: to manage the versioning and integration of change to code, configuration, and documentation produced.
• Build Management Service: to manage Build Configurations which define how to pull code from the Version Control Service and build artefacts.
• Release Management Service: to manage the Release Configurations which define when and where to publish built artefacts to.
• Test Management Service: to manage the manual testing required to determine what to automate.

The Work Item Management Service manages the Work Items (Tasks) of Projects developed by Teams of Users.

The service allows for Agile Work Items to be managed on a shared team Kanban Board as Epics, Features and User Stories + Acceptance Tests, and Bugs:

The functionality provided by the above ensure the following requirements are met:

• REQ-xxxx: Development projects must be managed, developed, tested and deployed, supported and enhanced using Agile tools and approaches.

The ALM Service's Version Control Service manages a distributed versioned code repository that is clonable to developer workstations.

The Version Control Service is used by projects to manage and version:

• Source Code
• Configuration Templates
• Deployment Templates
• Development Documentation

The Version Control Service is directly used by the following Roles:

• Project Development Roles, which depending on the size of the project will be one or more of the following:
  • Internal Organisation Development Role
  • External Vendor Development Role(s)
• External Review Role (Security and Maintainability Code Review)

In no circumstance is the Version Control Service to be used to manage sensitive data and artefacts:

• Copies of all or partial Production Data
• Certificates
• Security Tokens/Passwords/Keys
• Confidential Information

The functionality provided by the above ensure the following requirements are met:

• REQ-xxxx: Solution source artefacts must be managed using a a distributed version control repository.
• REQ-xxxx: Development policies must be in place to limit the persisting of any form of production data to the ALM Service.

As part of the ALM Service's functionality, VSTS provides a Build Management Service.

It is comprised of a hosted Build Controller, which manages a Build Queue of queued Build Jobs, which are spooled to a Build Pool of Build Agents.

A Build Job executes a Build Definition which contains a custom sequence of Build Steps selected from a selection of free and open source Visual Studio Extensions available for this purpose from the Visual Studio Marketplace.

An example of a Build Definition comprised of a series of common Build Steps is provided below.

The ability to develop, upload and maintain custom Build Step Extensions to the Visual Studio Marketplace is a key aspect of this solution.

This solution relies on the ongoing development of a custom Build Step, discussed later in this View.

As part of its ALM functionality, VSTS provides a Release Management Service.

The Release Management Service manages Release Definitions which queue the delivery of cached Build Artefacts built by a successful Build (see above) to a target Environment, upon receiving a Signal.

The Signal can be automatic or manual (eg: acceptance by an appropriate stakeholder).

A Deployment Job executes a Deployment Definition which contains a custom sequence of Deployments Steps selected from a selection of free and open source Visual Studio Extensions available for this purpose from the Visual Studio Marketplace.

An example of a Deployment Definition comprised of a series of common Deployment Steps is provided below.

Depending on the Deployment Definitions choice Deployment Steps and their configuration, a Deployment Job deploys to one or more target environments:

As per Organisation Design Specifications, in order to fully take advantage of the lower maintenance processes and cost of PaaS as compared to IaaS, PaaS should be the preferred option for new development projects.

This solution relies on the development of a custom Build Step capable of invoking a series of static text and binary tests.

Organisation Users setting up their project will download the Build Step Extension from the Build Step Catalogue and let the Build Job execute it:

The solution's custom Build Step Extension invokes a series of free and commercial 3rd party tools to develop parts of the final accreditation report artefacts.

A sequence diagram outlining key steps is defined below:

The results of the various tests run by the Console applicatoin are consolidated into a common report available to Accreditation Services.

The report will provide to Accreditation Services a report that outlines the factual readiness of an application for deployment using production data*.

Requirements: * REQ-xxxx: Accreditation Reports for all Builds should be persisted. * REQ-xxxx: Accreditation Reports for Systems deployed with access to live data must be persisted. * REQ-xxxx: Persisted Accreditation Reports must be accessible by Accreditation Services.

• This could maybe be done in a first instance by attaching the Reports to an Email so that they are persisted in the Accreditation Service Role's Email server. A dedicated website could be envisioned later.