Beyond the “Pipeline” Metaphor

What is a pipeline

Continuous Integration and Continuous Delivery (CI/CD) are two halves of the software delivery process. However, referring to this process as a “pipeline” is an oversimplification, as there is rarely a single source or a fixed end point.

A more accurate comparison is global automotive manufacturing. Developers act as part suppliers, shipping individual components to a central facility where incoming packages are checked against quality and build specifications. This represents Continuous Integration (CI): developers commit code to a shared repository, which automatically triggers a battery of testing suites.

Go in Comparison

Python is a great starting point for general programming and scripts. But when automation needs reliably across nodes, containers, or CI/CD pipelines, its additional layers slows it down. That is why infrastructure, Kubernetes, Docker, and Terraform are built in Go.

Bash shell scripting is a closely aligned to Go, in terms of its benefit and purpose. I believe Go is quicker to pickup and start using. However, more understanding is required to distinguish the differences.

Quick Guide

I use Hugo to build this blog site. It is lightweight, simple to pickup and thematically leans into the Linux way of building. Hugo creates static sites and is designed for performance. It has a strong templating support and allows for re-use and fast implementation. Hugo runs in terminal and has all functionality (and is actually practical) from CLI, very unusual for [current year].

Let’s run through some important hugo commands:

Introduction

This is a beginner taster course, I’m going to use Ansible to deploy and configure a basic web server. I’ll cover the core concepts and we should understand how it works and its place in a DevOps toolbox.

Pros:

• Easy to read
• Uses SSH rather than an Agent ()
• quick to deploy consistent configuration across hundreds of linux servers

Cons:

• Limited Windows support - (can’t install directly but can with WSL2)
• Being procedural, can cause errors in very large (thousands) or complex infrastructure (dynamic micro servers).

Use-cases

Introduction

The minimum circumstances where Kubernetes becomes a logical choice usually fall into three categories: Infrastructure Complexity, Operational Scale, and Business Requirements.

Complexity Thresholds

If your “site” is a single monolith or just two containers (App + DB), Kubernetes is almost certainly overkill. It starts to make sense when you have many services that need to talk to each other, manage their own secrets, and scale independently. The manual effort of managing them on individual virtual machines (VMs) becomes higher than the effort of running K8s.

Introduction

Purpose: documenting learning, experience and investigations using this personal and technical blog.

I have decided to create this using Hugo and LoveIt theme due to the impactful experience with consistent structure. Learning and self-development often goes overlooked and under valued - I am the worse culprit!

Taking time to process and formally write up my own words both helps to cement learning and offer resources to others interested in the DevOps Journey.