Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
79 changes: 79 additions & 0 deletions software-engineering-policies/Lifecycle/DecommissionGuidance.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,79 @@
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

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
- '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 service subscriptions & resources
- Resources outside of service subscription e.g. shared service key vaults.
- Azure spoke configuration
- Entra identities
- Access packages
- Elastic
- DNS entries
- Firewall rules
- SSL certificates
- Grafana dashboards and alerts

### References

We have a number of tools which will need to be updated. Consider the following.

- App Register
- PMP
- Tech Radar

## Azure DevOps

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 the project:

- Decommission pipelines, environments, variables, service connections.
- Remove team members from the project.

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).
56 changes: 56 additions & 0 deletions software-engineering-policies/Lifecycle/LifecyclePolicy.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
# 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, 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

- 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/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](../../quality-assurance/test-strategy.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](../InfrastructureAsCode/terraform.md) should be used for environment provisioning.

### Operational Maintenance

- 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.

### Documentation

- Architecture, APIs, deployment steps, and dependencies must be kept up-to-date.
- [System documentation](../SystemDocumentation/SystemDocumentationPolicy.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.
Loading