Continuous integration using jenkins, maven & subversion (svn). Introduction to CI process & CI tools

1. CI Using Jenkins, Maven & SVN
Ankur Goyal
Email: ankur.fbd@gmail.com

2. Agenda
• Java Build Process
• Continuous Integration
 Introduction
 Tools
• SVN - Apache Subversion
• Maven
 Introduction
 The Philosophy
 Build Patterns
 Common Project Metadata Format
 Common Directory Structure
 Common Build Lifecycle
 Dependency Management
 Repository
 Phases & Goals
 Hands-on
• Jenkins
• Continuous Integration – Team’s Responsibilities

3. Java Build Process
• "Build" is a process that covers all the steps required to create a
"deliverable" of your software.
• In the Java world, this typically includes:
 Generating sources (sometimes).
 Compiling sources.
 Compiling test sources.
 Executing tests (unit tests, integration tests, etc).
 Packaging (into jar, war).
 Running health checks (static analyzers like Checkstyle, Findbugs, PMD, test
coverage, etc).
 Generating reports.

4. Continuous Integration - Introduction
• Continuous Integration (CI) is a development practice that requires
developers to
integrate code into a shared repository several times a day. Each
check-in is then
verified by an automated build, allowing teams to detect problems
early.
• CI Best Practices:
 Maintain a single source repository
 Automate the build
 Make your build self-testing
 Every commit should build on an integration machine
 Automate deployment

5. Continuous Integration – Process Overview
http://builtbyadam.files.wordpress.com/2010/06/ci-diagram.png

6. Continuous Integration – Why ?
• Integration of various modules at the end is hard due to following
reasons:
 Number of components keep increasing
 Complexity of the system keeps increasing
 There is no visibility of code quality & relationship between different
modules
• CI provides following benefits:
 Rapid Feedback - Detects system development problems in initial stage
 Reduces risk of cost & schedule
 Reduces rework
 Provides report so that one can judge the actual code quality
 Collective Ownership

7. Continuous Integration - Tools
• Source Repository
SVN, CVS, GIT etc
• Build Tool
Maven, ANT etc
• CI Server
Jenkins, Hudson etc

8. SVN – Apache Subversion
• Apache Subversion is a software versioning and revision control system
• Distributed as free software under the Apache License.
• Is Open Source.
• Runs on Unix, Linux, Windows, Mac
• Client’s such as TortoiseSVN are available which provide intuitive and easy
to use
interface
• Developers use Subversion to maintain current and historical versions of
files
such as source code, web pages, and documentation.

9. Maven - Introduction
• Is a Java build tool.
• Is a dependency management tool
• Provides a standard development infrastructure across
projects
• Consistent project structure & build model
• Follows standard project life cycle phases & ensures that
developers moving
between projects do not need to learn new processes.

10. Maven - Nomenclature
• Archetype: template based on which maven
project would be created e.g.:
org.apache.maven.archetypes:maven-archetype-quickstart
(An archetype which contains a sample Maven project.)
• Groupid: similar to package in java e.g:
com.endeavour.first
• Artifactid: similar to project name in java e.g:
Maven-sample

11. Maven – Why ?
• Project references/dependencies
Make sure jars are available during compile time
Make sure to copy jars when moving project source
• Dependencies
Include dependencies of included jars
• Project Structure
Defines a standard project structure
• Publishing & Deploying
Allows phase-wise publishing & deployment

12. Maven – The Philosophy
• Maven was born of the very practical desire to make several projects at
Apache work in the same way. So that developers could freely move between
these
projects, knowing clearly how they all worked by understanding how one of
them worked.
• Puts convention over configuration
• Do not script the build rather describe the project & configure the build
• Defines Build Patterns
 Common Project Metadata Format
 Common Directory Structure
 Common Build lifecycles

13. Build Patterns – Common Project Metadata Format
• POM  Project Object Model
 Pom.xml  Project configuration file
• Contains all metadata about the
project:
 Name
 Packaging Type
 Dependencies
 Repositories to use
 Tool links (CI, SCM, Bug Tracker etc)

