Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add in application path to production process #94

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Add in application path to production process #94

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ae99d3c
Add in application path to production process
Jun 21, 2021
8ce5736
Update source/ways-of-working/path-to-live/application-approval-produ…
cakeben Jun 21, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions source/ways-of-working/path-to-live/application-approval-production.html.md.erb
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
---
title: Application approval into Production
last_reviewed_on: 2021-06-21
review_in: 6 months
---

# <%= current_page.data.title %>

This guide explains the typical processes an application team must ensure their app has been through before getting the green light to deploy to production

1. OAT - Operational acceptance testing covers multiple topics to try and ensure that your application is ready to go into production, it evidences topics such as best practices, avoiding anti-patterns, scalability, disaster recovery etc.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not really sure if best practices and avoiding anti-patterns should be included in here too vague, is that actually included as well?

Suggested change
1. OAT - Operational acceptance testing covers multiple topics to try and ensure that your application is ready to go into production, it evidences topics such as best practices, avoiding anti-patterns, scalability, disaster recovery etc.
1. OAT - Operational acceptance testing covers multiple topics to ensure that your application is ready to go into production, it include topics such as scalability, disaster recovery, logging, best practices, avoiding anti-patterns.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth including the OAT confluence link here?


you will need to contact the Release and Transition team with a proposed go live date and they will create the templated tickets for your consumption.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how do you contact them?


Platform Operations ask for a few weeks notice and a few weeks leeway from your desired go live date.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's be more specific feel free to change dates

Suggested change
Platform Operations ask for a few weeks notice and a few weeks leeway from your desired go live date.
Platform Operations ask for at least three weeks notice and minimum three weeks from your desired go live date.


Platform Operations role in OAT is to raise any risks that the application might pose on any of the topics covered in the OAT and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sentence is unfinished?


[OAT Ticket Sample](https://tools.hmcts.net/jira/browse/RBC-7754)

2. ITHC
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could maybe add this somewhere? https://www.gov.uk/government/publications/it-health-check-ithc-supporting-guidance/it-health-check-ithc-supporting-guidance


an IT Health check is akin to a penetatration/vulnerability scanning test conducted by the Security team
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use plain english

Suggested change
an IT Health check is akin to a penetatration/vulnerability scanning test conducted by the Security team
an IT Health check is like a penetration/vulnerability scanning test conducted by the Security team


3. Tech Readiness Sign Off

After OAT & ITHC is completed and usually 1-2 weeks before the proposed go live date, a tech readiness call will be arranged and chaired by the Release and Transition team
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
After OAT & ITHC is completed and usually 1-2 weeks before the proposed go live date, a tech readiness call will be arranged and chaired by the Release and Transition team
After OAT & ITHC is completed, usually 1-2 weeks before the proposed go live date, a tech readiness call will be arranged and chaired by the Release and Transition team


The tech readiness is a chance for Business/Product Owners, Platform Operations, Programme Leads, Security and Release and Transition to raise any risks or approve the release for production
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The tech readiness is a chance for Business/Product Owners, Platform Operations, Programme Leads, Security and Release and Transition to raise any risks or approve the release for production
The tech readiness is a chance for Business/Product Owners, Platform Operations, Programme Leads, Security and Release and Transition to raise any risks and decide whether to approve the release for production


4. Authority to Operate

an Authority to Operate or AtO will be given after a successful ITHC and subsequent approval from the Tech Readiness meeting, this is granted by the CISO
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is ATO after tech readiness? I thought ATO was as a result of ITHC being signed off?


Best Practices:

We discourage big bang deployments and encourage deploying components like infrastructure earlier than the proposed release dates to streamline the go live and as an opportunity to catch any unknowns ahead of the release date
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
We discourage big bang deployments and encourage deploying components like infrastructure earlier than the proposed release dates to streamline the go live and as an opportunity to catch any unknowns ahead of the release date
We strongly discourage big bang deployments and recommend deploying components like infrastructure and applications earlier than the proposed release dates to streamline the go live and as an opportunity to catch any unknowns ahead of the release date

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth mentioning the use of feature toggling here to hide features in production that the product teams don't want to enable? this may be one of the causes of teams not merging their code to the main/trunk.


For application deployments to production via Jenkins you will need your repo included here [Environment Approvals] (https://github.com/hmcts/cnp-jenkins-config/blob/master/environment-approvals.yml)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth mentioning that frontends can be deployed as shuttered and un-shuttered on day of go-live. And Backends can be made accessible with a PR merge to register dns/ add to Appgw in Azure-platform-terraform.

In short, all for deploying app (Adding infra, flux config could be done ahead of time ), but not sure at what point we allow approving those PRs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this needs to be made clear as part of this so we know what we should be approving.

We also briefly discussed during one of the tech improvements sessions:
a) do we want to keep these approval files at all
b) do we say people can add to them at any point?


For infrastructure deployments via Jenkins you will need to have a read through [Terraform Infra Approvals] (https://github.com/hmcts/cnp-jenkins-config/tree/master/terraform-infra-approvals) and seek approval way ahead of time