← Back to home

Infrastructure & deployment

CI/CD & Infrastructure

A deployment case study about making releases repeatable enough that rollback is planned, boring, and tied to source state.

GitHub Actions · Docker · AWS · Terraform 2025

SUMMARY

Deployment patterns across Nover and personal repos: lint, test, build, tag by commit SHA, push, deploy, and make rollback a known path.

Problem

Manual deployment paths make every release a memory test and every rollback a fresh improvisation.

What I built

I worked with CI/CD and deployment flows that lint, test, build, tag images by commit SHA, push artifacts, and deploy through a predictable path.

Architecture / system design

The deploy flow keeps source state, image identity, environment update, and rollback path connected through commit SHA and automated checks.

Failure modes / what broke

The breaks this pattern addresses are ambiguous image versions, skipped tests, manual server drift, and rollback steps nobody rehearsed.

Proof / metrics / tests

The original page frames this as worked-with infrastructure rather than a standalone product metric.

Lessons learned

A deployment path is part of the product. If rollback is vague, the release is not really finished.

field notes

Expanded field notes

WHY INFRASTRUCTURE MATTERS HERE

Infrastructure is where backend systems become real. Containers, CI, environment configuration, deploy paths, and rollback options decide whether shipping is a nervous event or a normal one. I'm an early-career engineer who cares about that part on purpose.

Across my personal and team projects, I try to set things up so deploys ride an automated path instead of living in someone's terminal history. Concretely: GitHub Actions for lint/test/build, container images tagged by commit SHA, infrastructure described in code (Terraform where it makes sense), and rollouts that can be reverted by reverting a commit.

At Nover, the part I contribute to follows that pattern: GitHub Actions runs tests, builds a Docker image, pushes it to a registry, and triggers a rolling update — gated by branch protection. I'm not the only person touching this; I'm describing the slice I've worked on.

For personal and open-source repos I use lighter-weight versions of the same idea: Actions for CI, Docker Compose for local-to-staging parity, and Nginx with Let's Encrypt for TLS termination on self-hosted services. The principle I try to hold onto: if a human has to remember a deploy step, the pipeline isn't done yet.

PHILOSOPHY

A deploy should be boring. If your heart rate goes up when you push to main, the pipeline is telling you something. Tests, container builds, and a one-commit rollback path do most of the work; the rest is discipline.

IaC
terraform where it earns its place
SHA
images tagged by commit, not "latest"
revert
rollback = revert + redeploy
CI/CD pipeline architecture git push · pull request · branch protection github actions lint · test · build docker build tag: commit SHA ECR / registry versioned images terraform plan → apply blue-green rolling update production GPU fleet · web nginx · let's encrypt TLS termination rollback revert commit → redeploy solid = deploy path · dashed = infra / rollback
fig. 6 — git push → CI → container build → blue-green deploy, with one-commit rollback.

hover or tab through any node to trace the deploy path

contact

Open to backend systems, AI infrastructure, and product engineering roles.

yehiasaidgewily@gmail.com GitHub LinkedIn