DevOps in Embedded Software? Let’s Be Honest: It Doesn’t Really Exist

When people talk about DevOps, they usually mean something very specific: development teams continuously building and shipping code, and operations teams running and scaling that code in production—usually in the cloud. CI/CD pipelines automatically build, test, and deploy code through staging, QA, and production environments. The boundaries and responsibilities are clear. But what happens when you try to apply this same DevOps concept to embedded software development? Spoiler: it doesn’t fit. At least not in the way most people mean when they say “DevOps.” Development in Embedded Software: A Different World In embedded systems, developers write software that runs on physical devices. Their workflow looks more like this: • Work locally on hardware on their desks • Push changes to version control (SCM) • Make the CI/CD pipelines green • Create a changelog, tag, and release documentation They may test features on sample boards, and in some setups, even flash the software to hardware themselves. But that’s where their “Ops” ends. What About QA, Integration, and Delivery? QA: A dedicated test department typically performs advanced system-level testing. They test on integrated systems or test rigs, not in cloud staging environments. Release: A release manager ensures that binaries, documentation, and metadata are entered into systems like SAP or Teamcenter. That’s how the software ends up in the factory line, where it’s flashed onto the actual products. Production? You Mean the Customer’s Device Once the device leaves the factory, the “production environment” is a physical appliance in a customer’s home. There’s no scaling, monitoring, or uptime management like in web apps. The software runs as-is on the hardware it shipped with. If something goes wrong, the fix is often delivered via an Over-The-Air (OTA) update—and even that is a tightly controlled and slow process. In theory, one might call this “Ops”—maintaining and patching the software in the field. But in practice, no one in embedded development calls that “DevOps.” So Where Is the Real “Ops” in Embedded? If you want to talk about something resembling “Ops” in embedded development, it’s on the infrastructure side: • Teams that host and maintain SCM systems • CI/CD infrastructure teams who provide and maintain Jenkins, GitLab CI, or similar tools • Teams that manage artifact repositories like Artifactory or Nexus • Engineers who set up and maintain CI/CD pipelines • Specialists who operate nodes connected to real hardware, or Kubernetes clusters with runners This infrastructure supports embedded development—but it’s not part of deploying or running the software in production. It’s about keeping the development environment running, not the product. CI/CD Experts: The Real DevOps Role? The closest thing to a DevOps role in embedded development is the CI/CD expert. Sometimes that’s a person embedded in the software team. Sometimes it’s a separate team that provides tooling and pipelines to all developers. Their job: • Maintain Jenkins pipelines • Integrate build/test hardware into the CI • Operate CI runners and nodes • Ensure firmware can be reliably built, tested, and released But again: this isn’t about running software in production—it’s about enabling development. Conclusion: Let’s Stop Pretending DevOps Means the Same in Embedded In the embedded world, DevOps as understood in the cloud world simply doesn’t exist. There’s no production environment to operate. There’s no live monitoring or auto-scaling. There are no infrastructure alerts in the middle of the night. What we do have are: • Development teams with local workflows and physical hardware • Test departments validating complex integrated systems • Release managers interfacing with enterprise systems • CI/CD experts maintaining infrastructure and pipelines So next time someone says “we need DevOps for embedded”, stop and ask: What exactly do you mean?

May 12, 2025 - 07:32

DevOps in Embedded Software? Let’s Be Honest: It Doesn’t Really Exist

When people talk about DevOps, they usually mean something very specific: development teams continuously building and shipping code, and operations teams running and scaling that code in production—usually in the cloud. CI/CD pipelines automatically build, test, and deploy code through staging, QA, and production environments. The boundaries and responsibilities are clear.

But what happens when you try to apply this same DevOps concept to embedded software development?

Spoiler: it doesn’t fit. At least not in the way most people mean when they say “DevOps.”

Development in Embedded Software: A Different World

In embedded systems, developers write software that runs on physical devices. Their workflow looks more like this:
• Work locally on hardware on their desks
• Push changes to version control (SCM)
• Make the CI/CD pipelines green
• Create a changelog, tag, and release documentation

They may test features on sample boards, and in some setups, even flash the software to hardware themselves. But that’s where their “Ops” ends.

What About QA, Integration, and Delivery?

QA: A dedicated test department typically performs advanced system-level testing. They test on integrated systems or test rigs, not in cloud staging environments.
Release: A release manager ensures that binaries, documentation, and metadata are entered into systems like SAP or Teamcenter. That’s how the software ends up in the factory line, where it’s flashed onto the actual products.

Production? You Mean the Customer’s Device

Once the device leaves the factory, the “production environment” is a physical appliance in a customer’s home. There’s no scaling, monitoring, or uptime management like in web apps. The software runs as-is on the hardware it shipped with. If something goes wrong, the fix is often delivered via an Over-The-Air (OTA) update—and even that is a tightly controlled and slow process.

In theory, one might call this “Ops”—maintaining and patching the software in the field. But in practice, no one in embedded development calls that “DevOps.”

So Where Is the Real “Ops” in Embedded?

If you want to talk about something resembling “Ops” in embedded development, it’s on the infrastructure side:
• Teams that host and maintain SCM systems
• CI/CD infrastructure teams who provide and maintain Jenkins, GitLab CI, or similar tools
• Teams that manage artifact repositories like Artifactory or Nexus
• Engineers who set up and maintain CI/CD pipelines
• Specialists who operate nodes connected to real hardware, or Kubernetes clusters with runners

This infrastructure supports embedded development—but it’s not part of deploying or running the software in production. It’s about keeping the development environment running, not the product.

CI/CD Experts: The Real DevOps Role?

The closest thing to a DevOps role in embedded development is the CI/CD expert. Sometimes that’s a person embedded in the software team. Sometimes it’s a separate team that provides tooling and pipelines to all developers.

Their job:
• Maintain Jenkins pipelines
• Integrate build/test hardware into the CI
• Operate CI runners and nodes
• Ensure firmware can be reliably built, tested, and released

But again: this isn’t about running software in production—it’s about enabling development.

Conclusion: Let’s Stop Pretending DevOps Means the Same in Embedded

In the embedded world, DevOps as understood in the cloud world simply doesn’t exist. There’s no production environment to operate. There’s no live monitoring or auto-scaling. There are no infrastructure alerts in the middle of the night.

What we do have are:
• Development teams with local workflows and physical hardware
• Test departments validating complex integrated systems
• Release managers interfacing with enterprise systems
• CI/CD experts maintaining infrastructure and pipelines

So next time someone says “we need DevOps for embedded”, stop and ask:
What exactly do you mean?