DEV Community: Benjamin Godfrey

Homemade CI/CD Pipeline - Part 1: Git

Benjamin Godfrey — Thu, 12 Feb 2026 16:27:09 +0000

Week 1: Demystifying the Remote

This past week marked the official start of my DIY CI/CD pipeline project. My first goal was to come up with a way to manage git repos.

I wanted to host my code without relying on GitHub or GitLab. When I clone a repo at work, the address usually looks something like this:

git clone git@github.com:path/to.git

Looking at that through the lens of a Linux terminal, it’s clearly just pointing to a path on a machine via SSH. I had a hunch that setting up my own remote server couldn't be as simple as just pointing to a folder on a spare machine.

It turns out, it really is that easy.

The "Aha!" Moment

Realising that Git is essentially just a series of file transfers over SSH was a massive confidence boost. It’s easy to look at a project like "building a CI/CD pipeline" and feel overwhelmed by the scale, but this early win reminded me that I already understand the core technologies at play. I’m just putting them together in a new way.

To manage this, I’ve put together a few Bash scripts to handle my Git settings and repository initialisation.

You can find the current scripts in the src/scripts directory of my project repo here: CI-CD-BG on GitHub.

The Road Ahead: From SSH to HTTP?

Now that the "Store" part of the pipeline is working, I’m venturing into the unknown.

Currently, I have to manually SSH into the server to run my management scripts. For the next phase, I’m considering setting up a lightweight HTTP server. The goal is to be able to trigger my build and test scripts via webhooks or simple HTTP requests rather than maintaining a manual SSH session.

This moves the project from "running scripts on a box" to "building a service," and I’m excited (and slightly terrified) to see how it holds up.

Homemade CI/CD Pipeline - Part 1: Git

Benjamin Godfrey — Thu, 12 Feb 2026 16:27:09 +0000

Week 1: Demystifying the Remote

This past week marked the official start of my DIY CI/CD pipeline project. My first goal was to come up with a way to manage git repos.

I wanted to host my code without relying on GitHub or GitLab. When I clone a repo at work, the address usually looks something like this:

git clone git@github.com:path/to.git

It turns out, it really is that easy.

The "Aha!" Moment

To manage this, I’ve put together a few Bash scripts to handle my Git settings and repository initialisation.

You can find the current scripts in the src/scripts directory of my project repo here: CI-CD-BG on GitHub.

The Road Ahead: From SSH to HTTP?

Now that the "Store" part of the pipeline is working, I’m venturing into the unknown.

This moves the project from "running scripts on a box" to "building a service," and I’m excited (and slightly terrified) to see how it holds up.

Overengineering: A Series

Benjamin Godfrey — Sat, 31 Jan 2026 20:55:32 +0000

I want to make a CI/CD pipeline. Going in to this project I understand that whatever solution I could make would not be nearly as usable, reliable, or feature rich as existing options. Despite this, I want to give it a go.

There are a few reasons for this. Firstly, from my (possibly incorrect) viewpoint as a junior dev, I think that what is most important for me is to understand the fundamentals and the tools that I use. I know how to go through the process of commiting, pushing, making a PR and merging, but given a blank terminal I would struggle to remake that process. Add to this the exposure to networking, scripting, and automated tests, and I think the picture becomes very clear.

Secondly, I think that self hosting where possible is a good thing. Sure, my GitHub profile probably won't be deleted and take with it all of my previous projects, but you never know. If I can host my repos on some device that I own then I won't need to rely on any third party, and I won't need to send packets halfway around the world to access my own projects.

Thirdly, I think it would make an interesting series of blog posts. My plan is to take on this project in weekly sprints, and to review progress at the end of each of these sprints. With this in mind, we could call this first post my sprint planning.

The first step of any project: figure out what I actually want to achieve. When I say that I want a CI/CD pipeline, what do I mean? Well,

I need a place for my repos to live. GitHub and Gitlab exist, but as stated, I would prefer to keep this on my own network. Functionality here can be minimal, especially at the start. A directory on a machine somewhere on my LAN will do.
I want some series of events to happen when I push to main.
A build should be created. This will most likely be in a docker container, or at least it will be to start with.
After a build is created, it should be tested. This should be everything from unit tests to end to end automated testing. Maybe even some SecOps stuff, just to spice it up.
If anything fails (in the build or test stages), the whole pipeline should rollback. This probably means I need to keep builds somewhere in storage.
If everything is ok, we are sorted. Deploy the build to some container.

Even in writing this list I have found a few areas that will require research. I guess this is kind of the point. I will spend the next week filling in any gaps in knowledge that would block initial progress, and also trying to figure out how much time I can actually afford to put into this project.

Thus far, no blockers.