What content ops can learn from devops

Why borrow from devops?

A strategist commissions a page, a writer drafts it, an editor checks it and a translator produces the Welsh version. Later, someone changes a statistic on the English page. Who checks the translation? Which other pages use the old figure? Has the chatbot’s source changed too? Each person may have done their job well; the trouble lies in how the work connects.

Devops brings development and operations together, with shared responsibility for how a system works after release. Many of the practices below predate devops or belong to software engineering more broadly. Their common concern is useful to content teams: how to make changes together, see their effects and remain responsible for what happens next.

Content teams already have their own traditions of collaborative production, from newsrooms to publishing houses. The challenge is that many organisations still manage web content through separate documents and informal agreements. Software teams offer practical ways to make that work more systemic, more dependable. Each linked term here leads to its entry in the Content Lexicon, where you can follow the idea further.

Working together

Version control and shared work

Version control records changes to files over time so people can see what changed and restore an earlier state. Git is one widely used version control system. The broader idea of versioning also covers how distinct versions are identified and managed.

Content has its own history, but it is often hard to see. Shared drives collect documents with names like Brand-guidelines-FINAL-v3-edits and Brand-guidelines-FINAL-v4, while the question of which version legal approved gets answered by asking whoever remembers. Many tools already keep a revision history. An agreed authoritative version, fewer disconnected copies for routine edits and a record of why important changes were made give the next person something better than archaeology.

A branch is a separate line of work based on a shared project. It lets someone prepare changes without disturbing the version others depend on, then bring them back when ready. A content team might use a CMS draft or a clearly labelled working copy for a significant change spanning several pages. The important difference from an accidental duplicate is that the starting point and route back to the live version are clear.

A pull request proposes a change for review before it joins the shared version. Editorial review is familiar; the useful addition is a visible proposal, a record of the discussion and, where the risk warrants it, a clear approval. Reviewing both the writing and its consequences helps teams catch broken links, conflicting figures and neglected translations, while checks that match the risk keep the process proportionate. A typo need not get the same ceremony as a change to eligibility advice.

A merge conflict occurs when changes from separate branches cannot be combined automatically, often because two people edited the same part. Content has related problems, but not every contradiction is a technical merge conflict: separate documents can disagree without any tool noticing. Making overlapping work visible and keeping shared facts tied to an authoritative source helps everyone collaborate more reliably.

Markdown is plain text with lightweight marks for headings, emphasis and lists. It is easy to compare, reuse and track in version control, which makes it useful for documentation and repeatable AI-assisted work. Word documents, Google Docs and PDFs can work too; Markdown’s advantage is that the words and basic structure remain easy to inspect across tools.

A database stores information in a structured form that can be searched and related. For a content inventory, that might mean a page, its owner, purpose and review date. Starting with a manageable set of important pages makes the inventory easier to maintain and more likely to stay useful. A review date doesn’t prove that a page is current, but it can show when someone was meant to check.

The frontend is the part people see; the backend handles the data and logic behind it. A headless CMS separates content management from the presentation layer, so the same content can be delivered to different channels. Reuse still depends on structured content and a reliable source for shared facts. Giving that information an authoritative home and recording where else it appears makes reuse safer and updates easier to trace.

Releasing and maintaining content

The live site is production; staging is a separate environment for checking a change before release. A page preview is useful, but it may not show how the page works in the site’s real navigation and templates. Checking an important change in context and on a phone, ideally with someone who did not write it, makes it easier to spot problems a page preview can miss.

Continuous integration brings changes into a shared version regularly and checks that they work together. Continuous delivery keeps that version ready to release; continuous deployment goes further and releases automatically when checks pass. The useful habit for content teams is to make small, reviewed changes routine, rather than waiting for a relaunch to fix known problems.

A rollback restores an earlier working state after a change causes trouble. Knowing how restoration works, who can do it and how long it takes makes rollback more than a reassuring idea. It is not always the right response: an earlier version may contain outdated guidance, and restoring a page cannot recall an email or a copy already taken elsewhere.

A feature flag controls whether a software feature is available, sometimes for only a subset of users. Content teams may need controlled release or regional variants too, but a scheduled expiry date and a feature flag are different mechanisms. Being clear about what needs controlling, which mechanism fits and who is responsible makes release controls more useful and less confusing.

Automated testing checks a defined expectation, such as whether a link works or a required field is present. Automating checks whose results people understand and will act on makes it more likely that problems will be caught and fixed. A script can flag missing alt text; a person still needs to judge whether that text describes what matters in the image. Checks are most useful when they support editorial judgement and leave interpretive decisions to people. Content Health Check is one example of combining mechanical and evaluative checks on live pages.

Publication is not the end of the work. Watching for broken journeys, failed searches and recurring support questions shows where content is failing people after publication. Asking people whether they could find and understand what they needed, then routing that feedback to the people who can improve the content, helps teams turn feedback into changes rather than background noise.

How developers think

Don’t repeat yourself, usually shortened to DRY, is the principle that each piece of knowledge should have one authoritative home, with other uses referring back to it rather than copying it. A figure repeated across fourteen pages will drift unless someone knows every place it appears. Keeping a source for shared facts, including where they came from and when they apply, makes drift easier to prevent and easier to correct. Where copies cannot be avoided, recording which pages depend on them makes the follow-on work visible.

Refactoring improves the structure of code without changing what it does. Content changes can improve structure too: clarify a heading, move an important paragraph or separate two subjects crowded onto one page. Unlike a code refactor, these changes can affect how readers understand and navigate the information, so check the effect rather than assuming the meaning stayed the same.

Technical debt describes choices that make later work harder. Content debt includes known problems that keep imposing costs: an outdated page, an inaccessible PDF, a duplicated fact or a page with no clear owner. A simple register can name what is wrong, what it costs, who will address it and when. Some items should be fixed; others should be retired. Either way, the decision becomes visible.

Working with AI

Context engineering concerns the material, examples, constraints and tools supplied to an AI model as it works. A polished prompt cannot make up for missing evidence or contradictory instructions. The habits above help: authoritative facts are easier to supply, structured guidance is easier to reuse and reviewed sources are safer to rely on. The person commissioning the work still needs to say who it’s for, what they need from it and what would make the result worthwhile. That editorial understanding belongs alongside the source material and technical instructions.

Retrieval-augmented generation, or RAG, brings relevant source material into a model’s context before it generates an answer. The quality of the answer still depends on whether the right evidence is found and interpreted correctly. If a collection contains three versions of a policy, the assistant may retrieve an old one or combine conflicting information. Auditing the sources and testing answers against real questions, including cases where the evidence disagrees or is missing, makes it easier to see whether the system is dependable or merely plausible.

Graph engineering designs an AI process as connected steps, with routes for decisions, review and failure. An editorial workflow already has a shape – plan, research, draft, check, review and publish – but making it executable means deciding what happens when a check fails and where a person must intervene. Drawing those steps and routes before automating them exposes gaps while they are still cheap to fix. The diagram may reveal that reader needs, maintenance or retirement have been left out.