Conveyor (part 3): Encapsulated Builds

For previous entries in this series see:
1 – Breaking Down Barriers
2 – Pipelines as code…not text
3 – Pipelines as code (part 2)…the API

The initial approach to running Maven through Conveyor used MavenCli. I found it a bit awkward to use with regards to sorting it’s dependencies and passing commands. It also relies a bit too much on the build machine having some pre-existing things in place such as setting.xml

Maven Wrapper is a much nicer solution. It’s an idea borrowed from Gradle and eliminates the need to have Maven already installed. I see automatically generates the wrappers for you and the plugin functionality is being migrated into Maven 4.

I want to aggressively cut as many prerequisites as possible when it comes to setting up. That will simplify build servers. The fewer bits to set up, the better and move the rest into version control. In other words: encapsulate your builds. It works for classes, why not builds and applications?

I wonder how far that idea can be pushed? We’re down to only needing Git to check out the project and Java to execute. I’d say Docker may be the answer here. Have an image that includes everything you need to build the application. Maybe parameterise the image so it can pass in repo details and git credentials.

This would also benefit setting up local development environments. Imagine you’re a developer starting on a new team and you’re handed a laptop. Would you rather:

A – Find some developer environment set-up documentation on confluence that’s hopefully up-to-date because no- one’s had to go near it in a while.
Start installing the required Maven version, Git version, Java version, Tomcat version, hunt down the right configuration for the application.
A day or so later you’re ready to trying running the application.
Doesn’t work.
Some head-scratching ensues as you double-check the docs before you bother anyone else on the team as you want to appear self-sufficient.
Eventually give up and ask someone who says you need to use a different tomcat version, the docs are out of date.

B – Pull and run the latest team docker image which includes the necessary version of everything.
Point IntelliJ at the mounted directory and start coding.

You could go so far as to run IntelliJ in the Docker image but that restricts you to operating the IDE via a browser. While very cool, it’s a big productivity no-no that plagues any browser-based IDE I’ve come across because you can’t use your IDE short-cuts, or multiple screens if that’s your bag.

Anyway, B is clearly the better choice. Optimise for developer productivity wherever you can, it’s your most expensive resource. What’s good for the build is good for the developers, everyone wins.

Comments? Questions? Suggestions?