O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

Ci jenkins maven svn

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Próximos SlideShares
Jenkins
Jenkins
Carregando em…3
×

Confira estes a seguir

1 de 26 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (20)

Anúncio

Semelhante a Ci jenkins maven svn (20)

Mais recentes (20)

Anúncio

Ci jenkins maven svn

  1. 1. CI Using Jenkins, Maven & SVN Ankur Goyal Email: ankur.fbd@gmail.com
  2. 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. 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. 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. 5. Continuous Integration – Process Overview http://builtbyadam.files.wordpress.com/2010/06/ci-diagram.png
  6. 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. 7. Continuous Integration - Tools • Source Repository SVN, CVS, GIT etc • Build Tool Maven, ANT etc • CI Server Jenkins, Hudson etc
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21. Jenkins - Why • Easy GUI to Manage • Strong Community • Distributed Builds • Open Source and Free Used by leading organizations
  22. 22. Jenkins – Basic Steps • Notice a change • Checkout source code • Execute builds/test • Record and Publish results • Notify Team
  23. 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. 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. 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. 26. Thank You & Happy CI !!!

×