LCTRT

My Past in Devops

I started learning some modern devops tools and practices recently. I heard someone say that it’s important to not just learn the “how” but also the “why” of technology. That’s something I can relate to, learning something just because it’s shiny is fun, but hard to sustain if there’s no compelling case for using it. Since devops is not my first tech work I have some pain points I already know I want to solve. After more than a decade in software engineering, I want to explore new skills and challenge myself. While doing that I’ve been thinking about my past experience in devops adjacent tasks. Why not have a little retrospective?

My devops history

Wordpress / PHP

My first job as a software engineer was in a web agency focused on building custom WordPress website for small clients. The workflow was extremely fragile and stressful. No automated tests (because it’s “takes too long to write them”), pushing changes through an ftp plugin on sublime text (without forgetting to manually swap config between dev and prod envs!). We wasted a lot of time fighting regressions, had little insight on what I’d call now like basic metrics like uptime. Rollbacks were a manual process and it was the paradise of “it works on my machine” or “it was fine 5 minutes ago”.

Python / Ansible / AWS

Later I was working on a python/django/postgres stack, hosted on AWS (I don’t remember the exact stack but it was in part EC2 instances). We were using ansible to automate most steps but still had a lot of manual work to deploy a release. Especially on the testing side, we had some unit tests but not enough integration/e2e testing to be fully confident. I don’t remember much on the side of analytics/metric either. I remember seing Jenkins being used there too, by the mobile apps team. I was still quite junior then and without someone to explain the workflow it was hard for me to see the benefits. Bridging the gap between our ansible+manual steps workflow to a CI system required a few puzzle pieces I was still missing.

Git-ops

When I joined YLD I saw the first examples of fully automated gitops CI/CD workflows. More exactly, as I was leaving my previous company I saw a more experienced engineer setup a lot of the missing pieces I was talking about, automating a lot of the previously manual work. Then at my first YLD client we had a fully fledged team including a QA. We had automated pipelines, tests (unit, e2e, integration) and visible metrics. This became the rough standard I became used to. Never 100% perfect but so much better than anything I’d seen before. Some places had more complicated requirements which in turn let me see more complex systems (multi client releases of the same applications with different config to manage, microservices shared across multiple teams, using tagged releases).

Pain points

Through my work, i’ve noticed common pain points in the developer experience. As I work more towards devops positions, I hope to be able to improve these for the teams I work with: