werf is our Open Source tool to build your applications and deploy them to Kubernetes — continuously & consistently. Today we are excited to announce that werf has learned to operate in a distributed mode!

Container registries tend to support the Docker Registry HTTP API, allowing their users to rely on the same tools to operate them. However, some implementations have their peculiarities and limitations. Thus, you have to take into account their specifics when using them as part of your CI/CD toolchain. That is exactly what happened when we decided to improve the way our werf GitOps utility manages the lifecycle of images.

werf is our Open Source GitOps tool to build your applications and deploy them to Kubernetes. The v1.1 release introduced a new feature in the image builder: the content-based tagging. Until now, the typical tagging strategy in werf involved tagging Docker images by a Git tag, Git branch, or Git commit. However, all these strategies have drawbacks that are fully resolved by implementing the new tagging strategy. In this article, we discuss its advantages.

werf is our Open Source GitOps tool to build your applications and deploy them to Kubernetes. As promised, the release of werf 1.0 marked the beginning of the era of new features and revising established approaches. Now, we are excited to announce the latest version (v1.1) of our tool which is a massive step in the development of its builder and laying the groundwork for the future. Currently, version 1.1 is available in the 1.1 ea channel.

You may already know our GitOps tool called werf — we have discussed it in several of our articles. Today, we would like to share our experience in building & deploying the site with our tool’s documentation, werf.io. Despite it is a regular static site, the building process is noteworthy as we use a dynamic number of artifacts.

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.