DEV Community: IriAndr

A 500 Error Taught Me More Than a Green Checkmark Would Have

IriAndr — Mon, 20 Jul 2026 23:15:57 +0000

I set up my first CI pipeline today. It failed on the first real run —
not because of a typo, but because the pipeline wasn't actually testing
what my app needed. Figuring out why turned into a short debugging
exercise that was more useful than if everything had just passed.

What CI/CD actually means

The idea is simple: instead of manually checking "does this still work?"
every time you push code, you let a server do it automatically.

CI (Continuous Integration) is that automatic check — build the project,
run it, confirm nothing broke. CD (Continuous Deployment) goes a step
further and automatically ships the working version somewhere. This
project only covers CI: making sure the app builds and responds correctly
on every push to main.

The workflow file

GitHub looks for automation instructions in one specific place:
.github/workflows/. Any YAML file there gets picked up automatically.

name: Docker Build

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Start services with docker compose
        run: docker compose up -d --build

      - name: Wait for app to start
        run: sleep 5

      - name: Check app responds
        run: curl --fail http://localhost:5000

      - name: Show logs on failure
        if: failure()
        run: docker compose logs

      - name: Stop services
        run: docker compose down

A quick walk through what happens on every push:

on: push: branches: [main] — this runs automatically whenever something is pushed to main.
runs-on: ubuntu-latest — GitHub spins up a fresh, temporary Ubuntu machine just for this job.
Checkout code pulls the repository onto that machine — without it, there'd be nothing to build.
docker compose up -d --build starts the whole stack, rebuilding the image fresh each time.
A short sleep gives the app time to actually start listening before anything tries to reach it.
curl --fail is the actual test — if the app doesn't respond correctly, this step fails and the whole pipeline turns red.
The logs step only runs if: failure() — it stays silent when everything's fine, and prints container logs when something isn't.
docker compose down cleans up either way.

The first version — and why it failed

My first attempt at this workflow didn't use docker compose at all —
I just reused the command from before I'd added Redis to the project:

      - name: Run container
        run: docker run -d -p 5000:5000 --name test-container hello-flask

It ran. It failed. The error:

curl: (22) The requested URL returned error: 500

A 500 is a specific kind of failure — it means the server responded, but
something broke while handling the request. That ruled out a timing
issue right away; if the app hadn't started yet, curl would have said
"connection refused," not returned an actual HTTP error.

Looking at app.py narrowed it down further. There's exactly one thing
in that file that can throw an unhandled error: the call to Redis.

count = cache.incr("hits")

And that's when it clicked — the app had been updated to require Redis,
but the CI workflow was still starting the app on its own, the way it
used to run before Redis was part of the picture. The container had
nothing to talk to.

The fix — and what it says about testing

The fix was straightforward once the cause was clear: stop starting the
app in isolation, and start the whole stack the same way it actually
runs.

      - name: Start services with docker compose
        run: docker compose up -d --build

This single line replaced the manual docker run step. Instead of
starting one container in isolation, it reads docker-compose.yml and
brings up everything the app actually depends on — in this case, both
web and redis. Once Redis was actually there to answer, the app
stopped failing.

The bigger lesson wasn't really about Docker or YAML syntax. It was that
a CI check is only useful if it tests the thing you actually run. My
first version passed a build check, but it wasn't testing my app — it
was testing an older version of it that no longer existed in the code.

What actually mattered

A 500 error and a connection failure mean different things — the error code itself is a clue
CI configuration can quietly drift out of sync with the actual app, especially when you copy an old command instead of updating it
Adding a logging step for failures (if: failure()) cost nothing to write and will save time the next time something breaks
A pipeline that always passes isn't necessarily testing anything meaningful — this one only became useful once it could actually fail for the right reason

Containers, Compose, and a Counter That Actually Persists

IriAndr — Mon, 13 Jul 2026 11:22:37 +0000

The moment Docker clicked for me wasn't when I ran hello-world. It was
when I understood what a container actually is: not just "your app, but
packaged" — more like a whole room, built exactly to spec, with everything
inside it already arranged. The walls, the furniture, and the app itself
are all part of the same package. You're not just shipping code, you're
shipping the room it lives in.

That idea became a lot more concrete once I built something that needed
two rooms talking to each other.

Building the room — the Dockerfile

A Dockerfile is the blueprint for that room — a step-by-step recipe
that says: start with this foundation, add these tools, put your code
here, and here's how to turn the lights on.

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY app.py .

EXPOSE 5000

CMD ["python", "app.py"]

A few things worth explaining:

FROM python:3.12-slim sets the foundation — a lightweight image that already has Python installed, so I don't have to build an operating system from scratch.
WORKDIR /app sets where everything happens inside the room — every command after this runs from that folder.
COPY requirements.txt . and RUN pip install -r requirements.txt happen before copying the actual app code. That ordering matters: Docker caches each step, so if I only change my app code later, it won't reinstall every dependency from scratch — only the steps after the change get rebuilt.
EXPOSE 5000 documents which port the app listens on inside the container. It doesn't open anything by itself — that happens later, when the container actually runs.
CMD is the last step: what to run the moment the room is occupied — in this case, start the Flask server.

