Broadcast engineering has always had an operations dimension. Keeping a transmission chain on air, maintaining a routing system, managing the configuration of hundreds of devices across a live facility - these are operational problems that require discipline, process, and good documentation. What has changed is the nature of the infrastructure being operated.
SDI routers had firmware. IP routing systems have software, APIs, configuration files, container images, and dependencies. An NMOS registry is a running process. A stream monitor is a web application. A routing automation system is a codebase. The tools that the software industry developed for managing this kind of complexity are called DevOps, and they are becoming relevant to broadcast engineering whether the industry is ready for them or not.
What DevOps Is
DevOps is not a job title, though it has become one. It is a set of practices and cultural principles that emerged from the software industry to address a specific problem: the friction between development teams who write software and operations teams who run it. The traditional separation between “writing code” and “running systems” created slow, error-prone deployment processes, poor feedback loops, and a tendency for problems to be discovered in production rather than before it.
DevOps collapses that separation. The same team - or the same engineer - is responsible for building, deploying, monitoring, and maintaining the software. The practices that make this work at scale include version control for everything, automated testing, continuous integration and deployment pipelines, infrastructure as code, and systematic monitoring and observability. None of these originated in broadcast, but all of them apply.
Why Broadcast Needs It
The shift to IP and software-defined infrastructure has moved broadcast engineering from a world of discrete hardware components with firmware into a world of interconnected software systems with runtime state. The operational implications are significant.
Configuration is now code. A traditional SDI router has a configuration that lives in the device. An IP media network has switch configurations, NMOS registry settings, PTP domain parameters, multicast group assignments, QoS policies, and routing automation logic - all of which exist as text files, database states, or API configurations that can be changed, corrupted, or lost. Managing this without version control is like managing a software project without Git. You have no history, no audit trail, and no reliable way to recover from a bad change.
Software changes at a pace hardware never did. NMOS implementations receive updates. Container images for broadcast services are updated by vendors. Security patches arrive. In a hardware-centric facility, a firmware update was a considered, infrequent event. In a software-defined facility, updates are continuous, and the question of how to apply them safely - without taking down a live system - is a real operational problem.
Complexity scales beyond manual management. A broadcast facility running ST 2110 with NMOS, PTP, IGMP multicast, QoS, and security infrastructure across dozens of switches and hundreds of devices has more configuration state than any individual can hold in their head. When something breaks, the ability to compare the current configuration against the last known-good state, or to automatically detect when a device has drifted from its expected configuration, is the difference between a quick resolution and a long troubleshoot.
Cloud production demands it. Remote and cloud-based production workflows involve deploying, configuring, and tearing down infrastructure on demand. A cloud production environment that has to be manually configured for every event is not operationally viable. The tooling to do this reliably - infrastructure as code, automated provisioning, container orchestration - is DevOps tooling.
What DevOps Looks Like in Broadcast
Version Control for Everything
The most immediately applicable DevOps practice is version control, and the broadcast industry has been slow to adopt it. Switch configurations, routing automation scripts, NMOS device configurations, SDP file templates, Python monitoring tools - all of these are text-based artifacts that should be in Git. The Git post on this site covers the basics, but the principle extends beyond individual scripts to the entire configuration state of a broadcast facility.
When a configuration change breaks something on a live system, being able to see exactly what changed, when, and revert it in seconds is not a luxury. In broadcast operational terms, it is the equivalent of a clean undo - and without version control, it does not exist.
Infrastructure as Code
Infrastructure as Code (IaC) is the practice of defining infrastructure configuration in machine-readable files that can be version controlled, tested, and applied automatically. In a cloud or hybrid production context, this means the servers, networks, and services needed for a production are defined in code - Terraform, Ansible, or similar tools - and can be provisioned consistently and repeatably.
For broadcast, the practical application ranges from simple Ansible playbooks that apply a known-good switch configuration across a fleet of network devices, to full Terraform definitions of a cloud production environment that can be stood up and torn down on demand. The consistency this provides - every device configured from the same source of truth, every time - eliminates the class of problems caused by manual configuration drift.
Containerisation and Orchestration
Docker and Kubernetes have become the standard for deploying software services in production environments. Broadcast software services - NMOS registries, stream monitors, media gateways, API servers - are increasingly delivered as container images. The Docker post on this site covers the fundamentals.
Kubernetes extends Docker to managed orchestration: it handles the scheduling, scaling, health monitoring, and restart of containers across a cluster. For broadcast facilities running multiple software-defined services, Kubernetes provides the operational reliability that was previously provided by redundant hardware. A service that crashes is automatically restarted. A node that fails has its workloads rescheduled. Deployments can be rolled out with zero downtime and rolled back in seconds if something is wrong.
This is not theoretical. Major broadcasters are running Kubernetes clusters for production broadcast services. The operational model is different from managing physical hardware, but the reliability outcomes are comparable and the flexibility is substantially greater.
CI/CD Pipelines
Continuous Integration and Continuous Deployment (CI/CD) is the practice of automatically testing and deploying code changes as they are made, rather than accumulating changes and deploying them in batches. In broadcast terms, this applies to any software that the facility maintains - routing automation tools, NMOS control applications, monitoring dashboards, custom processing scripts.
A CI/CD pipeline for a broadcast tool might look like this: an engineer commits a change to Git, automated tests run to verify the change does not break existing functionality, the tool is built into a container image, and the new image is deployed to a staging environment for validation before being promoted to production. The whole process is automated, auditable, and repeatable. Manual deployment steps - the ones that go wrong at 22:00 the night before a major event - are eliminated.
Monitoring and Observability
DevOps emphasises systematic monitoring - not just whether a service is up or down, but detailed metrics and logs that make it possible to understand why something is behaving the way it is. In broadcast, this extends beyond the traditional signal monitoring of audio levels and video integrity to the health of the software infrastructure itself.
Tools like Prometheus for metrics collection and Grafana for visualisation are common in broadcast IP infrastructure monitoring. Combined with log aggregation, they provide a complete operational picture - the state of every NMOS service, every multicast group, every PTP clock, every container, in a single dashboard. When something goes wrong, the data to understand it is already there.
The Broadcast DevOps Engineer
The emerging role that combines these skills is sometimes called a broadcast DevOps engineer, sometimes a media infrastructure engineer, sometimes just a systems engineer with a broader remit. The common thread is an engineer who understands broadcast signal chains and operational requirements, and who also has the software engineering and systems administration skills to build and maintain the infrastructure that delivers them.
This is not a role that requires abandoning broadcast knowledge. The value of the broadcast background is understanding what the system has to do - the latency requirements, the synchronisation constraints, the reliability expectations of live production. The DevOps skills provide the tools to build and operate software infrastructure that meets those requirements with the same rigour that hardware-based broadcast systems were engineered to.
The transition is not comfortable for everyone. Broadcast engineers who have spent careers working with hardware find the abstraction layers of containerised software, declarative infrastructure, and automated pipelines unfamiliar. Software engineers who enter broadcast from the IT world often underestimate the operational constraints of live production. The effective broadcast DevOps engineer sits at the intersection and understands both.
Where to Start
For broadcast engineers who want to develop in this direction, the path is incremental:
Version control first. Get every script, configuration file, and automation tool into Git. This alone provides immediate operational benefit and builds the habit of treating configuration as code.
Learn one scripting language well. Python is the most broadly applicable in broadcast contexts - it is used for NMOS tooling, network automation, monitoring scripts, and data processing. The ability to write, test, and maintain Python scripts is foundational.
Get comfortable with Linux. The vast majority of broadcast software infrastructure runs on Linux. SSH, systemd, file permissions, process management, and basic networking commands are operational prerequisites.
Learn Docker. Containerisation is how broadcast software is increasingly packaged and deployed. Understanding how to run, configure, and manage containers is becoming a baseline expectation.
Understand CI/CD conceptually. Even if you are not building pipelines from scratch, understanding what a CI/CD pipeline does and why it exists helps when working in environments that have them.
The broadcast industry is still relatively early in this transition. Engineers who develop these skills now are positioning themselves for infrastructure that is already being built, not hypothetical future systems.
The Honest Trajectory
The move toward software-defined broadcast infrastructure is not reversible. Every significant broadcast IP deployment involves software systems that need to be managed with software engineering discipline. The facilities that do this well - with version control, automated configuration management, systematic monitoring, and reliable deployment pipelines - will operate more reliably and respond to problems faster than those that treat software-defined infrastructure like hardware that happens to run code.
DevOps in broadcast is not about chasing trends. It is about applying the right tools to a problem the industry has already committed to having. The broadcast engineers who understand both sides of that equation are going to be the ones building and running the facilities of the next decade.