I've created a GitOps solution 4 years ago without knowing the term. We use this to deploying containers to several k8s clusters with several hundred nodes each for factory automation in manufacturing. We now run a 5000 apps on the nodes, more than 100 people have done 37.000 deployments so far - sometimes more than 100 per day. We don't have the problem of multiple pipelines since we cannot simulate the factories anyway. They are too complex. Each deployment touches one or more containers. Sometimes we update a whole fleet with a single commit this way which updates entire production lines. The declarative approach and having git as the source of truth has been a massive benefit especially when upgrading large fleets of apps since we know exactly what runs where, who put it there and when. In an environment with lots of changes this is a significant benefit. We use fleet from rancher to push the deployments to the clusters. We also use only a single repository for all of our k8s clusters. Some older fleet versions have issues in reconciling the state quick enough and our engineers have come to expect that changes are deployed within 60 seconds or less.
@@MarcoLenzo I liked your event driven approach video and we are using this for inspiration to refactor our API driven micro services to be event driven.
Did you manage to create a Continuous Deployment pipeline with the GitOps paradigm?
I've created a GitOps solution 4 years ago without knowing the term. We use this to deploying containers to several k8s clusters with several hundred nodes each for factory automation in manufacturing. We now run a 5000 apps on the nodes, more than 100 people have done 37.000 deployments so far - sometimes more than 100 per day.
We don't have the problem of multiple pipelines since we cannot simulate the factories anyway. They are too complex. Each deployment touches one or more containers. Sometimes we update a whole fleet with a single commit this way which updates entire production lines.
The declarative approach and having git as the source of truth has been a massive benefit especially when upgrading large fleets of apps since we know exactly what runs where, who put it there and when. In an environment with lots of changes this is a significant benefit.
We use fleet from rancher to push the deployments to the clusters. We also use only a single repository for all of our k8s clusters. Some older fleet versions have issues in reconciling the state quick enough and our engineers have come to expect that changes are deployed within 60 seconds or less.
This sounds amazing! You can't imagine how much I'd like to see something of that size in motion.
Thank you very much for the feedback!
@@MarcoLenzo I liked your event driven approach video and we are using this for inspiration to refactor our API driven micro services to be event driven.
@@magiconair I will surely add more content in the future on this topic. Thanks again for the feedback.