The 2012 release pipeline as drawn at the time: nvie's git-flow branch model on the left, Grunt building artifacts in the middle, Puppet provisioning environments on the right. The branch a commit lands on determines which environment Puppet promotes the artifact to.

// Grunt + git-flow + Puppet — 2012 release pipeline as drawn at the time
digraph grunt_git_flow {
    rankdir=LR;
    graph [bgcolor="white", fontname="Helvetica", fontsize=11,
           pad="0.3", nodesep="0.3", ranksep="0.35"];
    node  [shape=box, style="rounded,filled", fontname="Helvetica",
           fontsize=10, fillcolor="#f5f5f5", color="#888"];
    edge  [color="#aaa"];

    // Branch model cluster — nvie git-flow
    subgraph cluster_branches {
        label="git-flow branch model (nvie, 2010)"; labeljust="l";
        color="#369"; fontcolor="#369"; style="rounded,dashed";
        feature  [label="feature/*",   color="#369", fontcolor="#369"];
        develop  [label="develop",     color="#369", fontcolor="#369"];
        release  [label="release/*",   color="#369", fontcolor="#369"];
        master   [label="master\n(tagged)", color="#369", fontcolor="#369"];
        hotfix   [label="hotfix/*",    color="#369", fontcolor="#369"];
    }

    // Build step — Grunt task runner
    grunt    [label="Grunt\n(concat, uglify,\nless, imagemin)",
              color="#693", fontcolor="#693", fillcolor="#f0f7e8"];
    artifact [label="versioned artifact\n(static bundle / RPM)",
              color="#693", fontcolor="#693"];

    // Provisioning cluster — Puppet pulls artifacts to environments
    subgraph cluster_provisioning {
        label="Puppet provisioning"; labeljust="l";
        color="#d63"; fontcolor="#d63"; style="rounded,dashed";
        puppet   [label="Puppet master\n(manifests + facts)",
                  color="#d63", fontcolor="#d63"];
        test     [label="test env",    color="#d63", fontcolor="#d63"];
        staging  [label="staging env", color="#d63", fontcolor="#d63"];
        prod     [label="production",  color="#d63", fontcolor="#d63",
                  fillcolor="#fde8e8"];
    }

    // Branch model flow
    feature -> develop [label="merge"];
    develop -> release [label="release start", color="#693", fontcolor="#693"];
    release -> master  [label="release finish\n(tag vX.Y.Z)", color="#693", fontcolor="#693"];
    hotfix  -> master  [label="hotfix finish", color="#d36", fontcolor="#d36"];
    hotfix  -> develop [label="back-merge", style=dashed];

    // Builds — branch landing triggers Grunt
    develop -> grunt [label="build:dev",  color="#693", fontcolor="#693"];
    release -> grunt [label="build:rc",   color="#693", fontcolor="#693"];
    master  -> grunt [label="build:prod", color="#693", fontcolor="#693"];
    grunt   -> artifact;

    // Provisioning — Puppet pulls the artifact, branch decides target
    artifact -> puppet [color="#d63"];
    puppet   -> test    [label="develop -> test",     color="#d63", fontcolor="#d63"];
    puppet   -> staging [label="release -> staging",  color="#d63", fontcolor="#d63"];
    puppet   -> prod    [label="master -> production", color="#d63", fontcolor="#d63"];
}

• CI/CD Pipelines (2020) — the container-native, YAML-declarative successor to this branch-driven pipeline shape
• Terraform AWS resource patterns — the IaC layer that displaced Puppet manifests for cloud provisioning
• AWS Lambda configuration system — concrete Terraform module patterns for the same provisioning concerns Puppet handled here
• Kubeflow ML pipelines — the same branch-as-deploy-target idea applied to model artifacts and serving environments

"Deploying static assets" in 2012 was largely a manual exercise wrapped in just enough automation to be repeatable. The pattern at most shops looked something like this: a designer or front-end developer committed updated CSS/JS/images to a Subversion or (newly) Git repository; an operator either scp'd the tree to a production host or, in more disciplined shops, an RPM was built from a tagged commit and pushed through Spacewalk or a homegrown yum repo. CDNs existed — Akamai had been around since the late 1990s, CloudFront launched in 2008 — but they were not the default for a typical mid-sized web property; it was still ordinary to serve /static/ straight off an Apache 2.2 or nginx 1.0 host sitting in your own rack or on a DreamHost / Linode / EC2 small instance. The "static asset host" was a single VM, the artifact was a directory tree, and the deploy was a file copy plus an Apache reload.

