Presentation 1   open source tools in continuous integration environment v1.0
Upcoming SlideShare
Loading in...5
×
 

Presentation 1 open source tools in continuous integration environment v1.0

on

  • 3,615 views

Open Source Tools in Continuous Integration Environment - Jasmine Conseil 2011

Open Source Tools in Continuous Integration Environment - Jasmine Conseil 2011

Statistics

Views

Total Views
3,615
Views on SlideShare
3,592
Embed Views
23

Actions

Likes
0
Downloads
66
Comments
0

2 Embeds 23

http://www.eclipsecon.org 21
http://eclipsecon.org 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 1. First, a developer commits code to the version control repository. Meanwhile, the CI server on the integration build machine is polling this repository for changes (e.g., every few minutes). 2. Soon after a commit occurs, the CI server detects that changes have occurred in the version control repository, so the CI server retrieves the latest copy of the code from the repository and then executes a build script, which integrates the software. 3. The CI server generates feedback by e-mailing build results to specified project members. 4. The CI server continues to poll for changes in the version control repository.

Presentation 1   open source tools in continuous integration environment v1.0 Presentation 1 open source tools in continuous integration environment v1.0 Presentation Transcript

  • Open Source Tools in Continuous Integration Environment March 2011 Santa Clara Karim DJAAFAR CO of Jasmine Conseil [email_address]
  • Who am I ?
    • A JEE Evangelist over 15 years of experience in enterprise and Web technologies
    • Founder and CO of Jasmine Consulting a French and International company focused in JAVA/JEE agile development
    • Author of several books around Eclipse Development
    • Gold Member of Eclipse Foundation, we promote JEE Open Source incubation projects around agile development and JEE Expertise (see JasForge project)
  • About you
    • Ant users? Ivy ?
    • Maven users ?
    • Continuous integration ?
  • Outline
    • Towards a better build process using agile tools
    • Build Managements and repository
    • Continuous Integration, Principles and Tools
    • Workflow
    • Benefits
    • Jasforge: the unified agile tools
    • Demos
  • TOWARDS A BETTER BUILD PROCESS USING AGILE TOOLS
  • What Is a Build?
    • A build is much more than a compile (or its dynamic language variations)
    • A build may consist of the compilation, testing, inspection, and deployment—among other things
    • A build acts as the process for putting source code together and verifying that the software works as a cohesive unit.
  • Build Tools Automation in a agile scenario CI Build Server Automated testing Automated code quality Build Tool Agile and collaborative tools
  • Build Tool
    • Collect input
    • Process inputs
    • Generate final outputs
  • Build Tool - Inputs
    • Source code
      • Java, SQL
    • Resources
      • Properties, XML
    • Dependencies
      • Libraries, components, frameworks
  • Build Tool - Processing
    • Compile
    • Run tests
    • Copy files
    • Replace keywords
    • Package
    • Install / deploy
  • Build Tool - Outputs
    • JAR / WAR / EAR files
    • Zip files
    • Reports
  • Ant vs Maven
    • Ant: Procedural
      • Set path
      • Compile jars
      • Run unit tests
      • Create reports
      • Copy files
      • Assemble WAR
    • Maven: Declarative
      • Define name & version
      • Define as WAR project
      • Specify dependencies
      • Specify unit test plugin
  • Ant Multi-Project Builds
    • Option 1 – Master build.xml
    • Option 2 – Cascading build.xml's
  • Maven
    • Project and artifact-based build platform
    • Uses repositories to manage artifacts and third party libraries
    • Customized by modifying the behavior of the life-cycle via plugins.
  • Maven and the Development Build Process
    • Maven the source build management tool for enterprise Java projects
    • Use declarative approche rather then the task-based approach used in Ant or in traditional Make files or shell scripts
    • Promotes the use of standard directory
    • structures and a well-defined build lifecycle
    • Support quality metric reporting and
    • documentation generation tool throw the use
    • of plugins
  • Phases: build life cycle
    • The standard goals for building:
      • compile & test - compile and test the code
      • package – build and test the artifact
      • install – package the artifact and install to local repository
      • deploy – package the artifact and copy to the remote repository (release time)
    • Release management
  • Common way to build applications MOJO – Maven 2 Plugins Project http://mojo.codehaus.org/ plugins user e.g. mvn install M2 generate- sources compile test install deploy package integration- test Well-known phases mojo mojo mojo mojo mojo bindings
  • Reports
    • Centralize your project information and documentation for developers and their managers
    • Integrate project information such as source code, inspection reports, etc…
      • Reports are used to show the state of the project
      • Can be integrated with little to no configuration on an existing project
      • Test coverage (eg. Clover), test results, code style (eg Checkstyle, PMD), and many more
  • Maven main strengh
    • A Standard way of identifying artifacts
      • Each Maven artifact has a unique identifier, or “coordinates
      • All project interactions go through the repository
      • No more relative paths!
      • Declarative Dependency Management
      • Easy to share between team
    <repositories> <repository> <id>central</id> <name>Maven Repository Switchboard</name> <layout>default</layout> <url> http://repo1.maven.org/maven2 </url> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repositories>
  • Maven in the Eclipse Ecosystem
    • Eclipse IAM ( http://www.eclipse.org/iam/ )
      • Integration for Apache Maven and direct import of Maven 2 projects
      • continuation of Q for Eclipse
      • Provide a rich interface over Maven
      • Wizard for creation of new projects using the archetype mechanism of Maven
    • Using m2Eclipse plugin
      • Setting up Maven projects can be done in two ways: using Maven-eclipse-plugin (mvn eclipse:eclipse) or using M2eclipse plugin (see http://m2eclipse.sonatype.org/ )
  • Automated web deployment
    • Automating the deployment process using the Cargo Maven plugin
      • Start, stop and install application servers
      • Deploy to different application servers
      • Run a stand-alone instance
      • Or deploy to an existing server
    Deploy to different Application server Deploying to an embedded Jetty instance
  • BUILD MANAGEMENT AND REPOSITORY
  • Artifact Repository Manager
    • Artifact Search
    • Remote Proxying Cache
    • Artifact Upload
    • Graphical Administration
    • Virtual Repositories
    • RSS Feeds
    • Role-based Security
    • Integrity Reports
    • Maintenance
  • Archiva
    • Archiva http://archiva.apache.org the build artifact repository for use with build tools such as Maven and Ant
    • Proxy and cache
    • Search and repository browser
    • Reporting features
    • User interface
    • Uploading/Deleting artefacts
  • CONTINUOUS INTEGRATION PRINCIPLES AND TOOLS
  • What is CI (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 (includingtest) to detect integration errors as quickly as possible.”
    • Martin Fowler.
  • Continuous Integration (CI) scenario
    • A CI scenario starts with the developer committing source code to the repository.
    • On a typical project, people in many project roles may commit changes that trigger a CI cycle:
      • Developers change source code,
      • database administrators (DBAs) change table definitions,
      • build and deployment teams change configuration files,
      • interface teams change DTD/XSD specifications,
      • and so on…
  • Why do we need CI ?
    • Replace big (and long) integration phases with small and frequent ones
      • Ideally instantaneous
      • Think of « incremental compilation » in Eclipse
    • Minimize integration effort
      • Keep the development process running …
    • CI was introduced with XP principles and by Martin Fowler
  • Workflow
    • Checkout from SCM
    • Code a new feature
    • Run automated build on my machine
      • Repeat 2 and 3 until test pass !
    • Merge with latest changes from SCM
      • Fix and rebuild until test pass
    • Commit
    • Run a build on a clean machine
      • Immediately fix bugs and integration issues
  • Components of a Continuous Integration system CI Repository CI Server Deployment Platform Build Manager Feedback mecanism 1.Checkout: get all existing source from the repository 1 2 2.Commit: commit all local modifications in the repository 3 3.Pool: See if there is a commit in the repository 4 4.Build: Build construction in the JEE lifecycle. 5 5.Deploy: Artefact deployment in a target platform 6 6.Feedback: feedback mecanism like email notification and groupware.
  • The components of a CI system Commit changes Compile Source Code, Integrate Database, Run Tests, Run Inspections, Deploy Software Feedback Mechanism Generate feedback SCM Server (Svn, Git, …) CI Server
  • Version Control Repository
    • Simply put, you must use a version control repository in order to perform CI
    • Even if you don’t use CI, a version control repository should be standard for your project
    • The purpose of a version control repository is to manage changes to source code and other software assets (such as documentation) using a controlled access repository
    • There are different types of version control systems you can use too
    • We use Subversion for most of the examples in this seminar
  • Continuous Integration not exist without TDD !
    • A software development practice where members of a team integrate their work frequently usually each person integrates at least daily (Martin Fowler)
    • CI leads to significantly reduced integration problems and allow a team to develop cohesive software more rapidly and reduce risk
    • To complete this definition
      • Automated, self-testing and fast builds
      • Make it easy for everyone to get the last executable
      • Automate deployment
      • Everyone can see what’s happening progress, statistics on code coverage tests, etc …
      • Reduced risks
  • Continuous Integration
    • Major tools
      • Hudson
        • Writen in java ( https://hudson.dev.java.net/ )
        • No install required (put a war in a web container)
        • Easy to use
        • Powerful
        • Default support for CVS and SVN
        • Great support and active community
      • Cruise Control
      • Continuum
        • Java and Ant/Maven based
        • Open Source
  • Every commit much triggers a build !
    • Commit at least daily…
      • As soon as you have completed an independent functionnality
    • A full build on another empty machine
      • Not on your own !
    • With hudson
      • SCM polling
      • Cron-like scheduller
      • Trigger with http request (from maven or svn commit hook)
  • Practicing CI or TDD does not make you agile !
    • Although it is recommended, a CI server isn’t required to perform continuous integration
    • You can write your own custom scripts
    • Moreover, you can manually run an integration build whenever a change is applied to the repository
    • Using a CI server can reduce the number of custom scripts that you would otherwise need to write
    • Many CI servers are freely available and open source: Cruise Control, Hudson are the most well known
    • Without active engagement of the customer an organization will NEVER be agile, regardless of the other development techniques used.
  • THE INTEGRATED AGILE INFRASTRUCTURE
  • Managing all the agile tools is a complex process
    • Today, managing and taking control of your software process is a major challenge for maintaining is capacity to be innovative and competitive
    • Ho can we manage efficiently all these toolls in an unified way ?
    • We must manage the quality of our software development en meet the requirements and delays in a predictive mode
    • This is the aim of JasForge© Project ( http://www.jasforge.com ) : Taking the control of your development process using an “agile “ approache
  • MAVEN AND OSGI: THE NEW APPLICATION LIFECYCLE MANAGEMENT
  • The Problem
    • Ant and Maven
  • Maven to OSGI: the best of the two worlds
    • OSGI specification: A brief recall
      • Define java-based service platform, full dynamic component model
      • Why another specification ?
        • JVM doesn’t support natively dynamic module system: startting/stoping/updating application on runtime
        • JAR dependencies management missing: no way how to restrict exported packages, enforce imports …
    • Implementation
      • Open Source: Eclipse Equinox/Apache Felix
  • Maven and OSGI Integration
  • Version Control Repository
    • Simply put, you must use a version control repository in order to perform CI
    • Even if you don’t use CI, a version control repository should be standard for your project
    • The purpose of a version control repository is to manage changes to source code and other software assets (such as documentation) using a controlled access repository
    • There are different types of version control systems you can use too
    • We use Subversion for most of the examples in this seminar
  • CI Server
    • A CI server runs an integration build whenever a change is committed to the version control repository
    • Typically, you will configure the CI server to check for changes in a version control repository every few minutes or so
    • The CI server will retrieve the source files and run a build script or scripts
    • CI servers can also be hard-scheduled to build on a regular frequency, such as every hour (but note that this is not CI).
    • Some “little” screen casts and demos
    • Managing your projects
    • Managing users and roles
    • Managing you servers