#compliance (2023-08)
| Discuss topics related to compliance. See also <#CBXSAR45B | security>. |
2023-08-15
2023-08-17
2023-08-29
For keeping up with CVEs and Hotfixes, I’m curious if any one keeps separate “maintenance” environments for that fast development/testing.
For a simple example, lets say you have environments:
• dev
• test
• stage
• prod But then you get a CVE which needs to be patched fast, but there are unstable/unapproved features in dev+test:
• so you can’t promote the current build up to stage/prod, even if it is patched Instead you need another “maintenance” environment which holds the same version as stage+prod and you do any hotfix/CVE testing there. In my case, I’d need 2 environment: “maintenance dev” and “maintenance test”
From an application release engineering perspective, we offer a hot fix environment, which is pre production, but post staging. In other words a way to test changes to a current release, even if trunk has moved forward. We have not tried this with infrastructure.
Thanks. Our challenge is a large cluster with 150+ namespaces and some heavy resource requirements. So some development can’t be done locally. To develop the fixes (for the code we write, not third-party images) we appear to need additional environments.
I’ve tackled this at small scale in the past and we’re chinstroking about how to handle it at my current place. My suspicion is that being able to roll a single staging environment forward and back across versions to represent prod, or possible deltas from prod, is more efficient than the significant expense and complexity of another environment… but obviously this is context dependent