Author Guidelines for Proceedings of ISATE2005
Total Page：16
File Type：pdf, Size：1020Kb
Software Build Management Peculiarities when Working for
a Wireless Device J.T. Kokko*
* Oulu University of Applied Sciences, School of Engineering, Oulu, Finland, [email protected]
Abstract control submissions. Software build management generally includes compilation support, software In this paper some peculiarities related to version control management, integration support, software build management of wireless device sanity testing and delivery management support. software are discussed. These include complexity of In this paper some of the common problems the systems, multiple target platform compilations faced on software build management, when and challenges on automated testing. As software working for a wireless device, are discussed. build management is needed only on large scale software projects employing many people, relative Nowadays the lot of wireless device software simple short range wireless systems will not be development is done with continuous integration discussed and example devices are from mobile process. This will generally lead to a high phone industry. As background information, an workload on software build management as introduction to build management will be given. As software packets demand different kind of build technology and industrial software processes support on different phases. changes rapidly, more issues may rise and some As all parts should be moving all the time and issues discussed on this paper may become all time consuming parts of the software obsolete. deployment process will become critical, Keywords: build management, wireless device, everything that can be automated needs to be mobile, peculiarities, target platform compilation. automated. This includes software development effort stages from developer submitting his/hers 1 Introduction code to preparing software delivery.
Software build management is a process of 2 The Peculiarities combining multiple software packets into a small set of standalone software deliveries, for example To understand why these peculiarities affects into embedded device software image. A software to software build management, one needs to packet can be about anything from “Hello world” understand how build management, embedded application to a wireless modem driver to a 3D device programming and wireless device game. Most often the software packages aren’t programming works. ready when those are included first-time and require recurring updates via desired channels that 2.1 Wireless device programming can vary from file delivery in mail to version While programming an embedded wireless kind of emulator the code can be tested and device such as mobile phone or a base station, debugged on PC but all target devices doesn’t there’s few extra issues compared to for example have an applicable emulator, and some of the windows software programming that needs to be tests like radio link testing is impossible. taken into account. Some of the issues are trivial, such as selecting the right tools to get the correct The connection used to get the software to a target platform compilation, but some demand target device can often be used also for testing more detailed planning. and debugging on a target device. For example USB connection can be used to transfer data to The main issue when programming for any and from device. Analyzing this software usually embedded device is to get the correct target platform support for the compiled packet. Almost all of the embedded devices uses different processor architecture that the computer used for programming, typically to ARM processors whereas PC’s use Intel compatible processors [1]. Also other device hardware might add requirements for target platform support. Most of the time overcoming this issue is simple; one needs Figure 1. CI Development cycles to use correct tools for software compilation.
Another important issue when programming for requires target device specific program on PC. any embedded device is limited resources. This Another possibility is to use logging on software requires good software architecture and coding and import the logs via data connection from guidelines as well as code performance target device. evaluations. Some help for the issue might come from using target platform and/or compiler specific Both of the above methods work on most optimization settings. cases, but device startup from time before for example USB connection is initialized is usually impossible. That kind of issues usually needs to Common embedded device issue is how to get be traced via Lauterbach or similar hardware the compiled software into the target device. debugger so that runtime registries can be Usually there are few solutions with their pros and accessed. cons. One common solution is to use an USB cable and device or manufacturer specific PC program. One issue can’t be completely dealt with and it Other possible solutions include external flashing mostly affects to data connection testing; the device and for wireless devices a possibility to chaotic nature of wireless connections. No update over network. wireless connection is completely stable and free of collisions and signal strength changes. 2.2 Wireless device testing and debugging 2.3 Build management process One of the hardest issues is how to test and debug the software. With UI application the UI Software build management, as a part of a testing is quite straightforward, but everything else development effort, is a process of combining is bit harder that with PC software. With correct software components into one package or into a set of packages [2]. A Software component can be 2.4 Issues affecting build management anything from a simple text file to a standalone program included to the end result. The resulting Because software build management affects package is most often either an installable file, or a everything in a development effort developer device image. submitting code to starting to deliver software packets to client (which is software release Hardware build management refers to the effort management and in many cases bundled with designing and constructing the device hardware software build management), affecting issues and will not be handled on this paper. comes in numbers. There are many common problems related to build management but in this Software Build management process usually paper we focus to the ones that are wireless includes software configuration management. This device specific. process is used to deliver new content to be build, and sometimes also to deliver built packages When starting a build management process the forward. main thing is to select appropriate tools from the beginning. Changes on used tools will always As build management is using and relying to the increase work effort and cause instability and SCM process heavily, also setting up and risks to project. When project is for a wireless maintaining this process is often set as part of build product, the most important tools are the management process. compilation tools. Selecting compilation tools If development effort is done using continuous usually affects to operating system selection of integration processes, build management process the build machines aka computers used to might consist of multiple compilation sets done compile the program. parallel and on different levels or gateways. Each Key issues are both stability and speed – if level includes similar stages such as compilation compilation takes days or compilation results and testing, and may require large amount of can’t be reproduced the whole development resources. Most often the resource amount needed, effort wont progress. such as the level of testing, increases on higher levels of process cycles. Figure 1 demonstrates this For example, if the target device is ARM based process. product and most of the software is done with C, a good tool would be the Gcc compiler available Continuous development cycle might contain on Linux [3]; it has good support for ARM based compilation of changed components, i.e. partial processors, it is maintained well and developed compilation, and light sanity testing. Continuous continuously, it is relatively fast and it’s widely review cycle might contain partial compilation and used. Other tools are also available, some might additional code review and interface checking. be even better on project’s purpose. Hourly or continuous master cycle could do a full compilation and more thorough testing. Daily or Development effort’s code might also include nightly cycle might add regression testing and other languages such as Java, C++ and multiple target package compilations. Weekly or Assembly. In such case the build management bi-weekly release cycle generally adds long period process needs to support also those languages. testing and generates the package deliverable for Used compiler doesn’t have to be the same (and the client. it is often impossible) but every part of the compilation needs to be done with appropriate tools. Also, some components of the software might want to use optimization flags when can be compiled parallel. System software compiling so that kind of changes needs to be architecture effects on parallelization as supported. dependencies between components limit the possibility to compile those simultaneously – A common way to support such kind of good dependency handling is needed. multilingual software environment is to add a build framework to the process. The framework will use Empirical testing shows that in most cases instruction settings for each software component parallel builds are fastest when used amount of on how to compile it. This will enable default parallel compilation threads are two times the configuration for a component structure and count of visible processor cores on system. All possibility to adjust compilation settings by build frameworks do not support parallel component when needed. building and in many cases – including Maven – the parallel building support is on experimental One example of a build framework is Apache level but works on most cases. Maven which uses hierarchical XML files to describe build configuration [4]. Figure 2 Parallel builds can also include parallel demonstrates the configuration file. compilations. If for example system includes This kind of hierarchical approach helps on parallel components written in C and the Gcc separating different configurations but still do all of compiler is set to use multiple cores, both the compilations with one command. There are component level and component specific also other similar build frameworks, some of which compilations are done in parallel. This kind of are better, faster and more reliable, but Maven is multi-level parallelism is sometimes hard to easy to understand and configure. comprehend for both people and computers, especially when working with complex software Another important feature on build frameworks systems like wireless devices which source code is parallel building. This feature helps on making includes many kinds of dependencies both inside use of multi-core computers as many components and in between software architecture layers.
Higher level automated testing, such as integration, system, acceptance and regression testing, needs either a very good simulator or a On a continuous integration process the time is real device. Usually this requires a test always critical. Parallel compilations on build framework that can communicate with build frameworks helps quite a lot – full software framework to get the source package, upload it to compilation time might improve from 21 to 3 hours the device, run the tests and report the results. if sequential compilations are changed to parallel From build management perspective the with good enough hardware. complexity of test framework communication depends on both required communication needs In case of complex wireless devices the and stability of the testing. For example if a compilation itself is usually not enough as same system testing is done by test framework on a code might need to support multiple hardware device and includes high speed data transfer versions, products or even hardware platforms. testing, results might vary a lot between test This requires a lot of resources on software rounds due data path variation. packaging time. For example if the code base supports three different platforms, for one platform If the build framework needs the test results ten different products, for three products two before continuing, slow data connection would different hardware revisions and for all products delay the process or even fail the testing. If two types of images (normal and testing images), continuous integration process is also used, the packaging stage needs to produce 25 different waiting time of the above test needs to be limited images. Typical complex wireless device image before continuing, resulting a build deemed takes about five minutes to create, so above broken even if it would work on reality. example would take about two hours to complete. As a working build is needed for keeping the As packaging the software means combining a continuous integration process healthy, build set of combined sources to a single package, can’t be broken without investigation, and if the multiple target packages can often be easily done investigation takes time the whole continuous in parallel. As the packaging uses disk I/O more integration process might be required to be than processing time, parallelization might not stopped. From build management perspective speed up the packaging process as much as test automation can and should be used to see expected. that everything is working, but the problems caused. As software development effort with continuous integration process runs on many fronts and time is 2.5 Results and Discussion of essence, most of the testing needs to be automated. Usually the unit tests are done by the The most common peculiarities affecting developer, especially on test driven development, software build management for a wireless device but their tests can be reused later to test full are related to challenges on fast and reliable compilations, amount of parallel processing [2] http://allscm.com/build-management, read required due common continuous integration date 10.04.2013 processes, vast amount of target packages required [3] http://gcc.gnu.org, read date 20.04.2013 and challenges on test automation. [4] http://maven.apache.org, read date 17.04.2013 Compilation related problems including [5] compilation time can be at least adequately solved http://en.wikipedia.org/wiki/Software_testing, by selecting correct tools and frameworks. Best read date 20.04.2013 solutions require good software architecture and distinct software components.
Amount of parallel processing is dictated by used processes. Balancing for example the continuous integration process between compilation needs, needed review cycles and adequate testing helps reducing the parallel processing, but single compilation process is usually not a good solution due different needs of the developers, testers and the client.
Amount of target packages depends of the supported products and hardware revisions, so only improvement can be found from doing packages in parallel.
Test automation challenges derived from embedded wireless device environment can be solved adequately in many ways but none of them are guaranteed to cover everything. Human interaction on testing is still needed.
2.6 Conclusions
Wireless device specific build management peculiarities are mostly different kind of challenges. However, all challenges can be solved on an adequate level with good project planning and selecting the right tools and methods for specific target device needs.
References [1] http://en.wikipedia.org/wiki/ARM_architectur e, read date 20.04.2013