Add in application path to production process #94
Conversation
|
|
||
| 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 | ||
|
|
||
| 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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
source/ways-of-working/path-to-live/application-approval-production.html.md.erb
Outdated
Show resolved
Hide resolved
…ction.html.md.erb Co-authored-by: Tim Jacomb <[email protected]>
|
|
||
| This page explains the typical processes an application team must ensure they/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. |
There was a problem hiding this comment.
not really sure if best practices and avoiding anti-patterns should be included in here too vague, is that actually included as well?
| 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. |
There was a problem hiding this comment.
Is it worth including the OAT confluence link here?
|
|
||
| 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. | ||
|
|
||
| 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. |
|
|
||
| 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. | ||
|
|
||
| Platform Operations ask for a few weeks notice and a few weeks leeway from your desired go live date. |
There was a problem hiding this comment.
let's be more specific feel free to change dates
| 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 ask for a few weeks notice and a few weeks leeway 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 |
|
|
||
| [OAT Ticket Sample](https://tools.hmcts.net/jira/browse/RBC-7754) | ||
|
|
||
| 2. ITHC |
There was a problem hiding this comment.
could maybe add this somewhere? https://www.gov.uk/government/publications/it-health-check-ithc-supporting-guidance/it-health-check-ithc-supporting-guidance
|
|
||
| 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 |
There was a problem hiding this comment.
| 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 |
|
|
||
| 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 | ||
|
|
||
| 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 |
There was a problem hiding this comment.
| 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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
| 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 |
There was a problem hiding this comment.
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.
|
|
||
| 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 | ||
|
|
||
| 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) |
There was a problem hiding this comment.
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?
Before creating a pull request make sure that:
Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
Change description
Does this PR introduce a breaking change? (check one with "x")