GitOps
A few weeks ago I went to the Vancouver DevOps Meetup, which was my first in person meetup in a long time. Didn’t know a single person there, but it was good to see people talking about interesting. Also thank you Best Buy for the pair of Airpods I won in the door prize raffle.
The really interesting part for me was the talk on GitOps, which basically is doing everything through Git. This was one of my favourite things at GitHub, which didn’t use the name GitOps (as far as I’m aware) but did everything through GitHub as either code or issues.
- Want to change DNS settings? Create a pull request.
- Want to spin up a new service? Drop in a pull request with the configuration changes.
- Want to hire someone? Open an issue.
- Want to re-organize and change teams? Create a pull request.
- Want access to a new service, or remove access? Create a pull request.
All GitHub infrastructure was managed in GitHub. Configuration for services were stored in Git. To change something, you created a pull request with the changes. It would get reviewed by the appropriate teams. When the pull request is merged, then CI would kick off a new deployment with the changes.
Putting everything into GitHub providing a consistent interface that everyone understood, a consistent notification and review interface, an audit log and so on. This would be consistent across all the tooling. The power of this consistency here can’t be understated. If you don’t use this approach you are stuck on the learning curve as you figure out the UI, the API, the terminology and so on. That’s removed by having it all in one place.
Of course, it’s not perfect since often tooling needs to be built to allow this to happen. File formats and configuration will vary across teams and tools, so sometimes it’s not completely obvious what changes need to be made. Sometimes deploys would happen automatically, sometimes you need to run commands - that sort of thing.
And of course, it’s important to ensure that deploys are easy and easy to rollback with appropriate tooling and reviews are in place to ensure that something terrible doesn’t happen. No-one wants to send in PR and accidentally break the main DNS entries for GitHub (as an example).
This was one of the cooler things about working at GitHub and I missed it at other places.