Home avatar

Lou Stack Base

Lou's knowledge base for software engineering, DevOps, and topics I'm exploring.

Why I Didn't Use Reusable Workflows: GitHub Actions Readability, Maintainability, and Operator-Facing Tradeoffs

I originally thought that extracting shared logic into reusable workflows would be cleaner.

After actually implementing it, I ended up pulling them back into entry workflows, keeping only composite actions. Not because reusable workflows don’t work, but because in this case, they didn’t deliver the “cleanliness” I actually wanted.

This post documents the tradeoffs I ended up with.

Initial Motivation for Extracting Shared Pipelines

The reasoning was sound.

GitHub Actions + GCP WIF: Least Privilege Across Branches, Workflows, and Service Accounts

When I connect GitHub Actions to GCP now, there is one setup I do not want to repeat:

  • one shared deploy service account
  • one broad trust rule
  • one workflow that can hit every environment

It feels convenient at first. But once you split dev / prod, risk rises fast and debugging gets more expensive.

This is the model I ended up with: enforce least privilege through three aligned boundaries — branch, workflow, and service account.

From a Single Terraform Root to Modules + Live: Phased Migration, Import, and State Surgery

This post records one thing I keep coming back to: if Terraform starts with only one root, and later you want to add dev / prod, add a shared layer, and add CI/CD boundaries, how do you migrate without affecting the existing environment?

My final conclusion is simple:

  • do not rewrite everything in one shot
  • do not split CI/CD first
  • do not delete old roots before new roots converge

The method that actually works is phased migration.

Dev/Prod Isolation in a Single GCP Project: State, Secrets, IAM, and Workflow Boundaries

This post documents how I kept a Cloud Run + Cloud SQL application in the same GCP project while still cleanly separating dev and prod.

Branch naming alone will not isolate your environments, nor will merely adding two more GitHub workflows. What truly needs to be separated is state, resource naming, secrets, runtime identity, deploy identity, and workflow governance. If even one of these layers leaks, they will eventually collide.

Domain-Centric Pitfalls — Consistency-Cluster Boundaries, Double-Entry Ledger, and the Notification Pipeline

The previous post covered the concepts of DDD and how they compare to .NET MVC. This post documents the pitfalls I encountered in the actual project: how to draw consistency-cluster boundaries, how to design a double-entry ledger, and how the notification pipeline enables cross-module communication.

The Cost of Drawing Consistency-Cluster Boundaries Wrong

The rules for an Aggregate sound straightforward — a group of things that must always be accessed together, with a root entity as the entry point. But actually drawing the boundary is easy to get wrong.

What DDD Is — Starting From the Microsoft Ecosystem and the Repository Abstraction

During project development I encountered DDD (Domain-Driven Design) for the first time. I had previously worked with .NET MVC and also learned Go, and I realized many concepts are actually related to things I already knew — especially the Repository Pattern. This post documents how I used my existing knowledge to understand DDD.

The Request-Handler Approach

MVC stands for Model-View-Controller, three roles: