I'm new to Kubernetes, and hence helm, so I've been reading a lot, and teaching myself by setting up a cluster, services, deployments, and pods. In my case I use AWS EKS.
I now at least understand each piece from a technical point of view. But now I want to put it all together in managing an "environment." I believe this is the idea behind GitOps.
Say I'm a QA person and am testing a "staging" environment. This environment comprises a number of microservices with their own respective versions. So logically I can represent it this way
/staging-2021-03-06-4 # 4th build of staging environment on 2/06/2021 - microservice1:1.1.0 - microservice2:1.2.0 - microservice3:1.3.0
When we build the next staging, e.g,
staging-2021-03-06-5, anyone of those microservices versions can change.
But now I, the QA guy, find an issue with above
staging-2021-03-06-4 build, and I ask a developer to look at it. I want to be able to just tell the developer to "check out" the
staging-2021-03-06-4 environment so he/she can have exactly the environment that I have to reproduce the issue.
I'm thinking I can set up this idea of "environment" with
helm, since the "environment" is nothing but a package of packages? Is this the correct utility of
helm? If so, do I just set up a
staging-2021-03-06-4 helm chart that has dependencies of other charts, and those other charts are for each microservice?
I'm also reading How to manage 10+ team environments with Helm and Kubernetes? since it applies to me also, but that describes a different (additional) problem I'm trying to solve with
Update: I think I'm essentially wanting GitOps, so I'll read up on that.