Reducing Code Duplication in GitHub Actions Workflows (1/2)

#cicd #devops #node #githubactions

We use GitHub Actions to set up our CI/CD. The infra team (they renamed themselves to 'DevOps' a few years ago 🤔) set up a pool of runners for us and shared the IaC (Infrastructure as Code) repository for provisioning them.

- "Hey devs, here you go. Now you can install and run whatever you need in your pipelines"

Since then, I’ve been trying to improve our workflows (pipelines).

Here’s the thing: the YAML file is code. And like any other piece of code, it can benefit from clean code principles.

I don’t consider myself a clean code advocate anymore. I mean, I used to be that nick-piti kind of guy, but now I think I’ve grown... wiser🧙‍♂️?

Some code duplication? yep, fine. Some abstractions? over-engineering.

simpler >> canonically cleaner.

Anyway, reducing code duplication is generally speaking a good thing.

And reducing code duplication in your Github Actions workflows is a good thing 👍

What we have

Two workflows: release.yaml & deploy.yaml.

First, let’s clarify terms—because no, they’re not interchangeable. this question:

"What does a release mean?"

...It depends. 🤷‍♂️

In the context of this post -> a web front-end application; I like to picture the output of each workflow:

Release

Build the Docker image and publish it to our image registry (with the appropriate tag).

Input: the code base.
Output: nn image -we use Docker specifically- for instance awesome-front-app:1.0.3 + (recommended) a tag on git.
- What's in the image: the application (production build) ready to be served by a web server.

Deploy

Deploying –again, in this context– means updating the Kubernetes (K8s) config to use that fresh image tag. You edit the image field in the deployment YAML file to point to the updated tag (in this example, awesome-front-app:1.0.3).

Then, K8s pulls the new image and rolls it out, gradually swapping out the old pods for the new ones.

Input: deployment YAML file.
Output: the server is running the new version.

So, we’ve got these action workflows, and just like any other code, there can be improvements. Some of the tasks in both the release.yaml and deploy.yaml were repeating themselves.

...Alright, this post is already getting longer than I expected. I’ll stop here for now.
In the next post, I’ll dig into actual GitHub Actions changes I made to reduce code duplication in those workflows. Stay tuned! 🚀

thanks for reading.