USING SYNERGY WITH CRUISE CONTROL

Transcription

1 USING SYNERGY WITH CRUISE CONTROL by Brian Wise Medtronic, Inc. Prepared for the 2008 Telelogic Americas User Group Conference

2 Abstract USING SYNERGY WITH CRUISE CONTROL Continuous Integration and automated testing are both areas that contribute to the Agile programming environment. CruiseControl is a good, open-source tool that provides Continuous Integration features. It has a modular architecture that offers integration with many different source control and build tools, including Synergy. However, each project may have different components and build requirements. As such, the steps needed to check out, build, and test code will differ from the individual components to various different end products. The default Synergy plugin that is distributed with CruiseControl works well for any task based project. Even projects that contain sub-projects in different releases can have their reconfigure templates modified so this plugin works. This approach works well, but does not always meet the needs for every project. For example, a project may consist of baseline sub-projects that represent different modules it uses. Task based reconfiguration is not well suited for this situation, as the product should only be rebuilt when there are new baselines. However, with the command line support in Synergy and a few custom scripts, it is possible to get these baseline based projects to build correctly. This paper will cover some of the task based integration of CruiseControl with Synergy (based on the CruiseControl Wiki work), as well as getting baseline-based projects to check-out, build, and test. Author Biography Brian Wise Brian Wise is a software engineer with Medtronic Navigation. Brian has 7-years experience developing commercial software products along with experience developing the tools and processes to support software development by large teams. Brian has an MS in Computer Science from the University of Colorado. Brian Wise, Software Engineer Medtronic Inc brian.wise@medtronic.com

3 SCENARIO Several different methodologies can be used for software development. These range from relying heavily on up-front planning, such as the waterfall model, to more adaptive methods in Agile development. Depending on the organization and project, one methodology may be better, or some combination of them may be suitable as well. For example, a project with fixed requirements that will not change may do well with more up front planning, while one with requirements that may change can benefit from a more adaptive method. One of the key ideas in Agile development is integrating on a more frequent basis. If this is done, then the cost of integrating all the different components at the end of implementation is reduced as issues are discovered and addressed throughout the implementation of the software. However, when a product has many different components, it may be desirable to give the individual components some control on how they release code to the overall product. Medtronic Navigation uses several different build technologies. This presents a challenge for finding the best way to balance some Agile techniques while still maintaining control for individual components. Using Synergy has assisted in this, especially with the task-based control. However, as the architecture of the products has evolved, new build challenges have arisen. These will be discussed in the next section. OBJECTIVE/PROBLEM When there are multiple software products produced, it is possible for each of them to be completely independent. All code in one product will not affect the code in another. However, if there is similar functionality between products, it is possible to share common components between products. This can be seen as similar to common libraries used when developing code, except these are maintained internally. Moving to a code-reuse design has several benefits. Changes only need to be made in one place, and updates and enhancements can be seen by any software that uses a certain module. However, there are also some challenges when using this model. For example, updates to a component may cause undesired results in software that uses it. In addition, it has been desirable to update more frequently on the component, but still let a module control its use in the overall application.

4 There are currently several applications that use common components to take advantage of common functionality. The strategy of reusing code has provided the benefits discussed above, but has also presented those challenges as well. Figure 1 depicts an example of how several applications use components. Repository Application A Widgets & Elements Viewports I/O Modules Algorithms Reuse Strategy Reuse Configure Extend Modify New Application B Common Data Model Figure 1 One possible solution is to allow each component to be developed individually. This allows for frequent integration of any sub-modules it uses, as well as constant testing and feedback for the developers maintaining a component. Using Synergy s task-based reconfiguration has been useful in this regard, as it allows updates to components to be checked in and a prep project to be integrated. Problems can be addressed as they are seen in the prep project. However, having these propagate to the main product isn t desirable as builds and testing break. As such, an alternative is needed to give more control over the component releases. This is solved by having a product include component baseline projects. That way the component developers have some control over the stability of code that is released to the product. However, these updates should occur frequently, otherwise the value of integrating frequently is lost.

5 Thus, a strategy of using Continuous Integration for the components, while allowing the baselines to control release of these components to the main product can be used. There still needs to be a way to accomplish and manage this process, however. This is discussed in the next section. SOLUTION As discussed above, each individual component is maintained as a project in Synergy. These are updated and maintained using the task-based reconfigure provided by Synergy. A main product would then be maintained as a Synergy project that consists of baselines of each of the components. These baselines projects are updated when new baselines come out. In addition to this setup, a method is needed to control the building, testing, and reporting of both the individual components and the main product. CruiseControl, an open source product, was chosen to handle this. First, a brief discussion of CruiseControl will be given, and then the solutions for integrating it will be presented. CruiseControl is a good tool for providing Continuous Integration, and has a modular architecture. It consists of three main modules: the build loop, the legacy reporting application, and the dashboard view. The build loop is the module that deals with checking out and building the code, and it has plugins that allow it to interface with various source control systems, including Synergy. It also has plugins for pre-build, build, and post-build actions, which include methods for Synergy as well. Using the default plug-ins for Synergy (which make use of Synergy s command-line interface on the back end) is pretty straightforward for building the individual components. The CruiseControl site, along with the Wiki, provides good information on how to accomplish this. It basically describes how to set up the configuration file and configure the Synergy plugins to achieve a Continuous Integration build. Discussion on the site is also good for how to structure projects, and some of the issues that arise when reconfiguring, as well as when running post-build tasks. The Synergy plugin is based on task-based reconfiguration. While this is good for the individual component projects, it does not handle the baseline based product projects well. As such, some custom scripts were needed. A basic outline of how this fits together is shown in Figure 2.

6 Cruise Control Custom Scripts Release Area Synergy Build Area Figure 2 Custom scripts were developed to handle updating the baseline projects, determining the build order, and building/testing the project. Thus, the CruiseControl configuration simply calls the custom scripts to build and then reports the results. The custom scripts handle all management of the project, including all interaction with Synergy. It is true that a new plugin could be developed for CruiseControl to handle baseline based projects, but there were several reasons why this was not done. When CruiseControl starts a build, the custom scripts first check the project and update any baselines. This uses a combination of ccm query, ccm prop, and ccm rp commands to get information about the project and baselines. The project is then checked out using the ccm wa_snapshot command. Control is then passed to the build tool, which is a modification of scons. Tests are run, and the results of the build and test are returned to CruiseControl. RESULTS Overall, having two solutions for building the different types of projects worked well. The default Synergy plugin for CruiseControl works well for task based reconfigure projects. However, some more logic is needed for baseline based projects, and is provided by the custom scripts. It was essential to use the command line interface of Synergy to automate the process. The Synergy plugin for CruiseControl uses the command line interface as well, and this would not be possible without the command line support in Synergy.

7 So far, all testing has gone well. Test projects are able to be built, tested, and deployed to the internal product area. As soon as the current development cycle is complete, the new build system will be rolled out into production. There are still some areas for improvement, however. These include automating baselines, closer control of version numbers, and improving the reporting. However, these can be managed manually until the automation steps are built in. The CruiseControl website has a detailed configuration reference for defining a project. The Wiki provides excellent information, and should be used to get a good understanding of how to use CruiseControl for normal, task-based projects. Depending on the specific build environment, the custom scripts will need to change to accommodate project layouts and build tools. Using the Synergy command reference guide proves invaluable to select the right command line options to use when performing Synergy tasks. RESOURCES [1] CruiseControl Wiki Home - [2] CruiseControl Synergy Plugin Page - ynergy [3] CruiseControl Home -