• Save
Cruise control
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Cruise control

Uploaded on

>>Automation of build and release ...

>>Automation of build and release
>>Continuous Integration using ANT and Cruise Control
>>Features of Cruise Control
Using Cruise Control to achieve automation of build and release
>>Metrics, reports and data analysis using Cruise Control
Automated test case execution using EMMA
>>Automated code reviews using PMD

File Can be downloaded from:

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 11

http://www.scoop.it 7
http://www.linkedin.com 3
https://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • sdfsdfsdf


  • 1. www.scmGalaxy.com scmGalaxy Author: Rajesh Kumar [email_address] scmGalaxy.com
  • 2. Agenda
    • Automation of build and release
    • Continuous Integration using ANT and Cruise Control
    • Features of Cruise Control
    • Using Cruise Control to achieve automation of build and release
    • Metrics, reports and data analysis using Cruise Control
    • Automated test case execution using EMMA
    • Automated code reviews using PMD
  • 3. Expectations
    • My expectations
      • Ensure that you understand the usage of CruiseControl
      • Ensure that you are able to setup and configure CruiseControl and schedule an automated build process
      • Ensure you are able to view metrics and test reports on CruiseControl for the automated build
      • Ensure you understand the possibilities of running code coverage tools such as EMMA and code review tools such as PMD using ANT and CruiseControl
      • Ensure you understand how to continuously integrate using ANT scripts and CruiseControl
    • Your expectations ?
  • 4. Automated build
    • A build script itself is a good start point for automation.
    • A build script automates the sequence of steps to be executed per build.
    • However, with increasing need for integration and maintenance of multiple environments, one needs to worry about the availability of bandwidth to perform such tasks
  • 5. Automated build (contd)
    • Automating builds by scheduling builds helps answer the following questions
      • How often should the build be executed?
      • What event should trigger off a build?
      • If a build breaks, how should the cause of build break be routed to the team / individuals?
      • How can a deployment be automated ?
      • Can I avoid the manual work of starting a build ?
      • Can I integrate generation of various metrics, reports after each build ?
  • 6. Automated build (contd)
    • Traditional Automation
      • Build scripts can be automated using any continuous running process on an OS. The process can execute the build scripts at a scheduled time and do other support tasks as well.
  • 7. Automated build (contd)
    • For example, to automate a build script on a UNIX OS:
      • Write a build script that does the normal build
      • Write a batch file to invoke the build script
      • Write shell scripts to run the batch file
      • Write a CRON job to run the shell script
      • Put these tasks in the shell script or the CRON job
        • Send out build results through email
        • Log build progress and output
        • Generate reports for future reference
  • 8. Automated build (contd)
    • There may be a couple of drawbacks in this method of automation
      • Knowledge of scripting required for each OS
      • Non-standard reports across projects
      • Repetitive work for each project
      • More work to code all these standard activities by yourself
      • Tools provide wider variety of options in terms of integration with source control, report generation
  • 9. Automated build (contd)
    • Different method of automation using tools
      • Schedule existing build scripts
        • Tools such as cruise control, bamboo etc. provide us the ability to define an automated build.
      • Monitor builds using web consoles provided on these tools
      • Provide effective feedback on build breaks and code quality using the data reported from such tools
      • Multiple builds can be defined to ensure that a full build and a full application build are automated and kicked off based on different events
  • 10. Continuous Integration (CI)
    • Continuous integration is a term used to describe the process of triggering a build for each incremental code modification
    • The integration is a continuous process and not a big bang approach
    • The term "continuous integration," commonly attributed to Martin Fowler, who first wrote about the software development practice back in 2000 is one of the pillars of modern programming techniques.
  • 11. Continuous Integration (contd)
    • It advices the following rules
      • single repository
      • Event triggered build
      • Self-testing code
      • Commit code continuously (every day at least)
      • Use a production like machine and deploy the integrated build
      • Execute a fast build (take only modified code)
      • Use these builds to tag and monitor the best version of the day
      • Send feedback of breakages, test coverage reports , code reviews etc
  • 12. Benefits of continuous integration
    • The key is to identify bugs early because the cost of fixing a bug early in the project is less than doing the same at a later stage in the project.
    • CI helps in doing this on an incremental basis
    • Ability to use automated builds to monitor build breaks and code coverage on a continuous basis helps in tracking quality
    • Long integration phases are eliminated
    • Customer gets to see new features faster because integration is continuous and faster.
    • Getting (or creating) an executable from the source is so easy.
    • You know when you will be done
    • Project delivery risk is reduced
  • 13. Introduction to CruiseControl
    • CruiseControl is a framework for a continuous build process
    • A web interface is provided to view the details of the current and previous builds
    • CruiseControl is an open-source continuous integration toolkit
    • Originally it was developed by ThoughtWorks
    • It is free for use.
    • Latest version is 2.6.1
  • 14. Introduction to CruiseControl (contd)
    • CruiseControl is a mature tool and enjoys a strong user base in the industry
    • It supports many source control tools such as CVS, Subversion, Clearcase, PVCS, VSS, Perforce and many more
    • It also supports many build tools such as ANT, Maven.
    • Tools such as PMD, JUNIT integrate well with CruiseControl
    • CruiseControl is fairly sophisticated when it comes to running automated builds by detecting changes in the repository
    • Also, it is fairly well built to send out notifications after a build in the form of emails, RSS feeds, Blogs.
  • 15. CruiseControl components (contd)
    • Architecture
  • 16. CruiseControl components
    • Build Loop
      • This component executes the build cycles and is the core to CruiseControl
      • A configuration XML stores all details of a build cycle
      • Inputs to the “build loop” are the config.xml and the source code
      • Outputs of the “build loop” are logs, build artifacts and published reports through email etc.
      • Build cycles are executed based on a trigger such as CVS check in, scheduled time, source code change
  • 17. CruiseControl components (contd)
    • Schedules can be defined on build scripts written using various builder tools such as ANT, MAVEN .
    • A status file is maintained that helps keep track of the next build time
    • A log file is stored for each build that is started which will be read by the reporting component.
    • After the build completes, build reports can be published using various techniques such as email, log, FTP, HTML Email
  • 18. CruiseControl components (contd)
    • Reporting
      • Reports is a web application that runs in a web container such as Jetty (inbuilt) when CruiseControl starts.
      • Inputs to the “reports” component are the build artifacts and XML logs
      • The “reports” component has a web application hosted in a web container through which build details can be viewed
      • These build reports can be accessed through HTTP
  • 19. CruiseControl components (contd)
    • A build results JSP will display the log of the build loop.
    • Left panel of the JSP will display links to details of the completed builds and current builds.
    • Right panel will display details for a build such as build results, test results, changed files since last build
    • The build details right panel is created by applying XSL on XML log files to generate HTML that is displayed on the JSP. This lends to easy customization of this panel to include your own reports.
  • 20. DEMO
    • Demo 1– Display a build Results JSP live
    • http://localhost:8080/
  • 21. EXERCISE
    • Exercise 1 – Setup CruiseControl, View Results
  • 22. CruiseControl Terminologies
    • Project
    • Listener
    • Publisher
    • Schedule
    • Triggers
  • 23. CruiseControl Terminologies (contd)
    • Project
      • Is a basic unit of work for a build loop
      • It will primarily handle the job of arriving at a set of modifications in a project, building the project and publishing results of the project
      • One configuration XML can contain multiple projects
        • For e.g.:
        • 2 projects can be defined on the same source code.
        • One project will build only when a file in CVS changes.
        • The other project will build only on weekends at 4 p.m.
  • 24. CruiseControl Terminologies (contd)
    • Listener
      • Listeners are plug-ins that handle specific events.
      • For e.g.:”currentBuildStatusListener” writes the last built time into a file on the disk.
      • Let’s look at status.txt file
  • 25. CruiseControl Terminologies (contd)
    • Publisher
      • Publisher publishes the build output to a log, through email ,through FTP and through many more ways.
      • Publishing is done after a build has completed.
      • It will be run regardless of whether the build was successful or not.
      • For e.g:
        • xsltlogpublisher : Performs a transformation of the XML log file to HTML
        • htmlemail : Sends an email with the build results embedded as HTML
  • 26. CruiseControl Terminologies (contd)
    • Schedule
      • A build can be scheduled to occur at specific times
      • Alternately, a build can be triggered from an event such as CVS check-in, source code change.
    • Triggers
      • Changes to files in repositories such as PVCS, CVS can act as triggers
      • Changes in a file system can return a set of modified files that can trigger a build
  • 27. CruiseControl plug-ins
    • CruiseControl provides continuous integration as it’s core functionality.
    • All other functionality like publishing, building using builders etc are implemented through plug-ins
    • Plug-ins are represented by beans
    • Plug-in classes are mapped to element names in the XML config file through a process known as registration.
    • Plug-ins distributed with CruiseControl are all registered by default.
  • 28. CruiseControl plug-ins (contd)
    • You can also write your own plug-in and register it with CruiseControl
    • To register your own plug-in class:
      • Directly under the <cruisecontrol> element or within a <project> element, add this: <plugin name=&quot;&quot; classname=&quot;&quot;/>
      • Here “name” attribute corresponds to the name you wish to use within the config file
      • The “classname” attribute corresponds to the actual plug-in Java class.
  • 29. CruiseControl plug-ins (contd)
    • There are currently six different types of plug-ins that CruiseControl supports.
      • Bootstrapper: run before the build
      • SourceControl: poll a code repository and determine if anything has changed
      • Builder: perform the actual building and testing of your code
      • LabelIncrementer: handles incrementing the label for you to use to tag your source
      • Publisher: publish the results of your build, via email for example
      • Listener: handles project events
  • 30. CruiseControl configuration
    • A configuration XML is defined in CruiseControl to configure multiple projects.
    • Configuration XML file is reloaded every time CruiseControl wakes up to check if a build needs to be done. This way CruiseControl need not be restarted every time.
    • However, new projects added to the config XML will be reflected only if CruiseControl is restarted.
    • Several configuration files can be included in one config XML.
  • 31. Config XML scmGalaxy.com
  • 32. CruiseControl configuration (contd)
    • One can define the following elements in a config XML under the root <cruisecontrol> element:
      • Properties - <property>
      • Other config XML’s - <include.projects>
      • New plugins - <plugin>
      • Projects - <project>
    • Note on <property> : It’s just like ANT properties. But it's not entirely first come, first set. Properties set at the global level can be eclipsed within the scope of a project by simply resetting the property.
  • 33. CruiseControl configuration (contd)
    • <project> element can have these sub-elements :
      • Properties - <property>
      • plugins - <plugin>
      • Listeners - <listeners>
      • triggers - <modificationset>
      • Schedule - <schedule>
      • Log file manipulations - <log>
      • Publishers - <publishers>
  • 34. DEMO
    • Demo 2– Run through a sample config XML
  • 35. EXERCISE
    • Exercise 2 – write a config XML
      • Publisher
      • Listener
      • Schedule
      • Log
      • Modification set
  • 36. Scheduling
    • Most common scheduling pattern :
      • <modificationset>
      • <cvs localworkingcopy=&quot;C:Sourcesproject&quot;>
      • </modificationset>
      • <schedule interval=&quot;1200&quot;>
        • <ant antscript=&quot;${dir.javatools}antbinant.bat&quot; antWorkingDir=&quot;${dir.project}&quot; buildfile=&quot;${dir.project}build.xml&quot; target=&quot;integration&quot;/>
      • </schedule>
    • This schedule will execute a build every 1200 seconds if something has been checked into CVS.
  • 37. Scheduling (contd)
    • More scheduling scenarios:
      • The nightly build
        • This will execute a nightly build at 11PM or 2300 hrs only if something has been committed during the day.
        • The “time” attribute determines the time of the build
        • <modificationset>
          • <cvs localworkingcopy=&quot;C:cvsSourceproject&quot;>
          • </modificationset>
        • <schedule>
          • <ant antscript=&quot;${dir.javatools}antbinant.bat&quot; antWorkingDir=&quot;${dir.project}&quot; buildfile=&quot;${dir.project}build.xml&quot; time=&quot;2300&quot; target=“build&quot;/>
        • </schedule>
  • 38. Scheduling (contd)
    • Force Builds:
      • To force a build even if no modifications have been made, you can set the requiremodification attribute to “false” in the modificationset element
    • <modificationset requiremodification=“false”>
    • <cvs localworkingcopy=&quot;C:cvsSourceproject&quot;>
    • </modificationset>
    • <schedule>
    • <ant antscript=&quot;${dir.javatools}antbinant.bat&quot; antWorkingDir=&quot;${dir.project}&quot; buildfile=&quot;${dir.project}build.xml&quot; time=&quot;2300&quot; target=“build&quot;/>
    • </schedule>
  • 39. Scheduling (contd)
    • Different Builds on different Days
      • For e.g.: There are ways to schedule a build for Mondays, Wednesdays and Fridays . A different build can be scheduled for Tuesdays and Thursdays.
    • Pause build
      • There is a plug-in that can help pause a build during a certain period while backing up a server , during server restarts etc.
  • 40. DEMO
    • Demo 3 - Schedule a build if a file on the local file system changes
  • 41. EXERCISE
    • Exercise 3 - Schedule a forced build – even if there is no modification
  • 42. Metrics, Reports in CruiseControl
    • CruiseControl has the option of merging other tool’s reports into it’s log so it can be displayed on it’s reporting JSP.
    • The config XML can be configured to do this using these elements :
    • <log>
      • This element helps configure the location where the CruiseControl log files are stored.
    • <merge>
      • This element is put inside the <log> tag. XML artifacts to merge with the CruiseControl log can be specified here.
      • The most common XML to merge is JUNIT test results that the ANT <junit> task creates.
  • 43. DEMO
    • Demo 4 –
      • Integrating test reports (JUNIT) with CruiseControl web application
      • Integrating PMD reports with CruiseControl
  • 44. EXERCISE
    • Exercise 4 - Integrating CruiseControl with EMMA Reports
  • 45. Triggers in CruiseControl
    • The <modificationset> element under a <project> element contains the triggers for a build to occur.
    • These triggers can be classified into many types:
      • Source Control tool based: These triggers will detect modifications in a source control tool
        • For e.g.:
          • <cvs/>
          • <clearcase/>
  • 46. Triggers in CruiseControl (contd)
    • File based: These triggers detect changes in the file system based on last modified time.
      • For e.g.:
        • <filesystem>
    • Forced : These triggers force a build irrespective of whether modifications have occurred or not
      • <alwaysbuild>
      • <forceonly/>
      • <timebuild>
    • Other-build-status-based: These triggers are based on the status of another build which will be read from a log file
      • <buildstatus/>
  • 47. Triggers in CruiseControl (contd)
    • Optimized triggers:
      • These triggers help optimize searching for modifications
      • Sample : Here CVS is searched only of the text file is modified by CVS
      • <modificationset quietperiod=&quot;1&quot; >
      • <compound includeTriggerChanges=&quot;false&quot;>
      • <triggers>
      • <filesystem folder=&quot;./mod_file.txt&quot; />
      • </triggers>
      • <targets>
      • <cvs cvsroot=&quot;:pserver:user@cvs_repo.com:/cvs&quot; />
      • </targets>
      • </compound>
      • </modificationset>
  • 48. DEMO
    • Demo 5 - Use different triggers to trigger the same build
  • 49. Handling multiple projects
    • Using CruiseControl, multiple projects can be handled.
    • They are configured in the config XML
    • There are multiple strategies to do this.
      • Define multiple configuration XML’s with projects in each and include them all in one master config XML
      • Define multiple projects in one config XML
      • Use a combination of both strategies.
    • Project names must still remain unique. Else, the first project with a given name will be loaded and any subsequent projects attempting to use the same name will be skipped
    • Properties and plug-ins in the master config XML are global and will be available to all included config XML’s on a per instance basis
  • 50. Handling multiple projects (contd)
    • The projects in a config XML are run on a shared build queue.
    • The number of projects that can be executed simultaneously can be configured using a <threads> element in the config XML.
    • If the number of simultaneous projects crosses this number, they will be queued.
  • 51. Scheduling multiple projects
    • Day-and-night builds :
      • Multiple projects can be created to do regular quick CI builds during the day and then a complete build at night
      • Same repository location will be used.
      • Different build targets will be used
  • 52. Scheduling multiple projects (contd)
    • <project name=“CI&quot;>
    • <modificationset>
    • <cvs localworkingcopy=&quot;C:Sourcesproject&quot;>
    • </modificationset>
    • <schedule interval=&quot;1200&quot;>
    • <ant antWorkingDir=&quot;${dir.project2}&quot; buildfile=&quot;${dir.project}build.xml&quot; target=“CI-Build&quot;/>
    • </schedule>
    • </project>
    • <project name=“nightlyBuild&quot;>
    • <modificationset requiremodification=&quot;false&quot;>
    • <cvs localworkingcopy=&quot;C:Sourcesproject&quot;>
    • </modificationset>
    • <schedule>
    • <ant antscript=&quot;${dir.javatools}antbinant.bat&quot; antWorkingDir=&quot;${dir.project}&quot; buildfile=&quot;${dir.project}build.xml&quot; time=&quot;2300&quot; target=&quot;complete-build&quot;/>
    • </schedule>
    • </project>
  • 53. DEMO
    • Demo 6 – Handling multiple projects in CC
  • 54. Advantages of using CruiseControl
    • Use CruiseControl as your CI tool if you want a reactive build that will poll repository for changes and build thereafter
    • Use CruiseControl if you want excellent notification options.
    • More importantly, use CruiseControl if you don’t want to be pigeon-holed as the “Build Guru” of your project for life doing “building and notifying” 
  • 55. Some things to watch out for in CC
    • Checking out code from source control repositories has to be coded by the user (this is configurable in other tools such as Continuum)
    • Does not provide much for build management and inter-project dependencies
    • Visit the link for known issues w.r.t threads, multiple projects http://jira.public.thoughtworks.org/browse/CC?report=com.atlassian.jira.plugin.system.project:openissues-panel
  • 56. CruiseControl Best practices
    • Setup a different CruiseControl project for every branch you create in your CM system.
    • Communicate build results through email to all developers
    • Automate running of minimum bunch of tests after a build to ensure sanity.
    • Put a build label into the build artifacts. For instance, put a build version into the manifest.mf file of your jar
    • Version your CC config.xml
  • 57. Continuous Integration – other tools
    • Most tools support ANT and MAVEN
    • Most tools support commonly used source control repositories.
    • Some tools are :
      • Apache Continuum
        • Apache origin, created by the Maven team
        • Provides pretty much the same features as CC
        • One advantage here is that you do not need to write any script to check out the latest source code from a repository. All you need to do instead is supply the SCM repository details and the build script, and Continuum will do the rest.
        • Uses Cron type expression to schedule builds
  • 58. Continuous Integration – other tools (contd)
    • CCNet – CruiseControl for .net by ThoughtWorks
      • This is a continuous integration server
      • It is a C# equivalent for Cruise Control (which is a Java solution)
      • Supports integration with Nunit, NANT, Visual Studio
      • Remote management and reporting is built-in and well supported by tools such as “Web Dashboard” and “CCTray”
  • 59. Continuous Integration – other tools (contd)
    • AntHill Pro – By UrbanCode
      • This is a continuous integration server as well
      • Ideal for distributed and multi-platform builds
      • Handles dependencies between projects while building
      • Handles automated deployments on multiple environments
      • Handles multiple builds such as CI build, nightly builds, release builds through workflows
      • Handles automated promotion of a build which may involve repackaging build artifacts, deploying build artifacts, creating a baseline on the repository
  • 60. Continuous Integration – other tools (contd)
    • Other tools :
      • CruiseControl.rb - CruiseControl for Ruby
      • Build Forge - IBM Rational software
      • Apache Gump - Apache Origin
      • DamageControl – Thoughtworks origin
      • Tinderbox – by Mozilla
      • LuntBuild – Available on SourceForge, Built by PMEase
  • 61. Integration strategies
    • When defining an integration strategy while building your application’s code, you may want to think about these:
      • Phase-wise integration
      • Incremental integration
  • 62. Integration strategies (contd)
    • Phase-wise integration
      • wait till the system integration phase to actually integrate
      • This is more of a traditional approach and has a number of drawbacks
        • Problems are identified very late and this makes it expensive to fix them
        • Different types of issues may come in at this stage such as compilation issues, incompatible methods, classes and interfaces, runtime issues, unhandled exceptions, missing functionality. Prioritizing become difficult.
        • Project appears too risky at this point
        • Difficult to predict end of project
  • 63. Integration strategies (contd)
    • Incremental integration
      • This has evolved as a learning from the phase-wise integration approach
      • Integrate while you code
      • build and test daily
      • use “Continuous Integration” approach
  • 64. Integration strategies (contd)
    • You may need to integrate all of these. So decide when you want to integrate what
      • Portals – websites, integration with intranet
      • Databases
      • Web services
      • Third party applications
    • Broadly integration can be thought of at multiple levels:
      • Module – intra application
      • Application – across multiple applications in a project
      • Project- across multiple projects
      • Versions/Releases – across multiple versions of a project
  • 65. Good reads
    • Integration with PMD :
      • http://confluence.public.thoughtworks.org/display/CC/CruiseControlWithPMD
    • http://www.martinfowler.com/articles/continuousIntegration.html
    • http://confluence.public.thoughtworks.org/display/CC/MoreDetails
    • http://jira.public.thoughtworks.org/browse/CC?report=com.atlassian.jira.plugin.system.project:openissues-panel
    • http://damagecontrol.codehaus.org/Continuous+Integration+Server+Feature+Matrix
  • 66. Summary
    • We explored :
      • CruiseControl Features
      • Automation of build process using CruiseControl
      • Tools integration with automated build – EMMA, PMD
      • Continuous integration using ANT and CruiseControl
  • 67. www.scmGalaxy.com Thank You ! Author: Rajesh Kumar [email_address] scmGalaxy.com