Kubernetes allows us to manage our application deployments and other infrastructure components purely using declarative configuration files (e.g. we’re all YAML developers now). This enables us to put all these files into a Git repository, hook it up to a pipeline (Jenkins, GitLab, etc), which will apply those changes to a cluster—and voilà, we have GitOps.

About a year ago, we at Container Solutions started our engagement with FiduciaGAD, the largest IT service provider for banks in Germany. The focus of this project is to build a Continuous Integration/Continuous Delivery platform for development teams across the organisation.

Implementing Continuous Delivery[1] at enterprise scale is a major challenge. As every company has to innovate their software delivery methods, we need to allow individual teams to learn and improve their own delivery pipeline. This is especially true in the Cloud Native world, where many best practices are still emerging. However, giving teams flexibility to experiment needs to be balanced with security and compliance requirements. In this.

It is an interesting feature of today’s software development landscape, that while some consider Continuous Delivery a done deal, there are still many teams out there who either don’t see or are struggling to realise the benefits. The idea of releasing small increments of functionality often seems like such a straightforward solution to alleviate the pain from large, risky releases that we gloss over the very hard obstacles in the way.

I recently encountered an interesting problem while terraforming Kubernetes clusters on Google Cloud. Our Terraform configurations have some important information which is needed by applications running on the cluster. These are either values for which our Terraform resources are the primary source, or values which are outputs from them.