In Flant, we are often confronted with the challenge of adapting applications for running them in Kubernetes. When dealing with this challenge, we usually encounter many repetitive problems. We have already discussed one of them in the “Migrating your app to Kubernetes: what to do with files?”. In this article, we’ll focus on another problem which relates to CI/CD processes for this time.

In this article, timed to coincide with the werf release, we will provide a detailed description of what this version can and cannot do, as well as discuss our plans for future versions. However, let’s start with what the term “GitOps” means and what role werf has in the process of continuous integration and continuous delivery (CI/CD).

Let’s start with a theory. What are three-way-merge patches? How they’ve been invented, and why they are so essential for CI/CD processes with a Kubernetes-based infrastructure? And later, we will discuss the 3-way-merge process in werf, what modes are used by default, and how can you manage all this stuff.

Are you struggling with implementing CI/CD for many microservices in a efficient and elegant way? Here’s our current approach in solving this task using GitLab CI (thanks to its include keyword in .gitlab-ci.yml) and werf.

Let’s imagine that your application is written in some scripting language — e.g. Ruby — and you want to rewrite it in Golang. You may ask a reasonable question: what is the point in rewriting a program that is up and running?..

This article should be useful if you create & apply Helm charts for Kubernetes using the existing solutions drawn from the chart repositories.

Better late than never. The story of how we almost made a major mistake by not implementing support for building images using regular Dockerfiles.

We are excited to announce werf — Open Source, Go-native and simply powerful DevOps tool bringing the CI/CD implementation based on Kubernetes to the next level.