Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account? Log In

Real World Strategies for Continuous Delivery with Maven and Jenkins by Mind Map: Real World Strategies for
Continuous Delivery with Maven and
5.0 stars - 1 reviews range from 0 to 5

Real World Strategies for Continuous Delivery with Maven and Jenkins

Continuous Delivery


Get interesting stuff in front of your customer as fast as you possibly can, So that you can get a really fast feedback loop and value

Value can come from getting iterations in front of the customer

This gets feedback from your customer quickly even if its not a full feature to implement in production

Value can come from getting iterations in front of users

User feedback is important and it can be good to get that feedback on top of customer feedback., Need to help your customer understand the great value user feedback can be

Want to give the power back to the customer on when a product goes to production.

A release that passes all checks and quality controls has the means to go to production, We want the latest release to be able to go to production but it doesn't have to, it's up to the customer, If we always hold the keys and there is work to be done to get it to production the customer has no control and each build is less valuable



John Fergusen Smart

twitter: wakaleo

git: wakaleo


Java Power Tools

Jenkins - The Definitive Guide

Continuous Deployment


Every legitimate release does go to production


Every build is a potential release

not a predetermined release, every build is a potential release

Eliminate manual bottlenecks

Can't have continuous delivery if QA takes weeks to test it

Development pieces included, Database scripts, Implementation steps

Automate wherever possible

Have automated tests you can trust

Need HIGH degree of confidence - not just test coverage

Build Pipelines

Every build is a potential release

Use the same binaries throughout the pipeline


Compile & Unit Tests, Package and Deploy, Acceptance Tests (Automated Confidence Tests), Dev & QA/Test environments run all tests, Prod often has a subset or smoke tests to ensure deployment but to reduce load on production systems

Live Example, Initial Build, Use Parameterized Builds, MAJOR_VERSION_NUMBER, In a new branch update the pom version # version plugin, Maybe tag instead of branch?, Clean Install -U, Conditional Build Step Plugin to commit and push back on success, Deploy to Nexus, This could be moved to the end of the pipeline to save space if needed, Archive artifacts to reuse in pipeline, Block build when downstream project is building, Don't want acceptance tests to run against unexpected version and not know what was tested, Code Quality, Deploy to Test, Triggers Run Acceptance Tests with parameters so it's one jenkins job but the parameter says which environment (simplifies jenkins), Deploy UAT, *Manual* Deploy to Production, Build promotion plugin, Manual promotion, Has approvers listed, Run Acceptance Tests, Run Acceptance Tests

Using Maven

The Maven Problem

Core maven concepts predate continuous delivery but we can still utilize it. Still better than ant. Gradle may make things easier over maven though.

All maven steps runs the lifecycle front to back, Good on the surface but overall not effective for continuous delivery

Work on snapshot until you make a manual decision that it's good to go then you use mvn release plugin to increment the version

Beware Duplication, Don't add items to the pipeline that don't add true value every time. (eg Java Docs etc)


Split Unit and Integration Tests, Surefire Plugin

Maybe don't use mvn deploy, Multi Module projects it will deploy each at a time and may only deploy some of the artifacts, Jenkins artifactory plugin deploys after install all artifacts, Jenkins mvn deploy:deploy to nexus

Code Coverage - Jococo, Cobertura and Clover rebuild manipulated jars and adds duplicated, Jococo uses prebuilt jars and does code coverage on the fly, Add to post-integration phase, Adds minimal overhead to mvn install, Actually do checks on it, if you don't use checks on it, take it out of the pipeline, Same for code quality - PMD, Find Bugs, Checkstyles, etc, Fail the build if there are violations

Reuse binaries, Every build is a version - NOT a snapshot, Don't use maven release plguin, Maven Versions plugin, digit1.digit2.buildCounter, 1.0.203, 1.0.204, 1.0.205, On build - create a new branch, If build is successful you commit and push that back, If failed drop the branch and don't commit, notify everyone and still increase counter

Build Pipeline Plugin