Building the image from this blueprint is one command:

docker build -t hello-flask .

Running a container from it is another:

docker run -d -p 5000:5000 hello-flask

The -p 5000:5000 part maps a port on my machine to a port inside the
container — without it, the app would be running, but there'd be no way
to reach it from outside.

Two rooms, one hallway — docker-compose

One container is simple. But real applications rarely live alone — mine
needed a place to store data that survives beyond a single request. I
added Redis, a key-value store, to keep a visit counter that wouldn't
reset every time the app restarted.

This meant two containers now had to run together and talk to each other.
That's what docker-compose.yml is for:

services:
  web:
    build: .
    ports:
      - "5000:5000"
    depends_on:
      - redis

  redis:
    image: redis:alpine

build: . tells Compose to build the web service from my Dockerfile,
the same way I did manually before. image: redis:alpine does the
opposite — instead of building anything, it just pulls Redis's official,
lightweight image.

The part that actually made everything click was realizing how the two
containers find each other. It's not through the ports section — that
only maps my machine to the web container, and has nothing to do with
web talking to redis. The real connection happens because Compose
automatically creates a shared network between all the services in the
file, and inside that network, each container can be reached by its
service name.

That's why the app code just does this:

cache = redis.Redis(host="redis", port=6379)

"redis" isn't a placeholder — it's the literal name of the service
from the compose file. No IP addresses, no manual network configuration.
Docker handles the discovery on its own.

With both files in place, starting everything is one command:

docker compose up -d

Compose reads the file, starts redis first (because of depends_on),
then builds and starts web. Refreshing the page a few times confirmed
it was actually working:

Hello from Docker! This page has been viewed 8 times.

The count kept climbing with every refresh — proof that the state was
living in Redis, not disappearing every time the page reloaded.

An unexpected git detour

Pushing this project to GitHub hit a snag that had nothing to do with
Docker. I'd created the GitHub repository with an auto-generated README,
then tried to push my local commits on top of it:

! [rejected]        main -> main (fetch first)
error: failed to push some refs to '...'

Git was refusing to overwrite history it didn't recognize — my local
repo and the GitHub repo had each started with their own independent
first commit, so there was nothing connecting them yet. The fix was to
pull the remote history in and let Git combine the two:

git pull origin main --allow-unrelated-histories --no-rebase

That flag exists specifically for this situation — Git normally refuses
to merge two histories with no common ancestor, as a safety measure
against accidentally combining unrelated projects. Since I knew exactly
why these two histories had diverged, it was safe to allow it. No
conflicts came up this time, just a merge commit to confirm, and the
push went through right after.

Small reminder that most of the real learning in this stuff doesn't
come from the parts that go smoothly.

What I learned

Before this, Docker felt like a black box — something everyone in DevOps
uses, but hard to picture without actually building something with it.
Writing a Dockerfile from scratch and connecting two containers through
Compose made it concrete.

A few things stuck with me:

The order of steps in a Dockerfile matters, not just for correctness but for how efficiently images rebuild
Containers in the same Compose file find each other by service name, not by ports or IP addresses
Not every problem along the way is about the tool you're learning — sometimes it's just Git, doing what Git does

My First Git Merge Conflict (On Purpose)

IriAndr — Sun, 12 Jul 2026 11:51:31 +0000

Today I did something I'd only read about before: I created a Git merge
conflict on purpose, and then resolved it by hand. I wanted to understand
exactly what happens when two branches change the same line differently —
not just memorize the commands, but actually see the process.

Branches basics

A branch in Git is just a separate line of work. It lets you make changes
without touching the main codebase until you're ready to merge them back.

To create a new branch and switch to it in one command:

git checkout -b feature/add-greeting

The -b flag tells Git to create the branch first, then switch to it.
You can confirm which branch you're on with:

git branch

The current branch is marked with an asterisk.

One thing that confused me at first: why checkout? It sounds like
something you'd do at a library, not something related to branches.
Turns out that's exactly the idea — checkout comes from a "check out
a book" metaphor. You're telling Git "give me this version of the files."
Git even introduced a newer, clearer command for this — git switch —
because checkout historically does too many different things and
confuses beginners. But checkout -b is still what most tutorials and
teams use, so it's worth knowing first.

First merge — the easy one

Once my branch had a commit, I switched back to main and merged it in:

git checkout main
git merge feature/add-greeting

I expected this to be more dramatic. Instead, Git just said "Fast-forward"
and moved on. No conflict, no drama.

