A series of steps to take into account when shutting down/archiving a project from a DevOps/SRE viewpoint
1. Disable/remove monitoring services for the project
- Eliminates spurious alerts after deleting the releases.
- Reduces cognitive load in the on-call person and downstream developers that may not be aware of the change
2. Remove the deployments
These can include (charts, containers, manifests, binaries in a server, etc.), preferably in order: I. review envs II. staging/sandbox envs III. production envs
- That gives you the chance of detecting hidden dependencies that need to be dealt with, potentially in lower impact scenario
3. Delete any associated DNS records
Should take into account not only, CNAME and A records, but also dedicated TXT (usually used for verification) and MX records (for email)
- If automated, they may be removed alongside the deployments
- Dedicated DNS entries not managed through the deployments (e.g manually configured or through Terraform)
- Static IPs
- If superseded by a new project, redirect links instead to the new product/deployment
4. Proceed to archive deployment artifacts
- helm charts, k8s and related manifests
- env vars & secrets
- git/mercurial/svn repository
These can be valuable for auditing, tracking and history purposes
5. Create final backup and delete downstream infra resources:
- Databases
- Storage (dedicated disks, buckets, NFS folders)
- Dedicated users or permissions
The final backups will allow you to deploy the project once again if needed for rollback reasons, comparison or testing
6. Archive/remove documentation associated with the project
- API docs
- User/Dev docs
- Remove index entries from internal search DB engines
- Redirect links to docs to new version or to an information page stating that the project is no longer available
Notes
- In certains scenarios, it may make sense to completely erase the archives after a period of time