Embedded Technology
The benefits and challenges of
DevOps at scale in embedded design
One of the most talked-about software development methodologies in recent years is DevOps (literally, a portmanteau of DEVelopment and OPerationS). Originally stemming from the enterprise IT world, DevOps is experiencing increased adoption in a variety of other markets, including electronics and within that, embedded projects. Chuck Gehman, Perforce Software, tells us more
T
his methodology has much to offer – more on that shortly – but like any methodology, its value lies in successful implementation, not theory. One of the biggest drivers for DevOps in the electronics market is the need to manage large volumes of complex files which must be shared between globally distributed teams, locations, contributors, systems and platforms. The need to support large binary files has long been present in the electronics market, but more recently catalysed by the Internet of Things. The aim of DevOps is to break down the traditional siloes that have existed between development and operations’ teams, to enable higher throughput from development to production through better collaboration
and visibility over the entirety of a project, at every stage of the lifecycle. Benefits include faster-time-to-market, more rapid feedback so that what goes into production meets customer needs, plus support for compliance processes. These days, projects have more ‘moving parts’ than ever before, which is why they look to methodologies like DevOps to overcome the time-to-market challenges that increasingly complex design projects present. This need to manage complexity ‘at scale’ is often the driver for DevOps adoption in the electronics market, but ironically, it is also the difficulties of achieving ‘DevOps at scale’ that cause some DevOps projects falter.
Unless these difficulties are addressed, it will be hard for many organisations to move DevOps adoption beyond team-level adoption. This matters, because many of the organisations investing in DevOps right now are doing so with a view to achieving enterprise-wide benefits: after all, many projects span multiple teams, contributors and locations. Fortunately, there are some clear strategies for tackling ‘DevOps at Scale’ that have been successfully implemented by a wide variety of firms, many of which are in the electronics sector.
Cultural
The first important step is to engender the right working culture. Think beyond functional siloes, rather than development, operations and security as separate entities. There needs to be a mix of skillsets on all teams, with individuals have clear understanding of their responsibilities across the whole software lifecycle, as well as support from management for a more collaborative, open way of working. Agile, a complementary and equally popular methodology, sits alongside DevOps well, to improve the cadence of software development projects.
The right cultural attitude must be the foundation, but that needs to be supported by the right approach to technology – tools, designed with collaboration and cross-organisation workflows in mind. Successful DevOps also requires tools that support different types of users, across developers, designers, operations, QA and testing, external contributors and management.
Flexible tooling strategy There’s a balance to be struck between creating toolsets that support consistency, reporting and compliance, versus giving teams the flexibility to choose their favourite tool. Dictate which tools to use and run the risk of teams finding their own solutions. The answer is to consult with those teams early on, soliciting their input and expertise, so that team members feel part of the process. This ensures that remote workers are given distributed, local flexibility, while still being part of and having a better understanding of the bigger picture.
Allowing a team to adopt its chosen tool will require open support for flexible integration, plus an architecture and
14 March 2018 Components in Electronics
platform for scaled operations, to be mandated, with APIs creating a solid baseline for integration and interoperability. On the other side of the coin, avoid ‘tool sprawl’, a situation where most teams get customised toolsets, which costs money, not just in terms of licences, but also maintenance and training.
Legacy tools also need to be aligned with DevOps: older solutions may no longer be possible with projects ‘at scale’, particularly if they’re built around longer development processes and traditional waterfall processes, so may need updating or replacing. Again, choosing tools that have an open and flexible API framework will help hugely. Make sure that tools are properly designed to support all the necessary kind of assets involved in electronics (diagrams and other binary files), not just a clunky workaround, that can bring its own management problems down the line. For instance, the Git version control tool is popular among developers, but it is not inherently strong ‘at scale’, nor for supporting binary file types. Fortunately, there are tools and techniques now available that enable Git to be part of larger, more complex projects.
Automation
A vital part of DevOps at scale is automating as much as possible, to avoid resources being unnecessarily wasted, to speed up a project and to reduce the risk of error. Automation depends on simplification of processes into clear and unambiguous steps. For instance, most testing tasks have a simple ‘pass’ or ‘fail, which should be simple to automate. Hand-in-hand with automation goes creation of development DevOps pipelines that move software and other dependent content (such as hardware, multi-media and other binary files), through the entire lifecycle.
DevOps at scale is entirely achievable, given the right approach to processes, work culture, tool choice and framework. In the electronics design industry, enterprise-wide DevOps has the power to help businesses meet market demand rapidly, on a scale that previously seemed impossible to achieve.
www.perforce.com www.cieonline.co.uk
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48