When CityBase recently implemented Kubernetes and GitHub Actions to automate some of its internal processes, the company aimed to save time and money.
Both came true — and then some, according to the government tech platform’s Director of Engineering Gabriel Taylor Russ.
Russ said the two technologies have freed up about two to four hours of developer time daily and helped them save thousands of dollars per month on compute cloud bills.
More importantly, Russ said, was the change in his team’s overall satisfaction at work.
“After implementing this automation, we perceived an immediate positive impact on morale as developers were engaged in more high-value thought work,” Russ said.
But automation doesn’t always lead to positive outcomes like Russ and his team observed.
When teams don’t have a clear understanding of the processes they aim to automate, automation can be more of a hindrance than a solution, he said.
Built In Chicago connected with Russ to learn the specifics behind CityBase’s new automation processes and why he swears by always implementing a manual process before even considering automation.
serving constituents
How did your team leverage Kubernetes and GitHub Actions for automation?
Russ: Using Kubernetes and a custom web application, we’ve been able to scale each developer’s Kubernetes namespace up and down with a single click and to schedule scaling before developers start and after developers finish work. This helps us reduce the compute resources required to run our non-production environments and thus, reduce our operating costs.
We’ve been GitHub users for a long time at CityBase, but with the introduction of GitHub Actions, we’ve been able to add time-saving automation to our development processes. We use GitHub Actions to run automated test suites; lint our code; compile our applications; build and push Docker containers to our cloud container store; publish release notes; merge trivial pull requests automatically after they are approved; and reduce the file size of image assets, among other things.
Possibly our most complex GitHub Action pipeline is a series of actions we use to deploy applications. The first GitHub Action is triggered when we add a tag to one of our repos. It creates a release in GitHub for the tag and builds the release notes before attaching them to the release. The creation of a release triggers another GitHub Action, which dispatches a message with metadata about the application we want to deploy. The message is consumed by an Action on another repository where we store application configuration for applications deployed in Kubernetes. This action uses the metadata passed in the message to create a pull request, updating the application configuration with the updated version of the application we intend to deploy.
Unless you know the process well, it’s probably too soon to automate it.”
What effect has this automation had on your business?
We conservatively estimate that we save two to four hours of developer time every day through our most complex GitHub Action and many more hours through others. Automating these processes gives our team the opportunity to focus on more interesting tasks. After implementing this automation, we perceived an immediate positive impact on morale as developers were engaged in more high-value thoughtwork.
Through our use of Kubernetes, and the automated and manual scaling it has facilitated, we have reduced our cloud compute bills by thousands of dollars a month and at the same time empowered developers to get more done without having to request additional resources or support from our site reliability engineering team.
Where do you draw the line when it comes to automation?
When it comes to automation, it is often prudent to implement a manual process first before considering how parts of this process and eventually the whole process can be automated. This minimum viable process allows you to gather feedback from those who use it and to better understand which steps lend themselves to automation and which consume the most time. These will be good candidates to tackle first as you start to automate. This is also a great time to record measurements of the current process with respect to time, cost or another metric that makes sense for your use case. These measurements will help you validate the return on the time spent when automating the process.
In this sense, I draw the line between those processes I understand and for which there is a battle-tested manual process and those for which there is not. Unless you know the process well, it’s probably too soon to automate it.
