slides

advertisement
Continuous Integration
Peter Rautek
Institute of Computer Graphics and Algorithms
Vienna University of Technology
History
Daily Build and Smoke Test [McConnell 1996]
Daily (automated) build
Test
Present results
Motivation
Quality
Pinpointing problem
Social aspect
Example - Windows NT
5.6 million lines of code
40000 source files
19 hours builds (on several machines)
Peter Rautek
1
History
Continuous Integration [Kent1999][Fowler2000]
Continuous quality control
Small pieces of effort applied frequently
Opposite of quality control after development
Benefit(s)
Early detection of bugs
Disadvantage(s)
Higher costs
Peter Rautek
2
Best Practices
Source code repository
Automated builds
Automated testing
Everyone commits every day
Every commit (to trunk) is built
Keep build fast
Build in clone of production environment
Transparancy of build reports
Nightly builds available (to everyone)
Automated deployment
Peter Rautek
3
Implementation
Small independent components for very
specific tasks
Testing
Documentation
Building
Deployment
etc.
Server that coordinates the tasks
Custom scripts
Automated build server software
Peter Rautek
4
Automated Testing
Test driven development
Unit Testing
Write code plus tests
Tests specify
expected behaviour of functions, classes,
modules, etc.
preconditions and expected result
Execute tests frequently (at least for each
checkin)
Early detect changes that break expected
behaviour
Peter Rautek
5
Unit Testing
Library that handles test cases
Test case inherits a TestClass
Runs tests on target classes
Java:
Junit tests
Others ~20
C++:
CppUnit: port of Junit
Google C++ Testing Framework
Others ~40
Peter Rautek
6
CppUnit Example
Peter Rautek
7
Documentation Generation
Parses source code
Special comment blocks
Principles
Keep documentation close to code
 Easy to maintain
Expose project structure
 Good overview
Link documentation to source code
 Exploration tool
Peter Rautek
8
Documentation Generation Tools
Peter Rautek
9
Documentation Generation
Cross plattform ~20
C++ ~10
Free ~5
Do not completely suck ~1 
For Java ~2  Doxygen, Javadoc
Peter Rautek
10
Example Input
/**
* \class [classname]
*
* \brief [brief description]
* \details [detailed description]
*
*/
/**
* \brief [brief description]
*
* [detailed description]
*
* \param[in] [name of input parameter] [its description]
* \param[out] [name of output parameter] [its description]
* \return [information about return value]
* \sa [see also section]
* \note [any note about the function you might have]
* \warning [any warning if necessary]
*/
Peter Rautek
11
Example Output
...
Peter Rautek
12
Documentation Best Practice
Do document
Interfaces of modules
Public functions
APIs
Public Classes (concepts)
Don‘t document
Private functions and internals
Obvious stuff
e.g., ./** This method returns the value **/
public void getValue()
{
return value;
}
Peter Rautek
13
Automated Builds
Rules: code and dependency organization
Framework: extendable by plugins
Plugins: compile source code, build javadoc,
package classes, deploy files, create reports, run
unit tests, ...
Project Object Model (POM)
XML file with meta-information
Best known for dependency management
e.g., project depends on jUnit version 3.8.1
Does a lot of other things
Peter Rautek
14
Project Object Model
Peter Rautek
15
Maven Summary
Very powerful command line tool
IDE integration (e.g., eclipse plugin)
Java world (de facto standard?)
C++ alternatives ?
Native ARchive (NAR) plugin for maven
(never tried)
(never tried)
Peter Rautek
16
Automated Build Server (Hudson)
Continous integration server for Java
Open source (MIT-license)
Powerful web interface
Peter Rautek
17
Hudson Features
Build summaries
Javadoc
Test summaries
Junit test details
Email notifications
Rss feeds
and more - see http://hudson-ci.org
xUnit plugin for C++ projects (never tried)
Peter Rautek
18
Summary
Continuous Integration is best practice in
software development
Development cycles are
Quick
Tested
Transparent
Tools
Commercial
Free
Peter Rautek
19
References
[McConnell 1996] Steve McConnell, Daily Build and Smoke Test, Best
Practices, IEEE Software, Vol. 13, No. 4, July 1996
[Kent1999] Beck Kent , Extreme Programming Explained. ISBN 0-20161641-6, 1999
[Fowler2000] Martin Fowler, Continuous Integration,
2000, http://martinfowler.com/articles/continuousIntegration.html
[Schatten 2010] Alexander Schatten, Stefan Biffl, Markus Demolsky, Erik
Gostischa-Franta, Thomas Östreicher, Dietmar Winkler, Best Practice
Software-Engineering, Eine praxiserprobte Zusammenstellung von
komponentenorientierten Konzepten, Methoden und Werkzeugen,
Springer, 2010
Peter Rautek
20
Download