Promotion of Infrastructure changes?

[danielloader]

Hello all, thanks for this example repository.

The project seems to be making the assumption that infrastructure components are static, with only the apps themselves having cluster differences.

Is there a pattern in mind that addresses how you'd do a progressive rollout of infrastructure?

Would you just copy the apps model of having cluster sub directories?

Just wondering how you'd change the redis release from say 16.x to 17.x without it reflecting on the entire estate.

Just spitballing but I guess you could do strategic merges in the cluster directory Kustomization objects to change the version, though that's a method for only adjusting the shared infrastructure in a sharded way, it wouldn't necessarily facilitate adding of a completely new service you want to deploy to staging only to check the performance impact etc.

I think I've basically talked myself into the apps/ example being used for infrastructure/ but any other comments or insights on this usecase would be welcome.

[mereck]

Just wondering how you'd change the redis release from say 16.x to 17.x without it reflecting on the entire estate.

One approach is to deploy another version of redis as another hr with a different name, then point your apps to that new hr as needed. When no more apps point to the old hr, remove it.