Here's why: a conflict only happens when two branches diverge from the
same point and change the same content independently. My feature branch
was just sitting on top of main with nothing new happening on main in the
meantime — so Git could simply "fast-forward" main to match the branch,
no merging required.

That's when I realized: to actually see a conflict, I'd need to make main
and my branch disagree about something, on purpose.

Creating a real conflict on purpose

My first attempt to force a conflict didn't work either. I edited
greeting.txt on main, committed it, then created a new branch and
edited the same file there too:

git checkout -b feature/change-greeting

Still no conflict — another fast-forward. The reason: I'd created this
branch after the change on main, so there was still no real divergence,
just a straight line of commits.

To actually diverge, my branch needed to start from a point before the
latest change on main. I checked the commit history:

git log --oneline

and created a new branch from an earlier commit, not the latest one:

git checkout -b feature/real-conflict a0ae0d3
echo "Hello from a truly diverging feature!" > greeting.txt
git add greeting.txt
git commit -m "Diverging change from feature"

Now main and feature/real-conflict had both changed the same line of
greeting.txt, independently, from the same starting point. Merging them
finally produced what I was looking for:

git checkout main
git merge feature/real-conflict

CONFLICT (content): Merge conflict in greeting.txt
Automatic merge failed; fix conflicts and then commit the result.

Resolving the conflict

Opening the conflicted file showed something like this:

<<<<<<< HEAD
Hello from main - second edit!
=======
Hello from a truly diverging feature!
>>>>>>> feature/real-conflict

Git can't decide which version is "correct" — both are valid changes, made
independently — so it inserts both versions directly into the file,
wrapped in markers, and leaves the decision to you.

Here's what each marker means:

<<<<<<< HEAD — start of the version on your current branch
======= — separator between the two versions
>>>>>>> feature/real-conflict — end of the version from the branch you're merging in

The markers themselves aren't part of your code — they're temporary, and
Git expects you to remove them before committing. I opened the file in
nano (a simpler alternative to vim for anyone just starting out),
deleted the marker lines, decided what the final content should be, and
saved.

Then it's just a normal commit:

git add greeting.txt
git commit -m "Resolve merge conflict in greeting.txt"

Running git log --oneline --graph afterward made the whole story visible
at once — the branches splitting apart and merging back together at the
conflict resolution commit.

Pull Request workflow

Resolving conflicts locally is one thing, but in real teams, changes
usually go through a Pull Request first — a place for review before
anything reaches main. I wanted to go through that flow too, even
working solo.

After cleaning up my practice branches, I created a fresh one for an
actual feature:

git checkout -b feature/add-notes
echo "This repo is my Git practice playground." > notes.md
git add notes.md
git commit -m "Add notes about this repo"
git push origin feature/add-notes

Pushing for the first time meant dealing with authentication — GitHub
no longer accepts a regular account password for Git operations. Instead,
you need a Personal Access Token, generated from GitHub's developer
settings and used in place of a password. Once I set
credential.helper store, Git remembered it for future pushes.

The push output included a direct link to open a Pull Request. From
there, the GitHub interface shows exactly what a reviewer would see:
a diff of changed files, commit history, and a merge button — in my case,
with "No conflicts with base branch," since this change didn't overlap
with anything else.

Clicking "Merge pull request" combined the branch into main, and
GitHub offered to delete the now-unused branch. Back in the terminal,
one command brought my local copy up to date:

git checkout main
git pull origin main

What I learned

Before today, "merge conflict" was one of those phrases that sounded
scarier than it turned out to be. Once I saw what it actually looks
like — two versions of the same line, wrapped in plain markers, waiting
for a decision — it stopped being abstract.

A few things:

Conflicts only happen when branches genuinely diverge, not just because you're working on separate branches
The conflict markers are just text — nothing to be careful around, just something to read and clean up
The PR workflow exists for a reason: even solo, going through it made the whole process feel less like typing commands and more like actually working the way teams do

Why I'm Learning DevOps in Public

IriAndr — Fri, 10 Jul 2026 19:35:03 +0000

I just installed WSL2, set up Ubuntu, and ran my first Docker container.
Nothing groundbreaking — but it's the start of something I want to document
properly, so here we are.

Why DevOps

I want to work as a DevOps engineer, ideally starting with an internship.
Right now I'm at the very beginning: comfortable with a computer, but new to
Linux, containers, and most of the tooling this field runs on.

Why write about it

Two reasons. First, writing forces me to actually understand what I did,
not just copy-paste commands that happened to work. Second, English isn't
my first language, and technical writing is a good way to practice it
while doing something useful.

What to expect here

I'll be posting as I go through each stage:

Linux and the terminal
Git and GitHub workflows
Docker, from basics to docker-compose
CI/CD with GitHub Actions
Kubernetes basics
Infrastructure as Code with Terraform

Some posts will be short notes, others will be closer to tutorials, written
the way I wish someone had explained it to me.

If you're on a similar path, feel free to follow along.