From 070926285de2b5e79f5c825403c8bd139cb45582 Mon Sep 17 00:00:00 2001 From: Eleri Valiant Date: Fri, 28 Nov 2025 15:44:06 +0000 Subject: [PATCH 1/7] First draft of policy --- .../Lifecycle/DecommissionGuidance.md | 0 .../Lifecycle/LifecyclePolicy.md | 54 +++++++++++++++++++ 2 files changed, 54 insertions(+) create mode 100644 software-engineering-policies/Lifecycle/DecommissionGuidance.md create mode 100644 software-engineering-policies/Lifecycle/LifecyclePolicy.md diff --git a/software-engineering-policies/Lifecycle/DecommissionGuidance.md b/software-engineering-policies/Lifecycle/DecommissionGuidance.md new file mode 100644 index 000000000..e69de29bb diff --git a/software-engineering-policies/Lifecycle/LifecyclePolicy.md b/software-engineering-policies/Lifecycle/LifecyclePolicy.md new file mode 100644 index 000000000..3c7bc9d31 --- /dev/null +++ b/software-engineering-policies/Lifecycle/LifecyclePolicy.md @@ -0,0 +1,54 @@ +# Software Lifecycle Management Policy + +## Purpose + +This policy ensures that all software systems are designed, developed, deployed, maintained, and retired in a consistent, secure, and efficient manner aligned with organizational standards. + +## Scope + +This policy applies to all software engineers, contractors, and teams involved in developing or maintaining internal or customer-facing software. + +## Policy Requirements + +### Planning & Design + +- All new software must include documented requirements, architecture diagrams, and risk assessments. +- Designs must consider security, scalability, observability, and maintainability. +- [Naming conventions](../NamingConventions/NamingConventions.md) must be defined and followed consistently. + +### Development + +- Code must be version-controlled using approved [source control](../SourceControl/SourceControl.md) solutions. +- Code must follow established [coding standards](../CodingStandards/CodingStandards.md). +- Code must be peer reviewed in line with [code review policy](../CodeReview/CodeReviewPolicy.md). +- [Secure Development](../SecureDevelopment/SecureDevelopment.md) practices must be followed to mitigate vulnerabilities. +- Automated testing (unit, integration, and security checks) must be implemented before merge. + +### Testing & Quality Assurance + +- Testing must include unit, integration, system, and security tests. +- Testing should be automated where possible, following the [test strategy](../QualityAssurance/TestStrategy.md). +- Test coverage and results should be documented and reviewed. +- Performance and load testing should be conducted for critical systems. + +### Deployment & Release Management + +- Deployment pipelines must comply with the [pipeline policy](../Pipelines/Baseline_Policy.md). +- Rollback procedures must be defined and tested. +- IaC (Infrastructure as Code) practices should be used for environment provisioning. + +### Operational Maintenance + +- Teams must monitor system performance, security alerts, and error logs. +- Critical vulnerabilities must be remediated within defined SLAs. +- [Technical debt](../TechnicalDebt/TechnicalDebt.md) should be periodically reviewed and addressed. + +### Documentation + +- Architecture, APIs, deployment steps, and dependencies must be kept up-to-date. +- [System documentation](../SystemDocumentation/SystemDocumentation.md) must be comprehensive and accessible. + +### Decommissioning + +- Software approaching End-of-Life (EOL) must have a documented migration or decommission plan. For more information, refer to the [decommission guidance](../Lifecycle/DecommissionGuidance.md). +- Data retention and disposal must comply with organizational and regulatory requirements. From fbd142cfcefe1e2f6e1e2382f52914e175957362 Mon Sep 17 00:00:00 2001 From: Eleri Valiant Date: Fri, 19 Dec 2025 12:04:15 +0000 Subject: [PATCH 2/7] Updated from review comments --- .../Lifecycle/LifecyclePolicy.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/software-engineering-policies/Lifecycle/LifecyclePolicy.md b/software-engineering-policies/Lifecycle/LifecyclePolicy.md index 3c7bc9d31..d145c37a1 100644 --- a/software-engineering-policies/Lifecycle/LifecyclePolicy.md +++ b/software-engineering-policies/Lifecycle/LifecyclePolicy.md @@ -12,8 +12,9 @@ This policy applies to all software engineers, contractors, and teams involved i ### Planning & Design -- All new software must include documented requirements, architecture diagrams, and risk assessments. -- Designs must consider security, scalability, observability, and maintainability. +- All new software must include documented requirements, architecture diagrams, threat models and risk assessments. +- Designs must consider security (ref. [POL201 - Secure by Design](https://ukho.sharepoint.com/sites/docstore-prd/_layouts/15/Doc.aspx?sourcedoc=%7BD068DDEC-D0A6-49A6-AA88-B16D4A3B6A30%7D&file=POL201.docx&action=default&mobileredirect=true&DefaultItemOpen=1)), scalability, observability, and maintainability. +- Designs should be peer reviewed to identify any sharable components. - [Naming conventions](../NamingConventions/NamingConventions.md) must be defined and followed consistently. ### Development @@ -35,13 +36,14 @@ This policy applies to all software engineers, contractors, and teams involved i - Deployment pipelines must comply with the [pipeline policy](../Pipelines/Baseline_Policy.md). - Rollback procedures must be defined and tested. -- IaC (Infrastructure as Code) practices should be used for environment provisioning. +- [IaC (Infrastructure as Code) practices](../InfrastructureAsCode/terraform.md) should be used for environment provisioning. ### Operational Maintenance -- Teams must monitor system performance, security alerts, and error logs. -- Critical vulnerabilities must be remediated within defined SLAs. +- Teams must monitor system performance, security alerts, and error logs as per the [observability policy](../observability/observability_policy.md). +- Critical vulnerabilities must be remediated within defined SLAs (ref. [POL218 - Patch Management Policy](https://ukho.sharepoint.com/sites/docstore-prd/_layouts/15/Doc.aspx?sourcedoc=%7B82EA818D-00AA-44EE-B9A1-E901879DE72E%7D&file=POL218.docx&action=default&mobileredirect=true&DefaultItemOpen=1)). - [Technical debt](../TechnicalDebt/TechnicalDebt.md) should be periodically reviewed and addressed. +- Disaster recovery procedures must be defined and tested. ### Documentation From a3ebb847f6e16dc93e5e832cd47e4b50368db8da Mon Sep 17 00:00:00 2001 From: Eleri Valiant Date: Mon, 16 Feb 2026 12:27:05 +0000 Subject: [PATCH 3/7] Rough notes in guidance --- .../Lifecycle/DecommissionGuidance.md | 68 +++++++++++++++++++ 1 file changed, 68 insertions(+) diff --git a/software-engineering-policies/Lifecycle/DecommissionGuidance.md b/software-engineering-policies/Lifecycle/DecommissionGuidance.md index e69de29bb..858be5d93 100644 --- a/software-engineering-policies/Lifecycle/DecommissionGuidance.md +++ b/software-engineering-policies/Lifecycle/DecommissionGuidance.md @@ -0,0 +1,68 @@ +## Things to consider when decommissioning a service + +When decommissioning a service, consider the following aspects as part of your impact assessment. + +### Communication + +- Service owners and product owners are the key decision makers on when a service should be decommissioned. +- Stakeholders should be informed of decommissioning activities well in advance. + +### Service + +### Data + +Consider any data that the service holds and whether this needs to be migrated to another system or archived before decommissioning. + +### Upstream/downstream + +Consider impacts to upstream and downstream systems and services. Notify relevant teams of decommissioning plans. +Assess tests (functional, E2E, performance etc) that may be impacted by the decommissioning. + +### Monitoring + +SolarWinds alerts and dashboards should be removed once the service is decommissioned. + +- API pollers +- Nodes +- Credentials (and supporting Entra identities if applicable) +- Panels in dashboards + +### Documentation + +- Green tiles + +### Resources + +- Entra identities +- Access packages +- Elastic +- Azure subscription & resources +- DNS entries + +### References + +Think about references in external systems: + +- App Register +- PMP +- Tech Radar + +Add a decommission report to the Github repository and link to it from the readme.md file. +Archive Github repository. + +## Azure DevOps + +Depends on project. Some service owners might want to keep their Azure DevOps project for historical reference, while others might want to delete it entirely. + +If keeping: + +- Decommission pipelines, environments, variables. +- Remove team members from the project. + +If deleting: + +- Ensure all necessary documentation and reports are saved elsewhere before deletion. + +## Examples + +[Content Delivery Service](https://github.com/UKHO/content-delivery-service?tab=readme-ov-file) - decommission report linked at the top of the README. From e7f4ef037714b3d4c2e623d95f2bb06556bb7b0d Mon Sep 17 00:00:00 2001 From: Eleri Valiant Date: Thu, 12 Mar 2026 13:03:31 +0000 Subject: [PATCH 4/7] Finish wording on decommission guidance --- .../Lifecycle/DecommissionGuidance.md | 40 ++++++++++++------- 1 file changed, 25 insertions(+), 15 deletions(-) diff --git a/software-engineering-policies/Lifecycle/DecommissionGuidance.md b/software-engineering-policies/Lifecycle/DecommissionGuidance.md index 858be5d93..7ec7f51cf 100644 --- a/software-engineering-policies/Lifecycle/DecommissionGuidance.md +++ b/software-engineering-policies/Lifecycle/DecommissionGuidance.md @@ -1,13 +1,11 @@ -## Things to consider when decommissioning a service - When decommissioning a service, consider the following aspects as part of your impact assessment. -### Communication +## Communication - Service owners and product owners are the key decision makers on when a service should be decommissioned. - Stakeholders should be informed of decommissioning activities well in advance. -### Service +## Service ### Data @@ -29,40 +27,52 @@ SolarWinds alerts and dashboards should be removed once the service is decommiss ### Documentation -- Green tiles +Documentation should be removed or updated to reflect the decommissioning of the service. Consider that documentation in dependent services may also need to be updated. + +- Documentation in Github repositories +- Documentation in Azure DevOps wiki +- 'Green tiles' ### Resources +Resources that are no longer needed should be removed to avoid unnecessary costs. Consider the following which may need removing or updating. + +- Azure subscription & resources +- Azure spoke configuration - Entra identities - Access packages - Elastic -- Azure subscription & resources - DNS entries +- Firewall rules +- SSL certificates +- Grafana dashboards and alerts ### References -Think about references in external systems: +We have a number of tools which will need to be updated. Consider the following. - App Register - PMP - Tech Radar -Add a decommission report to the Github repository and link to it from the readme.md file. -Archive Github repository. - ## Azure DevOps -Depends on project. Some service owners might want to keep their Azure DevOps project for historical reference, while others might want to delete it entirely. +What needs to be done in Azure DevOps will depend on the project. Some service owners might want to keep their Azure DevOps project for historical reference, while others might want to delete it entirely. -If keeping: +If keeping the project: -- Decommission pipelines, environments, variables. +- Decommission pipelines, environments, variables, service connections. - Remove team members from the project. -If deleting: +If deleting the project: - Ensure all necessary documentation and reports are saved elsewhere before deletion. +## Final updates to Github repository + +- Add a decommission report to the Github repository and link to it from `readme.md`. +- Archive the Github repository. + ## Examples -[Content Delivery Service](https://github.com/UKHO/content-delivery-service?tab=readme-ov-file) - decommission report linked at the top of the README. +[Content Delivery Service](https://github.com/UKHO/content-delivery-service?tab=readme-ov-file). From 9a34900fcd4be3d591f14f152374ecb753958d73 Mon Sep 17 00:00:00 2001 From: Eleri Valiant Date: Thu, 12 Mar 2026 17:43:04 +0000 Subject: [PATCH 5/7] Fixed review comments --- .../Lifecycle/DecommissionGuidance.md | 5 +++-- .../Lifecycle/LifecyclePolicy.md | 12 ++++++------ 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/software-engineering-policies/Lifecycle/DecommissionGuidance.md b/software-engineering-policies/Lifecycle/DecommissionGuidance.md index 7ec7f51cf..6e5072f66 100644 --- a/software-engineering-policies/Lifecycle/DecommissionGuidance.md +++ b/software-engineering-policies/Lifecycle/DecommissionGuidance.md @@ -27,7 +27,7 @@ SolarWinds alerts and dashboards should be removed once the service is decommiss ### Documentation -Documentation should be removed or updated to reflect the decommissioning of the service. Consider that documentation in dependent services may also need to be updated. +Documentation should be archived or updated to reflect the decommissioning of the service. Consider that documentation in dependent services may also need to be updated. - Documentation in Github repositories - Documentation in Azure DevOps wiki @@ -37,7 +37,8 @@ Documentation should be removed or updated to reflect the decommissioning of the Resources that are no longer needed should be removed to avoid unnecessary costs. Consider the following which may need removing or updating. -- Azure subscription & resources +- Azure service subscriptions & resources +- Resources outside of service subscription e.g. shared service key vaults. - Azure spoke configuration - Entra identities - Access packages diff --git a/software-engineering-policies/Lifecycle/LifecyclePolicy.md b/software-engineering-policies/Lifecycle/LifecyclePolicy.md index d145c37a1..99659e964 100644 --- a/software-engineering-policies/Lifecycle/LifecyclePolicy.md +++ b/software-engineering-policies/Lifecycle/LifecyclePolicy.md @@ -19,16 +19,16 @@ This policy applies to all software engineers, contractors, and teams involved i ### Development -- Code must be version-controlled using approved [source control](../SourceControl/SourceControl.md) solutions. -- Code must follow established [coding standards](../CodingStandards/CodingStandards.md). +- Code must be version-controlled using approved [source control](../SourceControl/SourceControlPolicy.md) solutions. +- Code must follow established [coding standards](../CodingStandards/README.md). - Code must be peer reviewed in line with [code review policy](../CodeReview/CodeReviewPolicy.md). -- [Secure Development](../SecureDevelopment/SecureDevelopment.md) practices must be followed to mitigate vulnerabilities. +- [Secure Development](../SecureDevelopment/SecureDevelopmentPolicy.md) practices must be followed to mitigate vulnerabilities. - Automated testing (unit, integration, and security checks) must be implemented before merge. ### Testing & Quality Assurance - Testing must include unit, integration, system, and security tests. -- Testing should be automated where possible, following the [test strategy](../QualityAssurance/TestStrategy.md). +- Testing should be automated where possible, following the [test strategy](../quality-assurance/test-strategy.md). - Test coverage and results should be documented and reviewed. - Performance and load testing should be conducted for critical systems. @@ -42,13 +42,13 @@ This policy applies to all software engineers, contractors, and teams involved i - Teams must monitor system performance, security alerts, and error logs as per the [observability policy](../observability/observability_policy.md). - Critical vulnerabilities must be remediated within defined SLAs (ref. [POL218 - Patch Management Policy](https://ukho.sharepoint.com/sites/docstore-prd/_layouts/15/Doc.aspx?sourcedoc=%7B82EA818D-00AA-44EE-B9A1-E901879DE72E%7D&file=POL218.docx&action=default&mobileredirect=true&DefaultItemOpen=1)). -- [Technical debt](../TechnicalDebt/TechnicalDebt.md) should be periodically reviewed and addressed. +- [Technical debt](../TechnicalDebt/TechnicalDebtPolicy.md) should be periodically reviewed and addressed. - Disaster recovery procedures must be defined and tested. ### Documentation - Architecture, APIs, deployment steps, and dependencies must be kept up-to-date. -- [System documentation](../SystemDocumentation/SystemDocumentation.md) must be comprehensive and accessible. +- [System documentation](../SystemDocumentation/SystemDocumentationPolicy.md) must be comprehensive and accessible. ### Decommissioning From a344e8cb3623a892cd55eafbd48fddc3dc40453d Mon Sep 17 00:00:00 2001 From: Eleri Valiant Date: Thu, 12 Mar 2026 17:44:46 +0000 Subject: [PATCH 6/7] Need to go up another level for relative link for test strategy --- software-engineering-policies/Lifecycle/LifecyclePolicy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/software-engineering-policies/Lifecycle/LifecyclePolicy.md b/software-engineering-policies/Lifecycle/LifecyclePolicy.md index 99659e964..72a9adb92 100644 --- a/software-engineering-policies/Lifecycle/LifecyclePolicy.md +++ b/software-engineering-policies/Lifecycle/LifecyclePolicy.md @@ -28,7 +28,7 @@ This policy applies to all software engineers, contractors, and teams involved i ### Testing & Quality Assurance - Testing must include unit, integration, system, and security tests. -- Testing should be automated where possible, following the [test strategy](../quality-assurance/test-strategy.md). +- Testing should be automated where possible, following the [test strategy](../../quality-assurance/test-strategy.md). - Test coverage and results should be documented and reviewed. - Performance and load testing should be conducted for critical systems. From 05d92dbe046e2c8be6afdb9fdb4a58e752fb2265 Mon Sep 17 00:00:00 2001 From: Eleri Valiant Date: Thu, 12 Mar 2026 17:47:31 +0000 Subject: [PATCH 7/7] Observability link cares about case? --- software-engineering-policies/Lifecycle/LifecyclePolicy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/software-engineering-policies/Lifecycle/LifecyclePolicy.md b/software-engineering-policies/Lifecycle/LifecyclePolicy.md index 72a9adb92..6e8425d45 100644 --- a/software-engineering-policies/Lifecycle/LifecyclePolicy.md +++ b/software-engineering-policies/Lifecycle/LifecyclePolicy.md @@ -40,7 +40,7 @@ This policy applies to all software engineers, contractors, and teams involved i ### Operational Maintenance -- Teams must monitor system performance, security alerts, and error logs as per the [observability policy](../observability/observability_policy.md). +- Teams must monitor system performance, security alerts, and error logs as per the [observability policy](../Observability/observability_policy.md). - Critical vulnerabilities must be remediated within defined SLAs (ref. [POL218 - Patch Management Policy](https://ukho.sharepoint.com/sites/docstore-prd/_layouts/15/Doc.aspx?sourcedoc=%7B82EA818D-00AA-44EE-B9A1-E901879DE72E%7D&file=POL218.docx&action=default&mobileredirect=true&DefaultItemOpen=1)). - [Technical debt](../TechnicalDebt/TechnicalDebtPolicy.md) should be periodically reviewed and addressed. - Disaster recovery procedures must be defined and tested.