Member-only story
How GitOps works for us
From manually deployed monoliths to containers and GitOps with Weaveworks Flux
Over the last couple of years we’ve been running a number of projects creating new services, and migrating existing services to a new platform we’re building. We’ve been working very heavily with containers as our packaging and deployment mechanism, and using Kubernetes as our orchestrator. During this time we’ve been beefing up our Continuous Integration processes, and looking at how automation can help with deployment.
Historically we’ve had a lot of software that’s been deployed manually, and this has lead to many common issues — it takes time and resource we’d rather be using for other things; it can be error prone and require a lot of trouble shooting; and it often requires detailed knowledge of what’s where and how to safely upgrade. We very quickly realized that with the technologies we were using, this problem could easily grow if we didn’t change our way of working, but that equally these same technologies opened the door and reduced the friction of embracing newer techniques and processes to help us embrace Continuous Delivery.
Our goal is to make deployments — whether of a large-scale distributed system, a complex production environment, an embedded system, or an app — predictable, routine affairs that can be performed on demand. — Jez Humble, continuousdelivery.com
In this article I’ll be talking about part of the Continuous Delivery journey we’ve been on, how we use requirements and experiments to derive the best solution for us, and specifically Weaveworks Flux, which has turned out to be our tool of choice.
Analysing our requirements
Before we started creating a solution, we created a simple list of the requirements for our deployment solution, based on the challenges we were looking to resolve. These requirements would allow us to judge the success of the processes and tools that we used during our experiments. The list of requirements we came up with was:
- We wanted to spend less of our time fighting broken or complex deployments!
- We wanted to have our deployed configurations controlled and versioned, ideally with a lightweight approval process.
