search.noResults

search.searching

note.createNoteMessage

search.noResults

search.searching

orderForm.title

orderForm.productCode
orderForm.description
orderForm.quantity
orderForm.itemPrice
orderForm.price
orderForm.totalPrice
orderForm.deliveryDetails.billingAddress
orderForm.deliveryDetails.deliveryAddress
orderForm.noItems
Digital Communications


Software development trends - and how they impact embedded developers


Sven Erik Knop, Perforce Software, talks about methodologies and tools needed to be integrated into teams with well-managed and clearly-defined approaches, and how, if they take all of that on board, they can contribute a great deal to the bottom line success of any embedded electronics project


T


he list of software development trends, such as Agile, Continuous Delivery, DevOps, Distributed Version


Control (DVCS) and ‘mono repositories’, continues to grow. Many of these have now become commonplace in the world of mainstream software development and more relevantly, are becoming more prevalent in embedded software design. Methodologies such as Continuous Delivery and DevOps can tangibly reduce time-to-market, while reducing the risk of errors and unnecessary costs. So what exactly do these terms mean, how do they inter-relate and what does ‘best practice’ look like?


Agile


It has been many years since the original Agile manifesto was published and since then, a variety of interpretations and implementation processes have evolved, but a common thread is the focus on bringing a project to fruition quickly, through focused spurts of work. Interestingly, while Agile has been around as a development methodology for some time, it has only recently toppled the traditional waterfall method from its perch, to become far more mainstream. It’s also a


term that seems to appeal to non-technical senior management, because the concept is pretty well understood (and indeed, could be applied to other, non-IT projects). In the world of electronics, Agile can be used to trial out new ideas and only pursue the ones that have real promise. Also, instead of six-month (or longer) cycles until a new release with lots of new features, companies can get smaller sets of releases out to market in just a few weeks, which also makes it easier to get faster feedback from customers and make any adjustments deemed necessary. In this way, less time and money is wasted, plus companies’ development cycles can be far more in tune with customer needs.


Continuous Delivery While different to Agile, the Continuous Delivery (CD) methodology certainly supports Agile efforts, in particular taking Agile beyond the developer’s desktop to the production stage. CD enables businesses to roll out better products faster and safer, allowing software to be released into production at any time. It centres on building a development pipeline where early feedback, automated build and test are incorporated. Benefits include the fact


that what is deployed is what was originally tested, while also supporting smaller, more frequent deployments. For instance, a mobile phone manufacturer can more efficiently introduce a succession of embedded software upgrades.


DevOps


This is arguably the biggest trend in software development right now, DevOps is essentially about bridging the gap between development and operational teams, with the ultimate goal of ensuring swift delivery and completion of software- based projects. While it has more obvious appeal in the world of enterprise software, DevOps can also be applied to the embedded software space, particularly in environments where there is an intensive pipeline of releases or improvements. The success for DevOps, which is all about a far more collaborative and transparent way of working, is greatly enhanced by adopting CD. Applying DevOps will only work if everyone has a shared understanding of what is being developed and what is entering production, instead of just ‘throwing it over the wall’. While culture and processes are at the heart of DevOps, tools do have a role, not least of which is appreciating that both sides will be using different tools and therefore ‘bridges’ between these need to be made. Also, Continuous Delivery (CD) will help achieve the more transparent way of working that is essential to efficient DevOps.


DVCS


This is an approach to version control that has become hugely popular in recent years among developers, allowing them to work on a project without having to share a common network. Fans of DVCS cite benefits such as greater flexibility for the individual user (such as the ability to branch locally, meaning they can create code branches more quickly). However, more centralised version control systems are still hugely popular and continue to be deployed in parallel, particularly in large enterprises where control, traceability and security across the entire development landscape are important. Since electronics design and manufacture typically involves multiple contributors, often from a variety of external sources, making sure that this more all-embracing approach remains in place is very important. The good news is that there is a hybrid approach that straddles both worlds.


Best practice Regardless of which methodology, whether


30 December 2016/January 2017 Components in Electronics


singly or in combination, is being adopted, there are some common requirements. As experience has shown, roadblocks easily occur if these are not observed (which is why some early users of these methodologies got some bad press).


‘Version everything’ This became a popular phrase in recent years and for good reason: it helps create a transparent, collaborative culture, by creating a ‘single source of truth’. In other words, by tracking every change distributed teams can see what has happened, what is happening and who is working on what, all without having to disrupt the individual’s work.


This applies not just to developers, but also, and specifically, to the release management team and relates directly to successful DevOps. A study conducted by Puppet Labs in 2014 found that when trying to predict the success of implementing DevOps for faster and safer delivery, the most important factor was versioning of all tools, configurations and artefacts by the release team. Version management is a natural part of ‘continuous integration’ (CI), a development practice common in the electronics industry that requires developers to integrate code and other files into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.


Bring DVCS into the bigger picture The latest generation of version control tools are being engineered to support both distributed and centralised version control, so, in theory, everyone wins: the developer retains the ability to use his or her DVCS tool of choice (such as Git), while the organisation has the visibility, control and ‘auditability’ of who did what where and when. Other benefits vary according to the particular tools involved, but include prevention of system slow-down (due to the likes of Git having problems handling large volumes of binary code), or ending up with hundreds or even thousands of individual version control repositories created by users (which again, can slow down the whole system and make project- wide visibility nigh on impossible). If the electronics development environment is spread across multiple locations, look for a hybrid DVCS solution that supports a multi-server topology that is able to synchronise across different locations, with clustering and high availability.


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  |  Page 49  |  Page 50  |  Page 51  |  Page 52  |  Page 53  |  Page 54  |  Page 55  |  Page 56  |  Page 57  |  Page 58  |  Page 59  |  Page 60