This document describes the Application Development, Release, and Deployment Management Standard Operating Procedure for the National Biomedical Imaging Archive (NBIA), and includes the following sections.

Description

The NBIA Application, Releaseand Deployment Management is the process responsible for planning, scheduling, and controlling the development, build, testing, and deploying application releases. This procedure ensures that the software development team delivers new and enhanced information technologies required by NCI and its collaborators while protecting the integrity of existing services. With the risk-based approach, a project team assesses the risk of the application release to guide the testing and deployment efforts. The risk level assessment should be based on the probability and severity of the likely occurrence of security vulnerabilities, issues with regulatory compliance, the complexity level of the release, and functional and non-functional quality impact of the application.

Objectives

• Do the right level of testing and review of release based on a risk assessment.
• Reduce the time and effort it takes to complete a release.
• Improve coordination throughout the application release and deployment process.
• Improve productivity by establishing standard release process and tooling.
• Support iterative development, active user involvement, and incremental release.
• Communicate the releases to the stakeholders and the user community.

Actors

1. Project Sponsor (PS) –Business owner of the project. Responsible for the requirements of the project.
2. Technical project manager (TPM) – Project manager for the development effort
3. Development team (DEV)
4. Quality Assurance team (QA)
5. Systems Team Representative (STR) – Members of the Systems Team responsible for provisioning DEV, QA, Stage, and Production tiers
6. Security Representative (SR) – Member of the Security Team and responsible for performing security application scans

Standard Operating Procedure

1. The project sponsor proposes a new release.
2. The TPM works with the key project stakeholders to determine the project needs and the content of the release.
3. The DEV team tracks all feature requests and bug fixes in an issue tracking system e.g. JIRA.
4. The DEV team develops the release. Depending on the complexity of the release, the DEV team under the guidance of the technical lead decides to create milestone releases before creating the final release tag.
5. The DEV team deploys the software on the DEV tier.
6. The DEV team completes development testing on the DEV tier.
7. The milestone and/or final release tags are sent to the QA team for verification.
8. QA tier
   • The QA team deploys the software to the QA tier.
   • The QA team performs quality assurance and compliance testing on the release candidates.
   • The QA team submits an AppScan request ticket to the SR team.
   • The QA team provides the SR team a list of test cases that are related to exercising functions that could be affected by security vulnerabilities.
   • The QA team provides the SR team access to all test cases for the application.
   • The SR team runs the Security App Scan on the QA tier and returns results to the QA team and the DEV team.
     • Any high and medium-level vulnerabilities found during the AppScan need to be mitigated by the DEV team and the QA process restarted.
   • The QA team performs a 508 Scan on the QA tier and returns results to the DEV team.
     • Any non-compliance issues found during the scan need to be mitigated by the DEV team.
   • The QA team provides a QA Test Report on the QA tier to the PS for review and approval.
9. Stage tier deployment
   • The DEV team deploys the release to the Stage tier.
   • The QA team performs smoke testing.
   • The TPM coordinates and facilitates user acceptance testing if an UAT is planned.
10. Production tier deployment
    • The DEV team deploys the release to the production tier.
    • The QA team performs smoke testing.
11. The TPM ensures all required documentation and artifacts related to the release exist.
12. The PS informs the stakeholders and user community of the release as needed.