This article is part of a series about Java Forum Nord 2015, a conference that took place in Hannover, Germany. Links to articles about other talks I visited there can be found below.

Because I strongly agreed with most of what Bert said, I took very few notes during the talk. The following text is therefore an abstract of his slides . So, if you want to read the original source, just read the slides. :)

At the beginning of his talk, Bert asked the attendees who of them is doing Continuous Integration. A lot of hands raised. Then he asked who is doing Continuous Delivery, fewer hands raised. There have been even fewer when he asked for Continuous Deployment. I think at least a part of this is because these words have been used quite a lot and synonymous. Thankfully, the speaker gave the following definitions:

• Continuous Integration: “Team members integrate their work frequently. Commits are verified by automated builds and tests.”
• Continuous Delivery: “Building and testing software such a way that the software can be released to production at any time.”
• Continuous Deployment: “Every change goes through the build/test pipeline and automatically gets put into production.”

Stéphane described how his employer, Malmberg, changed over the last few months. There was a transformation going on from a technologically modern company with traditional processes to a place where a lot of the current aspects of modern software development are lived. This has been done by investing in building great teams and following these principles:

1. Master branch is always releasable. Don’t merge until it’s done.
2. Each commit is tested intensively. There are a number of different tests to perform before committing anything.
3. Every delivery job is a Jenkins job. Jenkins is the central infrastructure for building, packaging, testing and QA.
4. Deployments are roll-forward only. That means that occurring defects are fixed by a new (bugfix-)release instead of switching to a former version of the application.
5. Infrastructure as code - for everything. The complete infrastructure is configured via version-controlled config files. This way, changes in configuration can easily be retraced and taken back if necessary.
6. Put everything in auto scaling groups. The need to scale is not always visible right from the start. Adding scalability afterwards is harder than building it in from scratch. Hence: Use containers from the start.
7. No downtime in production. “Down for maintenance” is not acceptable.
8. Eyes and ears in production. Work proactive, not reactive.
9. Repeating tasks are executable for all team members. Repeating tasks such as viewing logs and doing deployments must be common jobs. I strongly agree with this one. Actually, this is exactly one of the first tasks I took when entering my current team.
10. DevOps teams work on a self-service basis. Teams should not depend on external help but should be enabled to getting things done.

After explaining these principles, Bert talked about the challenges when introducing them. Of course there have been communication issues and resistance. Also, the new versatility asked from the developers caused a shift in thinking. However, the benefits (for example availability, cost reduction, agility) outweighed the costs.

Other content of Java Forum Nord 2015

These are the talks I visited:

• Keynote by Adam Bien
• “Reflecting Software Architectures” by Stefan Zörner
• “Yes we scan - Software analysis with JQAssistant” by Dirk Mahler (blog post by Dirk Mahler himself)
• “Mastering legacy code in x simple steps” by Falk Sippach
• “Swimming upstream in the container revolution: Containerless Continuous Delivery” by Bert Jan Schrijver
• “Functional Programming in Java 8” by Nicole Rauch
• “Where has my software architecture gone?” by Oliver Gierke

TL;DR

At Java Forum Nord 2015, Bert Jan Schrijver talked about the transformation of his development team to an agile group of allrounder DevOps.