/devoxx-tools-maven

Showcase code for Devoxx.be Maven Tools in Action (http://cfp.devoxx.be/2016/talk/GLJ-8229/Maven__-_your_ultimate_CD_tool)

Primary LanguageJavaScript

Maven - the ultimate CD tool

Who am I?

Jakub Marchwicki
  • developer

  • position wise: ex-architect, ex-manager, ex-consultant

  • I help teams gradually recover from legacy trauma

    • Introducing microservices - out of frying pan into the fire

  • Twitter: @kubem

Why not Maven?

  • Maven will make the preferred path the easy path

    • The easy path might not be the best path

  • If your idea doesn’t confront the Maven’s - it’s you problem

    • After that not easiest to extends - matters of hours not minutes

  • Honestly, besides dependency management there is not much so great about Maven

Why Maven?

  • Well known, old-but-goldie tech classic

Build pipeline

/-------------\
| upstream #1 | --------\
\-------------/         |
                        v
                   /----------\     /---------\    /------\            /---------\
/-------------\    |          |     |         |    |      |            |cGRE     |
| upstream #2 | -> | assembly | --> | release | -> | test |-> ... -->  | promote |
\-------------/    |          |     |         |    |      |            |         |
                   \----------/     \---------/    \------/            \---------/
                        ^
/-------------\         |
| upstream #2 | --------/
\-------------/

Antipatterns

  • Deploy software manually

  • Deploy to production-like environment

  • Manual configuration management of the production environment

Patterns

  • Build binaries only once

  • Deploy the same binary to every environment

  • Smoke test you deployments

If project builds, than run it as far through the testing pipeline as it can go until it gets to the end.

Three steps we’lll focus on

  • Release process

    • Run tests

    • Tag version

    • Prepare new development version

  • Prepare docker image

  • Assemble application from multiple parts - microservish architecture

Why bother - we have release plugin?

  • The plugin builds twice:
    build the code → tag / branch → build the branch

    • [maven-release-plugin] prepare release …​` and [maven-release-plugin] prepare for next development iteration - so not every commit is releasable

  • Perform the release on current branch

  • Commits and pushes the changes

configuration
link:project/pom.xml[role=include]
  1. Name of the tag

  2. We don’t want to commit remotly - we will do it later on

  3. We checkout out (to perform the release) from the local tag

  4. As for preparation we will be running following goals: clean, test, scm:branch and exec:exec
    Standard goal is clean verify - but we also create a branch and check it out

  5. For the release itself - we will be doing just installation (no deployment) - again that will come later

command
$ mvn -B release:prepare release:perform

Let Maven rule the NPM

link:project/app/todo-ui/pom.xml[role=include]
link:project/app/todo-ui/pom.xml[role=include]

Docker

link:project/deploy/pom.xml[role=include]
link:project/deploy/docker/pom.xml[role=include]
  1. References which artifact actually goes into docker image

Thank you