What Is
DevOps?

DevOps combines software development, IT operations, and quality assurance, three previously separate workflows and IT groups.

As software applications become larger and more complex, teams face an increasing need to coordinate their efforts. New teams are formed specifically for the purpose of carrying out nonfunctional work streams such as testing, development, deployment, or operations. These teams include business analysts, project managers, systems engineers, and other members who would previously have performed these functions as part of different teams.

The DevOps approach to application development brings together the development and operational teams to deliver software faster and more frequently, with the goal of satisfying customer needs better than before.

Traditionally, software developers wrote code. When they finished, the application went through QA and then would be deployed into production by IT ops, who arranged for the servers, storage, and other needs to make the code perform as expected. In embedded systems, ops refers to the people who put the software onto the embedded system and oversee the production of whatever device the software powers.

This model worked well for the waterfall method of software development. However, developers spent relatively long periods of time perfecting the embedded system software before turning it over to ops, so the disadvantage was that it was comparatively slow.

Traditional development methods are simply too slow for today’s competitive embedded market.

Agile methods introduced a new approach to software development, with dev teams working in “scrums” and pushing out releases at a faster clip. What became quickly apparent was that agile teams were creating code so rapidly that it was better to integrate the ops and QA teams into the development process. They all started to work together under the DevOps banner.

Another consequence of DevOps relates to the mechanics of integrating and distributing the new code itself. The pace of code releases grew so quickly that only automated software could handle it. Plus, many of the code releases were just small updates to existing applications. It made little sense to do a big uninstall/reinstall routine every day (or every few hours) as new code came out of DevOps teams. To solve this problem, the practice of continuous integration (CI) and continuous delivery (CD) of code has become the norm. CI/CD tools take code and place it right into a production application, without stopping any functions from running. This is like the old “change the tire while the car is moving” concept. But here, it works.

Turning DevOps and CI/CD theories into practice requires toolsets that, although technically separate, are interdependent. Figure 1 shows a simplified version of the most common DevOps-to-cloud CI/CD workflow. Each step in the workflow is supported by a specific type of tool.

DevOps is becoming popular with embedded systems makers for a combination of positive and negative reasons. The positives include the ability to move better products to market faster. Done right, DevOps makes the once sequential development, QA, security, and operations schedules overlap to some extent — essentially becoming DevSecOps. There are fewer iterations in every cycle, so everything advances more rapidly.

CI/CD methods speed up time-to-market, improve collaboration, and produce better products … but organizations face challenges when trying to implement these new methodologies.

The negative factors that are forcing companies to embrace DevOps are largely related to personnel limitations. Developers who can write good code and who understand embedded systems are hard to find. Many design teams are facing a shortage of developers who understand embedded systems and their role in specific industries, such as aerospace or automotive.

This basic shortage of people is exacerbated by the requirement for developers to have security clearances. DevOps is critical in this context, because it enables a small, limited talent pool to produce more software than ever before.

Not every embedded systems company has an easy time making the move to DevOps, even when there is a strong intent to get it going. One issue that comes up is a lack of coordination between groups. Simply declaring that DevOps will be the mode of software development and release is inadequate to get teams to integrate their processes.

Adopting DevOps must be a revolutionary change in management processes. Team members need to be trained on the new methodologies and tools. They need the chance to ask questions and determine how these novel methods will work at their specific organization. DevOps and CI/CD are cultural shifts as much as they are technical and procedural.

Security can also impede the progress of DevOps. Application security can be challenging, and speeding up the development process doesn’t automatically mitigate risk. If anything, it increases the dangers. You need to ensure security throughout the entire embedded development process.

Hardware can be a barrier, too. In traditional development, the dev team had to code for a known piece of target hardware, such as a specific operating system on a familiar processor and circuit board combination. As the overall process accelerates, it gets harder to provide target hardware quickly enough for the DevOps team. Some hardware may be extremely expensive, of limited availability, or not even built yet.

Using the right tools, such as Wind River Simics^®, eliminates hardware roadblocks, enabling faster development of high-quality embedded products.

Although many data center toolsets already come with DevOps and CI/CD-friendly functionality, in the embedded world most development is still being done in the traditional waterfall manner. Wind River is leading the way in modern development by providing robust agile functionality in every product release and roadmap.

Wind River products now enable the full DevOps-CI/CD workflow. To make this successful for our customers, we started with our own dev-test-release processes. Today, products such as Wind River Linux, VxWorks^®, and Wind River Helix™ Virtualization Platform are produced using our own DevOps environment. We have learned a great deal about the unique needs of these methodologies in the embedded systems context. Our insights into the process have led to an effective DevOps-CI/CD stack, as depicted in Figure 2.

Figure 2. Wind River products either directly offer DevOps and CI/CD functionality or support a range of industry-standard toolsets in each functionality area of the workflow

Wind River products now enable the full DevOps-CI/CD workflow. To make this successful for our customers, we started with our own dev-test-release processes. Today, products such as Wind River Linux, VxWorks^®, and Wind River Helix™ Virtualization Platform are produced using our own DevOps environment. We have learned a great deal about the unique needs of these methodologies in the embedded systems context. Our insights into the process have led to an effective DevOps-CI/CD stack, as depicted in Figure 2.