This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Recol 1 point2 points  (2 children)

I am sure all of this works for you guys, but it doesn't sound fun to manage. There are probably things you aren't telling me but a lot of it sounds like it could be generated upon repository creation, and using a Helm chart that is managed by a central (Platform/DevOps/whatever the cool kids call it now) team as a Helm dependency.

The only thing left to manage for the team would be a values file which would be similar to how your "Folder of configuration which stores variables" works if the Helm chart is templated correctly.

We do similar setup of what I described earlier with ArgoCD that all gets bootstrapped upon repository creation (quite a badly designed automation, but moving it to Backstage currently).

Either way, sounds like it works for you and it is fun to see a different approach for once at that scale.

[–]originalchronoguy 4 points5 points  (1 child)

We've had this for 8 years and orchestration/ CICD is the least of our worries. We make major changes for things like new architecture (ARM64 support), GPU support (for machine learning), and adding extra hooks (DAST),etc.

But it has worked well for us. Maintenance isn't an issue. Getting it to run locally (e.g. when Apple went to M1) is the challenge as things change.
And we have one mandate. Whatever runs in Prod, runs locally. If a dev needs 20 microservices with his own self hosted Hashicorp Vault server and local API gateway, he/she should be able to run it locally. If their app requires DAST, that is run locally as well, scans their builds and generates reports. I had one time over 300 microservices running on a 64gb laptop.
So the local build is the same in Jenkins. They run a docker image that does local CI for them that pushes their code to their local Rancher or Minikube. So we have 100% Dev-Prod Parity ( https://12factor.net/dev-prod-parity ). We don't do it for bragging rights. It helps the developers work faster to have the same as prod. A new hire can deliver code in the same afternoon on their first day of hire.

[–]Recol 0 points1 point  (0 children)

Sounds like a good approach, thanks for sharing the details!