DevOps Engineer

DevOps Engineer

DevOps practice through my own build and deploy workflows

I have not held a DevOps Engineer title yet. What I do have are repeated reps with GitHub Actions, Docker Compose, build validation, and deployment notes across my own projects.
  • GitHub Actions: linting, type-checking, and build validation before deploys.
  • Docker Compose: repeatable local environments for Node, Python, and Zig experiments.
  • Deployment checks: personal workflows that stop deploys when builds fail.
  • Documentation: READMEs that spell out missing health checks, rollback gaps, and manual steps.
Honesty upgrade

Clear scope, upfront

What I have

  • Personal CI scripts and deployment checklists for personal projects.
  • Local Docker Compose labs to practice repeatable environments.
  • Documentation practices that record failures and remediation steps.

What I am still working toward

  • Ownership of production CI/CD workflows or multi-team delivery pipelines.
  • Rollback drills and approvals in a real shared delivery environment.
  • Deeper observability stacks beyond basic logs and alerts.

What I’m doing next

  • Required checks and manual approvals before deploy steps in sandbox workflows.
  • Monitoring practice beyond Lighthouse and console logs.
  • Policy-as-code exercises for secrets and access control.
Reality snapshot

What 'DevOps' means in my world today

Personal automation (public)

Most of my DevOps practice comes from automating my own releases and making small projects harder to break.

  • GitHub Actions pipelines run linting, type-checking, and build validation before publishing to Netlify or GitHub Pages.
  • Docker Compose labs to standardize Node, Python, and Zig tooling in local development environments.
  • Scripts and deployment notes documented in repository READMEs.

Guided exposure (lab-style)

The AWS internship added some operational context, but it was still guided exposure rather than owning shared pipelines for a team.

  • AWS internship exposure to ticket triage and CloudWatch dashboards in lab-style environments.
  • Guided rotations only; no ownership of production changes or independent resolution of live customer tickets.
Work samples

Evidence (student/volunteer level)

Docker Multilang

This project is less about shipping an app and more about standardizing local environments so onboarding and repeatability are easier.

  • Compose file standardizes Node, Python, and Zig tooling for onboarding.
  • Manual smoke tests are used in place of automated test suites; README documentation lists missing health checks.
  • GitHub Actions builds images and runs linting before merge or deploy steps.

Proof links: Containerization notes

Portfolio deploys

This is where most of my practical CI/CD work shows up today: personal sites, demos, and deploy checks that block obvious mistakes.

  • Netlify and GitHub Pages workflows validate builds before publishing personal sites and templates.
  • Accessibility and Lighthouse checks run via CLI scripts.
  • Build failures block deployments until issues are resolved.

Proof links: CI/CD workflow notes

Tools in rotation

What I'm practicing (always with AI pair-programming)

GitHub Actions — personal CI basicsNetlify CLI — personal deploysDocker / Docker Compose — local dev labsAWS CLI labs — lab onlyBash scripting — local automationTerraform — tutorial stagek6 smoke tests — local only

Each repository documents which tools are operational, experimental, or planned to indicate maturity and reliability.

Help wanted

Where I still need guidance

  • Designing CI/CD for teams bigger than me, including approvals and rollback plans.
  • Monitoring stacks beyond Lighthouse + console logs (e.g., Prometheus, Grafana).
  • Hardening secrets management and policy-as-code beyond .env files.
  • Incident response drills inside real production environments.

If you are hiring for junior DevOps or platform roles and provide coaching in these areas, I am open to discussing opportunities.