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:
- 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.
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
- Backend web application
- Production Java Code
- JUnit Test Code
- Technical libraries if required
- 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.
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:
These quality gates can include metris like code coverage or even more sophisticated metrics like cyclomatic complexity.
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.
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.