EDA & Development
system should help resolve the conflicts with complete change history. Compliancy, audit-ability and traceability
are key requirements in many industries. They require the ability to maintain records of what is being implemented, what is changing and who is making the change. The only way to ensure compliance is via a version management repository that can securely store all assets generated during hardware designs, software source code, documentation, test plans and test results. When selecting a version management system, it is critical to consider a few key capabilities: Versioning everything – many systems
were built purely for software source code which is typically in the form of relatively small text files. Can the system also handle large chip designs, graphics, and other large binaries? Can the system handle large files with high performance? Usable by everyone – not every contributor to a project is a software engineer which is the focus for many version management tools. As well as good integrations with the most common Integrated Development Environment (IDEs) such as Eclipse and Visual Studio, how easy is it for designers, authors or project managers to use? Scalable for very large projects and very large teams. Many teams are geographically distributed. Does the system have flexible deployment architectures that can adapt to your changing requirements? Are there complex and expensive add-ons required to achieve that?
Automating for profit
Once the version management system is in place then automating processes becomes viable - and the more automation that can be achieved, then the lower costs and delivery times become. If building, testing and deploying changes relies on manual processes then errors will occur. That could be for any number of reasons such as the “expert” that normally does the releases not being available (for example, the change is out of office hours or the expert is no longer with the organisation) or some change in the environment that has not been accounted for.
Automation is also critical for compliancy. Imagine having to complete the required documentation for a new piece of medical hardware without automation – how do you track activities and prove the correct processes were defined and, importantly, followed without automation? However, manual processes may still be needed in some situations.
Learn & adapt Once automation really starts being used then you can start optimising the process. This uses “feedback” and can be collected at different stages across the development lifecycle. The earlier this feedback is collected and pushed back into the development process, the easier and cheaper it is to make changes. Feedback from an automated build & test system is invaluable. Feedback from the customer is valuable, but comes very late when it’s difficult to make changes quickly. Continuous Integration is building and testing a component or system on every check-in to the version management system. That doesn’t mean all testing gets run on every check-in, but an important subset will be. These tests might verify the
www.cieonline.co.uk
Key actions for successful adoption of continuous delivery in embedded systems:
1. 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.
2. Automate Everything
Or at least as much as is possible. Understand the potential impact of manual elements and implement mitigation strategies.
3. 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.
4. Include all possible configurations
Include in your automated continuous integration process, record in your version management engine.
5. 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.
core functionality or validate regressions haven’t been introduced. Some automation systems put extreme loads on the version management engine so having one that can scale for such usage is critical. Choosing which tests get run at this stage is also very important. They have to be a reasonable validation, but also run quickly enough not to bring the development teams and systems to a halt waiting for test results.
Conclusion Time to market has never been a more critical element of product development for embedded systems. Ensuring that products fit customer demand first time and have the required quality and flexibility for future development is what makes products profitable. Agile methods and Continuous Integration offer a chance to address these challenges during the development phase. Continuous Delivery automates the process of moving those changes through the product lifecycle into production (or at least Integration Testing) as quickly and reliably as possible. A strong version management tool is required to enable distributed, multi-skilled teams to fully exploit the promise of Agile methods and CD.
Perhaps if CD is successful in your organisation that retirement to the coast isn’t quite as impossible as it seems!
Perforce Software |
www.perforce.com
Mark Warren is Marketing Director, Europe, for Perforce Software
Components in Electronics October 2013 33
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