The "communication cost" the original note alludes to was the friction layer wrapped around that file copy. At an enterprise the path from "designer pushes CSS" to "CSS is live" routinely included: a Jira ticket to ops, a CAB (change advisory board) review for the production window, a manual scheduling email, a smoke-test sign-off from QA, and an after-hours deploy slot — all to ship a few hundred kilobytes of text. The git-flow + Grunt + Puppet stack was an attempt to replace those human handoffs with a branch-driven contract: the branch a commit lands on names the environment it goes to, and the build + provisioning toolchain executes that contract without further negotiation.

The artifacts below are the kind of files a 2012 contractor would actually have committed for this stack. They are illustrative, not canonical — but they should look familiar to anyone who shipped front-end code in the Grunt era.

The Grunt + git-flow + Puppet choice was one cell in a much larger matrix. The plausible 2012 alternatives, with the tradeoffs that mattered at the time:

The shape of the 2012 decision matrix was: pick a build tool that matched the developer's primary language (Grunt for JS shops, Rake for Ruby, Make/shell for everything else); pick a config-mgmt tool that matched ops' comfort (Puppet or Chef in roughly equal measure in North America, with CFEngine still strong in finance); and glue them together with whatever CI you already ran. The Grunt + Puppet combination in this note is unusual only in pairing a JS-world build tool with a Ruby-world config-mgmt tool — which works fine because the artifact handed off between them is just a directory of files.

The original note's framing — reduce the communication costs associated with when and what to build and how to deploy — is, in retrospect, almost a one-line definition of what InnerSource Commons would coalesce around three years later. Tim O'Reilly coined the term "InnerSource" in 2000 (in conversations with IBM teams adopting open source practices internally), and the InnerSource Commons community was founded by Danese Cooper at PayPal in 2015 and announced in her OSCON keynote that same year. The InnerSource Patterns book and patterns.innersourcecommons.org are the working catalogue of the practices that emerged.

The 2012 stack as written assumes the deploy pipeline is owned — ops owns the Puppet manifests, the front-end team owns the Gruntfile, release engineering owns the git-flow ritual — and the cross-team contract is the branch name. An innersource-aware version of the same problem would invert the ownership model in three concrete ways:

1. Puppet manifests as a contributable repo. Instead of ops being the bottleneck for "add a new vhost" or "bump the cache header," the manifests live in a repo with a README, a CONTRIBUTING.md, a PR template, and a small set of trusted committers from ops who review pull requests from any internal team. The InnerSource pattern names for this are "30-Day Warranty" (the contributing team maintains the change for 30 days) and "Trusted Committer."
2. Grunt config as a vendored internal module. Rather than every front-end team copy-pasting a Gruntfile, the build pipeline ships as an internal npm package (@example/static-build) that exposes a small grunt-config.js API. Teams contribute pipeline improvements upstream via PR; the package is versioned and pinned per consuming project. This is the "InnerSource Library" pattern.
3. README-driven onboarding for the deploy pipeline itself. The pipeline's own README is the contract: how to add a new environment, how to cut a release, how to roll back, who the trusted committers are. This eliminates the "ask in #ops Slack" step that consumes most of the communication cost the original note set out to reduce.

The deeper alignment between innersource and the trunk-based-development critique of git-flow (Paul Hammant's trunkbaseddevelopment.com is the canonical reference) is that both treat branch proliferation as a proxy for coordination friction. git-flow's five branch types encode five distinct handoff conversations; trunk-based development collapses those to one branch and pushes the coordination into PR review and feature flags — which is precisely the medium an innersource workflow runs on. Read in that frame, the 2012 stack solved the right problem (reduce coordination cost) with the wrong primitive (branches as deploy targets); the innersource + trunk-based answer would have been PRs as deploy proposals, with the same Puppet manifests on the receiving end. Nadia Eghbal's Working in Public (Stripe Press, 2020) documents how that PR-as-proposal pattern scaled from open source into the modern platform-engineering playbook.

Almost every named tool in this 2012 note has been replaced. nvie's git-flow lost the argument to GitHub Flow and trunk-based development, and nvie himself published a note of reflection in March 2020 saying git-flow is the wrong default for web teams. Grunt was eclipsed by npm scripts and then by Gulp; Gulp in turn lost to Webpack, and the current build front-runners are Vite and esbuild — Grunt's last release (1.6.1) is from January 2023 and the project is in maintenance mode. Puppet went through Perforce's 2022 acquisition and a 2024 split between a paid Enterprise edition and the community fork OpenVox (first formal release January 2025); in greenfield work it has largely been displaced by Ansible/Salt for config management and by Kubernetes plus Terraform/Pulumi for provisioning. The piece that survived intact is the underlying pattern — a git branch is the deploy target — now the central abstraction in GitOps via Argo CD and Flux, both CNCF graduated projects.