Creating a CICD setup for home use

Posted By Barry van Acker on 23 Sep 2018 in CICD in docker |

Often when I am working at home, I wish I had a CICD setup similar to the one at my customers. Developing code without a continues integration platform feels like a big step back. Any self-respecting developer should use CICD, even at home.  The only pain is the time needed to setup the applications, which can be significant the first time you do it. In the upcoming posts I will be creating a CICD setup for home use, so that you might go through the steps faster.

I will explicitly not choose any development language or platform, as I will be using it for many different things. I dabble around with many languages and such, so I want my environment to be able to support them all. A small sample of languages and platforms I am supporting using this platform: Python, Django, Java, Angular, Tibco BW, docker.

Our Continues Integration platform is build upon


The integration lifecycle

Setting up a continues integration is quite a project. A good setup is straight forward from administrating point of view, easy to use as a developer and most important: stable. A continues integration setup is not a static thing, but it changes over time, just as fast as the IT world itself is changing. Therefor we need a stable basis that is a good foundation on which we can build in the future.

A sample Continues integration and deployment cycle.

The docker infrastructure

To create this CI platform, we will be using Docker-compose. This allows us to re-create the composition independent of server availability, networks and admin permissions. All we need is a computer with sufficient disk and memory space, and sufficient permissions on that computer to install docker.

We have to configure our artifact repository. We can create areas for different packaging systems: maven, pip, docker. Also, we need to consider the types of updates: do we use allow overwrite actions on an existing version, or do we force new version numbers?

Next, the Jenkins master will be added to the stack, so that we have a director to control the build jobs.

We will configure the slave to work with our repository by creating a sample project.

First we will create an artifact repository to hold our build artifacts. It will contain both the temporary artifacts created at the build phase, as well as the docker images created at the packaging phase, as well as all supporting binaries.

Docker is quite strict in its security requirements. We will secure the repository, so that it will be accessible without hacking or compromising security settings of docker. We do this by adding a reverse proxy as central entry point into our stack.

Once we have Jenkins up, we can add a Jenkins slave to execute build jobs.

Finally, we add a SonarQube installation to validate the quality of the code.

Share This

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.