werf CI/CD tool becomes a CNCF project!

werf is officially a Sandbox project in the CNCF (Cloud Native Computing Foundation) now. Here is a brief intro to the project, this change, and our nearest plans.

werf joins CNCF as a Sandbox project

• werf was initially created in Flant as a tool to automate the building of Docker images. Over time, it grew into a much broader solution covering the whole software delivery lifecycle involving containers and K8s. It has been an Open Source project since its inception seven years ago (here’s its main GitHub repository).
• CNCF is a vendor-neutral home for Kubernetes, Helm, ArgoCD, and other great cloud-native software, which is what werf builds upon.

We believe the CNCF is the best possible home for werf that will help it to get a wider community of users & contributors and align better with other cloud-native projects & the industry needs.

What werf is and when you need it

werf is an Open Source CLI tool for CI/CD which helps you implement efficient and consistent software delivery to Kubernetes by:

• integrating well-known technologies,
• extending their features,
• and facilitating best practices.

To be more precise on technologies, werf:

• implies you’re using Git,
• relies on Buildah to build container images,
• is compatible with various container registries to manage your images,
• embeds and extends Helm to deploy to Kubernetes,
• integrates with a CI system of your choice (and includes out-of-the-box integrations for GitLab CI/CD and GitHub Actions).

The best practices werf brings include using established technologies (mentioned above) and their configuration patterns (Dockerfiles, Helm charts) as as well:

• an advanced caching system speeding up your building time,
• builds’ reproducibility via Giterminism (using Git as a single source of truth; we described this concept in the werf v1.2 announcement),
• content-based tagging (why is it good?),
• enhanced resource tracking in Helm (see details in our werf vs. Helm comparison),
• smart cleanup of old/unused container images (what is this about?).

When will you need werf? It can be used from both sides of DevOps, development and operations. There are two main scenarios why software engineers opt for it:

1. Experienced users of existing technologies for building & deploying containers are looking for better — i.e. easier to maintain — options for their CI/CD toolbox. They can ditch their DIY implementations in favour of a robust integration layer between tools they know & trust (such as Helm) and enforce the best practices within their teams developing and operating the products.
2. Beginners are overwhelmed by a huge ecosystem of cloud-native tools available today and they don’t know how to start. With werf (and its guides), they get a ready-to-follow path to build & deploy containers to Kubernetes. Following this path, they will also learn essential tools used under the hood. It’s also important they’ll have a solid foundation for implementing full-featured and proven CI/CD on a different scale.

What CNCF means for werf

From now on, CNCF is the owner of werf and a vendor-neutral government body fostering its future. Practically, it means the project will follow an open governance model described here and other CNCF guidelines created by the worldwide community for the common good of the Open Source cloud-native ecosystem.

Existing werf users have no reason to worry since our core maintainers responsible for werf before will continue their work. The main difference is that their work will become more public in accordance with the CNCF policy and recommendations.

The formal project onboarding process is happening in this issue.

Our future plans

The last major effort in the werf development was a huge overhaul of the documentation. While it’s still an undergoing process, you can see many fruits of this process on the website already.

As for the next big things to implement in werf, our current plans include:

• Promoting layer-by-layer caching in Kubernetes-native image building (using Buildah) to stable;
• Advanced management for werf inner tasks.

The latter implies:

• Minimising configuration drifts by moving all logic to the pipelines described in werf.yaml;
• Implementing sophisticated CI/CD use cases by running multiple werf tasks in parallel and/or in a specific order: for testing scenarios, deployment orchestration, etc.

P.S.

If you have any questions or suggestions, we’re happy to hear from you in this GitHub Discussion.

Please, feel free to star the project on GitHub and spread the word about this exciting news for werf, too!

P.S. Follow the project on GitHub, Twitter, and Telegram to stay updated.