Transcript Build Systems

Continuous Integration Systems
Shava Smallen
Jim Hayes
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
Continuous Integration
• “Continuous Integration is a software development
practice where members of a team integrate their
work frequently, usually each person integrates at
least daily - leading to multiple integrations per day.
Each integration is verified by an automated build
(including test) to detect integration errors as quickly
as possible. Many teams find that this approach
leads to significantly reduced integration problems
and allows a team to develop cohesive software
more rapidly.” -- Martin Fowler
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
Choosing a CI System
A useful CI system should support
• Retrieving source from varied revision control systems
• Building software and running tests on systems with
varied architecture/os/software configuration
• Transmitting build/run results to display machine
• Configurable summaries of results
• (Bonus) tracking changes to software
• (Bonus) easy, flexible configuration
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
Outline
• Four CI Systems
•
•
•
•
Condor Build & Test
CruiseControl
Tinderbox
DART
• Example: CruiseControl
• Summary
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
Condor Build & Test
• Pluses
• Flexible definition of automated checkout/build/test steps
• Easy access to varied build hosts
• Built-in transmission of results
• Minuses
•
•
•
•
No planning for reuse of CI system during development
Welded to Condor
Fixed display
No documentation
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
CruiseControl
• Pluses
•
•
•
•
Automated checkout/build/test
Built-in transmission of results
Good support for tracking software changes
Configurable display
• Minuses
• Strongly tied to Java/Junit/Ant
• Single build host
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
Tinderbox
• Pluses
• Supports multiple, varied build hosts
• Highly configurable display
• Good support for tracking software changes
• Minuses
• No automation of checkout/build/test
• Conventional configuration requires friendly sysadmin
• Result transmission via mail?!?
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
DART
• Pluses
•
•
•
•
Supports multiple, varied build hosts
Easy transmission of results
Flexible result summaries
Integration with CruiseControl
• Minuses
• No automation of checkout/build/test
• C/C++ bias
• Poor documentation
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
Outline
• Four CI Systems
•
•
•
•
Condor Build & Test
CruiseControl
Tinderbox
DART
• Example: CruiseControl
• Summary
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
CruiseControl
• Features (partial):
• Lots of support for Java projects
• Very easy to install & setup
• Build & test can be triggered by SVN/CVS check-in or ondemand (web page trigger)
• Email notifications can be setup on error
• Configurable
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
Installing CruiseControl
• Download cruisecontrol-bin-2.5.zip from
http://cruisecontrol.sourceforge.net
README.txt
apache-ant-1.6.5
artifacts
config.xml
connectfour.ser
cruisecontrol.bat
cruisecontrol.log
cruisecontrol.sh
docs
lib
logs
projects
webapps
• % nohup ./cruisecontrol.sh -webport 9011 >&
cruisecontrol.out &
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
CellTest.java
package
net.sourceforge.cruisecontrol.sampleproject.connectfour;
import junit.framework.TestCase;
public class CellTest extends TestCase {
public void testConstructor() {
Cell newCell = new Cell(10, 5);
assertEquals(10, newCell.getColumn());
assertEquals(5, newCell.getRow());
}
}
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
Configuring CruiseControl
• Projects contained in config.xml
• Each project can have
•
•
•
•
•
Listener - log file written to logs/<project>/status.txt
ModificationSet - e.g., SVN/CVS diff
Bootstrapper - e.g., SVN/CVS update
Schedule - how often to check for changes, ant call
Publisher - on success/failure - log, email, etc.
• Build.xml needs to contain junit task using XML
formatter
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
Config.xml
…
<project name="branches-inca-common-java">
<listeners>
<currentbuildstatuslistener file="logs/${project.name}/status.txt"/>
</listeners>
<bootstrappers>
<svnbootstrapper localWorkingCopy="projects/${project.name}" />
</bootstrappers>
<modificationset quietperiod="30">
<svn localWorkingCopy="projects/${project.name}"/>
</modificationset>
<schedule interval="300">
<ant anthome="apache-ant-1.6.5" buildfile="config/${project.name}.xml"
target="test"/>
</schedule>
<log dir="logs/${project.name}">
<merge dir="projects/${project.name}/inca-common-java/test-results"/>
</log>
</project>
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
Build.xml
…
<target name="run-tests"
description="run the unit tests included in this package">
<mkdir dir="${tests.output}"/>
<junit printsummary="yes" fork="yes" timeout="180000"
showoutput="no" >
<classpath refid="classpath"/>
<formatter type="xml"/>
<batchtest todir="${tests.output}">
<fileset dir="${build.src}">
<include name="**/*Test.java"/>
</fileset>
</batchtest>
</junit>
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
Outline
• Four CI Systems
•
•
•
•
Condor Build & Test
CruiseControl
Tinderbox
DART
• Example: CruiseControl
• Summary
SAN DIEGO SUPERCOMPUTER CENTER
UCSD
Summary
• Current freely available CI systems are crude
• CruiseControl is a good choice for Java-based
projects
• CI Comparison Chart:
• http://docs.codehaus.org/display/DAMAGECONTROL
• (Click on “Continuous Integration Server Feature
Matrix”)
SAN DIEGO SUPERCOMPUTER CENTER
UCSD