Automate everything – why end2end automation is key

These days we are used to consuming products that are supposed to continuously improve their value towards us – the customer. We are faced with constantly changing products. Depending on the industry the release times are spanning from longer time spans – like years – to real continuous changes – multiple times a day.

Nowadays there is no doubt that the principle of continuous delivery is to our advantage and provides a huge competitive edge – if done right. In order to implement the principle in the right way a huge amount of automation is required. The biggest chunk of automation and therefore also the success factor is automating the delivery chain or the end-to-end-automation.

The following talk is about the different automation building blocks it requires to implement the *end-to-end-automation*. It is about how these building blocks interact with each other and are dependent from each other. It is about how we implemented these principles at Fidor to create a banking-as-a-service product.

The main building blocks are:

  • Automated regression tests, immutable-infrastructure-as-code and automated zero downtime deployments.
  • The foundation blocks that makes end-to-end-automation possible are immutable-infrastructure-as-code and automated zero downtime deployments.
  • Immutable-infrastructure-as-code enables us to build the same infrastructure (perhaps different in size) for all different levels the infrastructure is required – test, acceptance and production for example. This leads to less brittle tests and therefore reliable quality assurance.
  • Automated-zero-downtime deployments requires intense care during the time of building the application software but otherwise every deployment will lead to downtime which is not acceptable for continuous deployments.

Only if those building blocks are available end-to-end automation can be implemented. On top of the foundation an automated regression test suite must be implemented. Driven by the continuous deployment principle all end-to-end regression tests have to be automated. Many more tools for API test -, UI test and mobile test tools are necessary to achieve the building block of automated regression tests.

I will talk about how we implemented end-to-end automation for our banking-as-a-service platform, which tools we are using and how the delivery processes need to adopted.

I care about finding the right balance between technical challenges, new developments and a group of people (some call this organization) in order to use this mixture to its advantage and the advantage of the customer.

I started coding in the 1980s and since then try to stay up-to-date. I love using programming languages to deliver a product that can make a difference to the customer.

I learned a lot about creating software products in the data center world when I was working as a founder and CTO at ATIX from 1995 to 2013. I had the opportunity to support selling, implementing and maintaining our product.
My takeaway mainly was that I have to be flexible and take customers serious. During my time at ATIX I started learning about lean thinking and approaching business ideas in a different way that I thought was possible.

2013 I left ATIX :'( and started working for Fidor the technology provider of the Fidorbank as CTO.

Since I’m there – for 6 years now – we broke the monolith – or better we are still breaking it – cause it’s a big beast – we implemented continuous delivery pipelines and automated regression testing to learn and constantly improve the process how fast we can get customer feedback and iterate on our product. We moved from classical application servers to docker containers to cloud native with Rails apps and much more.

This post is also available in: German