Real World Strategies for Continuous Delivery with Maven and Jenkins

Get Started. It's Free
or sign up with your email address
Real World Strategies for Continuous Delivery with Maven and Jenkins by Mind Map: Real World Strategies for Continuous Delivery with Maven and Jenkins

1. Build Pipelines

1.1. Every build is a potential release

1.2. Use the same binaries throughout the pipeline

1.3. Examples

1.3.1. Compile & Unit Tests

1.3.1.1. Package and Deploy

1.3.1.1.1. Acceptance Tests (Automated Confidence Tests)

1.3.2. Live Example

1.3.2.1. Initial Build

1.3.2.1.1. Use Parameterized Builds

1.3.2.1.2. Clean Install -U

1.3.2.1.3. Conditional Build Step Plugin to commit and push back on success

1.3.2.1.4. Deploy to Nexus

1.3.2.1.5. Archive artifacts to reuse in pipeline

1.3.2.1.6. Block build when downstream project is building

1.3.2.1.7. Code Quality

2. Using Maven

2.1. The Maven Problem

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

2.1.2. All maven steps runs the lifecycle front to back

2.1.2.1. Good on the surface but overall not effective for continuous delivery

2.1.3. 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

2.1.4. Beware Duplication

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

2.2. Implementation

2.2.1. Split Unit and Integration Tests

2.2.1.1. Surefire Plugin

2.2.2. Maybe don't use mvn deploy

2.2.2.1. Multi Module projects it will deploy each at a time and may only deploy some of the artifacts

2.2.2.2. Jenkins artifactory plugin deploys after install all artifacts

2.2.2.3. Jenkins mvn deploy:deploy to nexus

2.2.3. Code Coverage - Jococo

2.2.3.1. Cobertura and Clover rebuild manipulated jars and adds duplicated

2.2.3.2. Jococo uses prebuilt jars and does code coverage on the fly

2.2.3.3. Add to post-integration phase

2.2.3.3.1. Adds minimal overhead to mvn install

2.2.3.4. Actually do checks on it, if you don't use checks on it, take it out of the pipeline

2.2.3.4.1. Same for code quality - PMD, Find Bugs, Checkstyles, etc

2.2.4. Reuse binaries

2.2.4.1. Every build is a version - NOT a snapshot

2.2.4.2. Don't use maven release plguin

2.2.4.3. Maven Versions plugin

2.2.4.3.1. digit1.digit2.buildCounter

2.2.4.4. On build - create a new branch

2.2.4.4.1. If build is successful you commit and push that back

2.2.4.4.2. If failed drop the branch and don't commit, notify everyone and still increase counter

2.2.5. Build Pipeline Plugin

3. Continuous Delivery

3.1. Define

3.1.1. Get interesting stuff in front of your customer as fast as you possibly can

3.1.1.1. So that you can get a really fast feedback loop and value

3.2. Value can come from getting iterations in front of the customer

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

3.3. Value can come from getting iterations in front of users

3.3.1. User feedback is important and it can be good to get that feedback on top of customer feedback.

3.3.1.1. Need to help your customer understand the great value user feedback can be

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

3.4.1. A release that passes all checks and quality controls has the means to go to production

3.4.1.1. We want the latest release to be able to go to production but it doesn't have to, it's up to the customer

3.4.1.2. 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

4. Speaker

4.1. Video

4.2. John Fergusen Smart

4.2.1. [email protected]

4.2.2. twitter: wakaleo

4.2.3. git: wakaleo

4.3. Books

4.3.1. Java Power Tools

4.3.2. Jenkins - The Definitive Guide

5. Continuous Deployment

5.1. Define

5.1.1. Every legitimate release does go to production

6. Principles

6.1. Every build is a potential release

6.1.1. not a predetermined release, every build is a potential release

6.2. Eliminate manual bottlenecks

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

6.2.2. Development pieces included

6.2.2.1. Database scripts

6.2.2.2. Implementation steps

6.3. Automate wherever possible

6.4. Have automated tests you can trust

6.4.1. Need HIGH degree of confidence - not just test coverage