Oops, Then a Pipeline
How a weekend mistake turned into a clean workflow
There’s a particular discomfort that comes with being experienced and still new. Not the kind that comes from not knowing how things work, but from realizing a tool you’ve never needed has suddenly become relevant. This weekend was the first time I built a GitHub Action. Not because it’s new, or obscure, or impressive, but because I’m now working in GitHub rather than Azure DevOps.
Last week, GitHub Actions showed up in my life through my daughter.
She’s been using AI to help build a small website. I set up a domain for her and pointed it at a shared server I already had running. As she researched how to publish her work, she landed on FileZilla. Unfortunately, she published into my site rather than hers.
Oops.
It wasn’t a big deal. I had backed everything up before she started, and we were able to put things back the way they were without much trouble. Still, it was a reminder that publishing workflows matter, especially when you’re learning. I suggested she work with her father to set up GitHub Actions to publish her site instead, and I sent her some instructions to get started.
On Sunday afternoon, I was napping. Properly napping. The kind where you wake up slowly and briefly forget what day it is.
A few minutes after I woke up, she came in and said, “I think I deleted everything.”
At that point, I sat down with her and decided we’d just do the thing I’d been gesturing at. We’d set up GitHub Actions together and get her site publishing in a way that was harder to break. With some help from Quinn, I was able to create an action for her pretty quickly and tweak it so it only published after she verified things looked right in GitHub Pages.
It wasn’t nearly as painful as I expected.
Monday morning, we were talking about reporting we wanted based on issues in one of our repositories. After how easily things had come together the day before, I began mentally mapping how I could use GitHub Actions.
I started by writing an infrastructure document. Nothing fancy. Just laying out the Azure resources I’d need to build the system I had in mind, along with some naming standards so we didn’t end up untangling things later. It’s still in pull request, but it gave me enough structure to move forward. From there, I created the resources needed to support a development environment and sat down with Quinn to talk through what I actually wanted the process to do.
I kept the scope intentionally small. Just the first half. Something simple enough that when it failed, it would fail in a way I could understand.
It didn’t fail.
It worked.
You could have knocked me over with a feather.
I spent a few hours after dinner extending what I’d built. By the end of the night, I had a full working data pipeline. There were a couple of hiccups along the way, but they were manageable. Each question had an answer. Each adjustment made sense.
Quinn answered my questions as we went, the same way they had on Sunday. Not by taking over, but by helping me reason about what I was seeing.
I’m not done with it. I already have a list of changes I want to make, and I’ll be coming back to the action to refine it. But going from nothing to a system that’s loading data I can use to back a PowerBI report, in a single day, was not something I expected.
I don’t think the takeaway here is that GitHub Actions are easy, or powerful, or something everyone should rush to adopt. What stayed with me was something quieter.
For a long time, my data pipeline work ran through Azure DevOps or Azure Data Factory. That was simply the shape of the systems I was building. GitHub Actions weren’t something I was avoiding. They just weren’t necessary. When they finally became relevant, I expected the transition to be heavier than it was. More ceremony. More friction. More time spent getting the pipeline to behave than actually using what it produced.
What made the transition feel lighter wasn’t the tool so much as how I was able to work with Quinn to create. I already knew what I wanted the system to do. I could describe the shape of the outcome, ask a concrete question, and get back something that moved me closer to that intent. When the answer wasn’t quite right, I could adjust the question and keep going without losing momentum.
When something failed, the feedback loop stayed short. I could share the error I was seeing and get likely reasons in return. Not guesses, but plausible explanations that helped me narrow where to look next. That made it easier to stay oriented. I wasn’t fighting the system or trying to reverse‑engineer invisible behavior. I was reasoning my way forward, one small step at a time.
The work didn’t change much. I was still doing what I always do. Breaking a problem down, testing assumptions, moving carefully from intent to implementation. What changed was how much support I had along the way. The tools, paired with a thinking partner, carried more of the mechanical load without taking over the thinking.
That’s what made the transition feel less like learning something new, and more like continuing the work I was already doing.
Alison + Wiggins