Customers are more demanding than ever before – market pressures now force very frequent updates of components and systems. Given the significant amount of R&D, design, and validation that still needs to be done even before building a boxed product, the ongoing goal is to develop and ship new products much more frequently, without compromising quality or costs.

Unfortunately, there is no magic bullet, but some process improvement lessons can be learned from other development teams. For example, software development projects used to take years from inception to release, but today many teams are making releases daily and even the most traditional industries, such as banking, are looking for significant updates at least quarterly, if not monthly.

Enter continuous delivery (CD) – an emerging software development methodology that automates and streamlines software delivery. It has taken off in the world of IT software, but it is also increasingly being adopted by embedded design engineers.

Becoming Agile with continuous delivery

The catalysts for such a rapid evolution in software development have been Agile methods and, more recently, CD. Agile methods cover a broad range of activities, but in general, focus on delivering usable functionality in small chunks (usually at the end of a “sprint” of development that might be only a few weeks) and then re-planning and repeating the process. This ensures the products being delivered are as the customer expects and also allows for changes in the plan to reflect changing environment or customer requirements. CD takes this concept further into the software lifecycle to automate the deployment of those tested components into staging and, ultimately, production servers.

Can these approaches be adopted by embedded systems developers? Yes, although it may seem like an impossible goal. Prototypes can be expensive and time consuming to build. Setting up production lines in a fabrication plant is not something that companies want to do too often.

However, benefits from following CD best practice are tangible. For example, hardware designs might be developed and tested or simulated before making physical prototypes. The firmware or applications running on the device can adopt CD relatively easily and can ensure the software components are correctly delivered alongside the hardware.

CD is rapidly becoming the new norm for software development and adoption rates are soaring – around two thirds of organisations surveyed by Evans Data (across the UK and U.S.) are using CD for at least some projects, while 28 percent report using it for all projects. However, the research shows that definitions of CD vary: some respondents view it as automation related, while others see it as related to continuity, time, or process.

Adoption in SaaS versus on-premise

Market perception, and the view of many industry analysts, is that only software-as-a-service (SaaS) companies are currently practicing CD. So have things moved on? Indeed, more than 80 percent of SaaS companies report adoption, with 47 percent reporting use across all projects. However, the survey does show cross-industry uptake among non-SaaS companies, including boxed/on-premise software, hardware/embedded components, industrial goods and services, and consumer goods and services. Within these sectors, 18 percent of
respondents report adoption across all projects and 33 percent across some projects.

What’s driving the move to CD?

To find out specifically why CD is becoming so popular, Evans Data asked participants to rank the top five benefits. “Time to market” and “better quality product” came out on top, followed by “competitive advantage,” “higher customer satisfaction,” and “reduced cost of development.”

Respondents who anticipate a longer adoption time view CD as a large undertaking with a huge payoff. Therefore, understandably, people who think it will take their organisations more than three years to adopt it rank faster time to market much higher than those who think it will take less than two years.

Interestingly, almost half of respondents (46 percent) think their competitors have already adopted CD. This perception – especially compared to the 28 percent of respondents who have fully adopted CD – highlights the role of competitive pressure in adopting proven development systems.

Barriers to adoption

In a bid to discover why all companies aren’t making the move, respondents were also asked to rank the top five barriers to adopting CD. “Integrating automation technologies” (version control, automated testing, etc.) proved to be the largest issue. A close second was “lack of skilled people.” The third-ranked barrier is “lack of collaboration” – or not having the right platform in place to implement CD.

Key actions for successful adoption of continuous delivery in embedded systems

• Version everything – not just source code but test data, environment configuration, firmware images, documentation … If any part of a deliverable is not versioned you only have a partial record.
• Automate everything – or at least as much as is possible. Understand the potential impact of manual elements and implement mitigation strategies.
• Feedback early and often – Automate test plans to be executed on every change or check-in whether hardware designs or software. Review and update plans regularly. Iterate and improve continuously.
• Include all possible configurations – Include in your automated continuous integration process, record in your version management engine.
• Universal usage – Make sure your chosen tools can be used by all non-technical staff as well as the development team for efficient collaboration and versioning. Ensure performance is good for distributed teams.

CD implementation in practice

More than half (53 percent) of respondents in the survey say it would take their organisation less than 12 months to implement CD; 85 percent say it would take less than two years. Furthermore, three quarters of respondents whose organisations have already begun adopting CD say they can move in less than one year, compared with only 41 percent of respondents who have not yet started their adoption. These perceptions differ significantly from the views of some industry analysts, who see CD as a substantial change from most software development organisations’ current practices.

Levels of optimism appear to vary by job role. Executives are more optimistic than developers about how quickly their organisations can change; they are more likely to think that they can move to CD in less than one year.

Finally, looking at the kinds of systems that need to be in place to support CD, nearly all respondents recognise the central role of their collaboration platforms. 71 percent view them as very or extremely important.

Adopting CD for a more efficient future

These figures show that awareness and adoption rates of CD within organisations are much higher than previously thought, and the practice is viewed as both a critical business driver and competitive necessity across industries, not least embedded.

At the same time, the wide range of CD definitions and estimates about the time required to move to CD underscore the need for industry-wide education on: what is comprised; the technology, processes, and cultural changes required; and the benefits and best practices.

The good news is that most software development professionals know that their collaboration platform is a key to their success. Investing in this technology and building competencies and processes around it will help software development organisations to transition more quickly to CD.

Time to market has never been more critical within embedded systems, and ensuring that products fit customer demand and quality requirements first time boosts profitability. CD automates the process of moving those changes through the product life cycle into production as quickly and reliably as possible.

Mark Warren is Marketing Director, Europe, for Perforce Software. Mark has over 25 years experience as a consumer and vendor of enterprise development and configuration management products.

Perforce Software

www.perforce.com