14. Build Patterns – Common Directory Structure
• Maven is opinionated about project structure & follows
convention over configuration approach.
• Following is standard directory layout:
 target: Default work directory
 src: All project source files go in this directory
 src/main: All sources that go into primary artifact
 src/test: All sources contributing to testing project
 src/main/java: All java source files
 src/main/webapp: All web source files
 src/main/resources: All non compiled source files
 src/test/java: All java test source files
 src/test/resources: All non compiled test source files

15. Build Patterns – Common Build Lifecycle
• Default Lifecycle phases - Invoked with ‘mvn’ command
 validate - validate the project is correct and all necessary information is available
 compile - compile the source code of the project
 test - test the compiled source code using a suitable unit testing framework e.g. junit
 package - take the compiled code and package it in its distributable format, such as a JAR
 integration-test - process and deploy the package if necessary into an environment where integration tests can
be run
 verify - run any checks to verify the package is valid and meets quality criteria
 install - install the package into the local repository, for use as a dependency in other projects locally (Not server
install)
 deploy - copies the final package to the remote repository for sharing with other developers and projects (Not
server deploy)
• There are two other Maven lifecycles of note beyond the default list above:
 clean: cleans up artifacts created by prior builds
 site: generates site documentation for this project
Specify the phase needed to run, previous phases run automatically

16. Maven – Dependency Management
• Dependencies Identified by
groupid
artifactid
version
scope
• Declaration in pom.xml will do the following:
download the jar
add it to the classpath
• Supports Transitive dependencies
Automatically takes care of dependencies of dependencies

17. Maven - Repository
• Contains versioned artifacts & plugins associated with
pom
• No need to copy libraries for each individual project
• Remote repository can be added as required
• Local repository caches artifacts to allow offline builds
• All project references go through the repository
therefore no relative paths

18. Maven – Phases & Goals
• Goals are executed in phases. Phases determine the order of goal’s
execution.
• The compile phase goals will always be executed before the test
phase goals which
will always be executed before the package phase goals and so on…
• When executing maven we can specify a goal or a phase, however If
you specify a
goal then it will still run all phases up to the phase for that goal. In
other words,
if you specify the jar goal it will run all phases up to the package phase
(and all goals in those phases), and then it will run the jar goal.
Phase Goal
compile compiler:compile
test-compile compiler:testCompile
package jar:jar or rar:rar or war:war

19. Maven – Hands-on
• Install & Configure Maven
mvn --version
• Create a Maven Project that outputs a jar
mvn archetype:generate
• Add a dependency in project created above
▌Resources:
 http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
 http://www.mkyong.com/tutorials/maven-tutorials/
 https://www.youtube.com/watch?v=al7bRZzz4oU

20. Jenkins - Introduction
• An open source CI server
• Easy To Install and use
• Formerly known as Hudson
• Triggers a build based on some event such as notice SVN
commit or manually click build by user or build periodically.
• Generates reports & notify to team as configured
• Deploys the deliverable at given server

21. Jenkins - Why
• Easy GUI to Manage
• Strong Community
• Distributed Builds
• Open Source and Free
Used by leading organizations

22. Jenkins – Basic Steps
• Notice a change
• Checkout source code
• Execute builds/test
• Record and Publish results
• Notify Team

23. Integrating Plugins
• Jenkins is extensible & we can add new capabilities using
plugins
• Over 600 plugins are available for Jenkins such as:
 Static code analyzers
 Test coverage
 Reporting plugins
 Credentials Management
 Mailer etc
• Use Manage Plugin section for integrating plugins

24. Integrating Plugins – Code Quality
• Install PMD, FindBugs and checkstyle plugins from the
manage plugins option.
• Add cobertura plugin to capture the code coverage report by
Junit.
• Add the plugins in the pom.xml file of the project.
• Configure the jenkins job to process the above tools.
• Install the plugins to display the violations on the jenkins
dashboard like-
 Analysis Collector Plugin, Violations, Dashboard View, Plot Plugin.
• Set goal: Cobertura:cobertura check pmd:pmd
findbug:findbug in Jenkins Job.
• Execute the build.

25. Continuous Integration – Team’s Responsibilities
• Check in frequently
• Don’t check in broken code
• Don’t check in untested code
• Don’t check in when the build is broken
• After checking in make sure that system builds successfully

26. Thank You & Happy CI !!!