December 2022 — on the difference between saying you can do something and having the git history to prove it

The first question any serious technical employer asks is: “Can I see something you’ve built?”

A CV full of bullet points — “experience with Docker”, “familiar with Kubernetes”, “worked with CI/CD pipelines” — is noise. Every candidate has those. What cuts through is a link. A repository. A pipeline that runs. Code that deploys itself.

My wife is intelligent, motivated, and was moving into IT work. She had built her own website. She understood the basics. What she didn’t have was the infrastructure to demonstrate it credibly — the kind of setup that signals to a hiring manager or a client: this person understands how software actually gets to production.

So I built it for her. Then I showed her how it worked and why. She did the rest.

What we built

The setup is straightforward in the right way: it does exactly what a professional deployment pipeline does, no more and no less.

git push → GitLab CI → Docker build → image push → kubectl apply → live site

Every commit to her website repository triggers a pipeline. The pipeline builds a Docker image, tags it with the branch name and commit SHA, pushes it to GitLab’s container registry, and applies Kubernetes manifests that update the running deployment. No manual FTP. No SSH into a server and git pull. No “it works on my machine.”

The pipeline

Here’s the actual .gitlab-ci.yml:

image: docker:20.10.16

services:
  - name: docker:20.10.16-dind
    alias: docker
    command: ["--tls=false"]

variables:
  GIT_SUBMODULE_STRATEGY: recursive
  DOCKER_HOST: tcp://docker:2375
  DOCKER_TLS_CERTDIR: ""

stages:
  - build_docker
  - cluster_res
  - apps

create_docker:
  stage: build_docker
  tags:
    - kubernetes
  script:
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN registry.gitlab.com
    - docker build -t registry.gitlab.com/chebna/chebna-website/chebnaeu:"$CI_COMMIT_BRANCH"_AMD64_"$CI_COMMIT_SHORT_SHA" -f chebna.eu/Dockerfile .
    - docker push registry.gitlab.com/chebna/chebna-website/chebnaeu:"$CI_COMMIT_BRANCH"_AMD64_"$CI_COMMIT_SHORT_SHA"

regsecret:
  stage: apps
  tags:
    - kubernetes
  image: djieno/alpine-curl-kubectl:amd64
  script:
    - kubectl apply -f manifests/regsecret.yml --kubeconfig=${KUBECONFIG_CHEBNA}

chebna-eu:
  stage: apps
  needs: [regsecret]
  tags:
    - kubernetes
  image: djieno/alpine-curl-kubectl:amd64
  script:
    - sed -i "s/_CI_COMMIT_BRANCH_/$CI_COMMIT_BRANCH/g" manifests/develop.chebna.eu.yml
    - sed -i "s/_COMMIT_SHORT_SHA_/$CI_COMMIT_SHORT_SHA/g" manifests/develop.chebna.eu.yml
    - kubectl apply -f manifests/develop.chebna.eu.yml --kubeconfig=${KUBECONFIG_CHEBNA}

Three stages. Build the image. Ensure the registry pull secret exists in the cluster. Apply the manifests with the correct image tag substituted in.

The image tag format — main_AMD64_a7c3f8d — means every deployment is traceable back to an exact commit. If something breaks, you know precisely what changed and when. That’s not ceremony; that’s how production systems work.

What she learned

I didn’t hand her a magic box. I walked through each piece:

• The Dockerfile — how a website becomes a container image. What the layers mean. Why you copy dependencies before source code (caching).
• The pipeline — what triggers it, what each stage does, how the variables work. Why $CI_JOB_TOKEN can authenticate to the registry without storing a password.
• The Kubernetes manifests — what a Deployment is, what a Service is, why the image tag matters for rollouts.
• The registry pull secret — why the cluster needs credentials to pull from a private registry and how that works.

None of this is beyond someone who is curious and motivated to understand. The barrier isn’t intelligence. It’s exposure. Most people learning to code are never shown the deployment side of the equation because tutorials stop at “it runs on localhost.”

What happened next

She put it on her resume and her profile. Not “familiar with CI/CD” — she linked the repository. She could explain exactly what the pipeline did and why each step existed.

She landed several high-paying freelance contracts. Clients hiring for IT work — web projects, internal tools, digital presence — were used to candidates who could build things but couldn’t deploy them, or who could deploy things but couldn’t explain the process. Someone who could do both, and show the working code, stood out.

The actual lesson

The technical setup here is not impressive by enterprise standards. A three-stage GitLab pipeline deploying to a small Kubernetes cluster is table stakes.

What’s impressive is ownership: having a thing that runs, that you understand, that deploys itself when you commit. That’s the difference between knowing about a technology and having used it to solve a real problem.

The pipeline is the portfolio. The repository is the interview. The commit history is the CV.

If you’re helping someone get into technical work, don’t just teach them syntax. Set them up with infrastructure that shows their work. Give them a pipeline. Show them how it works. Then get out of the way.

The motivation has to be theirs. The tools can be yours to set up. But the commits — and everything that follows — that’s on them.