The Deployment Pipeline as Editorial Workflow

In a traditional CMS, publishing is a button. The content exists in a database in draft state. Clicking publish changes a field. The post is live. The workflow is immediate and direct, which makes it easy and also makes it difficult to review, stage, or coordinate publication across a team.

A static site generator deployed through a Git-based pipeline has a different publication model. Content moves from draft to published by merging a commit to the main branch. The merge triggers a build. The build produces a new version of the site. The site deploys automatically. Publication is a consequence of version control operations, not a CMS action.

This maps onto editorial workflow in ways the button model does not. A post can be written on a branch, reviewed as a pull request, commented on line by line, revised, and merged when ready. The staging environment is the branch preview. The publication event is the merge. The record of review is the pull request thread.

For a solo publisher, much of this is unnecessary. Writing a post and pushing to main is a two-step operation. The pipeline handles the rest. The draft flag in frontmatter provides a simpler mechanism — set draft to false, push, the site rebuilds with the post included.

The interesting property of the pipeline model is that it makes publication auditable by default. Every post that ever went live, every revision, every deletion, is recorded in the Git history with a timestamp and an author. This is not a feature that was designed into the system. It is a consequence of using version control as the publication mechanism.

For publishers who think carefully about editorial record-keeping, this consequence is not incidental. It is the point.