In this blog post I will describe how to support a modern continuous delivery process to deliver business value daily to weekly. The main tools that will be used are git, Jenkins multibranch pipelines and production application servers e.g. wildfly.

The image above shows how to structure a modern continuous delivery process. We have typically 3 stages for our software:

• develop
• qa (quality assurance)
• master (production)

Develop is the stage where active development takes please. Most of the commits are happening in this stage. When a release is prepared everything moves from develop to qa. When qa is done the system is put into production.

git flow and deployment speak

git flow is a very prominent and often used git branching and merging model. I would recommend this model. We are already using this for some years and it works well. Further we extended parts with submodules to include technical libraries into the flow.

If you are interested in the details please read the official article. There is also direct command line support and SourceTree bundles this as well.

Branch naming

The average developer does not know all the git terms like branch, remote branch, local branch, rebase, submodule, cherry-pick etc. so it is a good idea to make things obvious. One thing that turned out to make the development a lot more understandable is to name the branch, the jenkins job and the instance jenkins will deploy to the same. You can see this here:

If your continuous delivery is integrated with your issue management system this will also make it easy for the testers to see if a certain feature was already deployed on one of the instances.

How many repositories do I need?

The answer is you need one repository for one microservice. This repository will host the following things:

• Frontend web application
  • Production JavaScript Code
  • QUnit JavaScript Test Code
• Backend web application
  • Production Java Code
  • JUnit Test Code
• Technical libraries if required
  • Java or JavaScript Code
  • Test Code
• System tests
  • It is a very good idea that the system tests will not have any compile time dependency to the frontend or the backend

In general everything that is released together should be in one repository. Everything that is in multiple repositories should use a formal interface definition to speak to each other.

Good example here: The linux kernel is in one repository so no stable ABI is needed.

Build job

The build job will build all libraries of the microservice including unit tests. It will build the backend and the frontend. If everything worked it will deploy them on the given instance.

You can include quality gates with code quality tools like:

• SonarQube
• PMD
• ESLint

These quality gates can include metris like code coverage or even more sophisticated metrics like cyclomatic complexity.

Java already has very good unit test support. For javascript there are multiple alternatives. We made some good experiences with QUnit and PhantomJS. A plugin was written by Kyle Lieber so that PhantomJS can be delivered by maven central.

Newer selenium tests can also run on chrome headless.

System tests

OpenUI5 has a nice overview about the testing hierarchy

I would recommend to have tests for all the parts. The systemtests are typical a bunch of Selenium test that can be driven by a behavioral feature language like gherkin with cucumber or jbehave.

This will make sure that you are delivery business value and not only using libraries that are currently hyped on reddit.

Where is docker?

From the Java EE perspective there is no reason to package a web application in another container format. Nevertheless you can configure your Jenkins to produce a docker file and deploy that on your servers.

Conclusion

Modern software development can be automated a lot and this blog post gave recommendations for multiple decision that have to be taken. It recommends a best of breed approach for tooling.

If you need help building your own continuous integration pipeline contact us.