Werf: Glue Together Git, Docker, Helm, Kubernetes For CI/CD Pipelines

Thanks

Is it possible to use helm charts created by were independently outside without depending on werf later?
If yes, then it will be useful for product developers to create helm charts for their software without needing to learn helm.

Nice review, thank you. Had seen werf a bunch of times, but didn't look into it. Your honest review gives a very insightful overview of it, appreciated.

What is your preferred OpenSource, cloud agnostic application/service for Event Based Micro-Service communications? Kafka? Kafka Streams? Some MQ Implementation? I have watched almost all your videos now and so far we see eye-to-eye on almost everything… Love your thoughts on this topic.

Thank you for cutting through the BS and explaining very succiently what this actually does and what is does NOT do. No disrespect to the devs of werf, it certainly can help some newer orgs simplify their pipelines potentially, but yeah. Excellent explanation etc. Subscribed.

Thank you for the video and following replies, Victor! There are some important clarifications about werf we want to do as its core developers. We've discussed some of them on Reddit already but it would be good to post here since it's the actual place where the video will be watched 😉

1. Local development is implemented in werf using –dev and –follow flags. We've seen your excitement about not allowing to converge when files are not committed (08:05). However, this very error message also states: "You may be interested in the development mode (activated by the –dev option), which allows working with project files without doing redundant commits during debugging and development." While werf was originally created with CI/CD in mind, when our Giterminism being introduced, it was extended with this local development support to make developers life easier (and more features here are ahead).

2. "werf converge" is not the only way you can use werf. Here are also: a) bundles, b) export/render commands to implement different ways of delivery. (You can find the werf 1.2 stable announcement for more details.)

3. "werf converge" is the default way of using werf indeed. However, it would be a big mistake to boil it down to executing docker build + docker push + helm upgrade. There is so MUCH MORE: a) inside, including separating building process into different stages, benefits from reading the Git history, content-based tagging, cleaning up the registry, synchronizing simultaneous builds (distributed building), etc. + b) outside, since werf serves as a unifying, controlling part of the whole CI/CD process. There are in-depth comparisons from which you can get a much better understanding of how the basic mechanisms mentioned in video are extended in werf — just google for "werf vs Helm" and "werf vs Docker". In terms of Git, werf is not as straightforward as you probably think (using the only monorepo as it is) since werf also supports Git submodules and remote repos.

4. Building in werf was originally implemented using docker build. Saying this dependence kills the idea of using werf with Kubernetes (since dockershim support in K8s is deprecated) is quite odd, though. Kubernetes doesn't care how you build images, it will run any of them using with your preferred runtime (containerd, etc.). There was no issue at all with that. Running werf inside Kubernetes is another issue, though. While it doesn't seem to be the first thing you need, it's still a valid case. It is supported in werf since quite recently. To achieve this, another building mechanism was implemented in werf and it is based on buildah. It makes possible to run werf in Docker/Kubernetes, e.g., we have ready-to-use examples for using werf in GitLab CI/CD with both, Docker and Kubernetes executors.

In general, werf might not seem a killer app for such a basic scenario provided on video, yet it has much, much more to offer if you investigate into its features. It's different from a vast majority of other tools on the market since it tries to cover the whole CI/CD process, from building to deploying and cleaning up. And it still follows the idea of not reinventing the wheel, but integrating existing well-known basic tools for each of part of the process (i.e. Git, Docker, Helm, any CI system, etc.). We now see some major problems in our high-level documentation and are super grateful for making it obvious for us with this video. Your feedback on GitOps vs. Giterminism is also much appreciated! More great work ahead for the project to help people understand how they can benefit from it 🙂

As far as i know – werf does much more than focussed in the video, and these additional fetures are basically main fetures, not the simplified workflow (which is not worth to be even mentioned).
To name a few:
1. Werf has its own image builder not based on docker.
2. Werf keeps your image registry clean, by deleting unused images (and doing it really smart and not like f.e. nexus scarry approach just deleting older ones)

Kontinuous is a Continuous Integration & Delivery pipeline tool built specifically for Kubernetes. It aims to provide a platform for building and deploying applications using native Kubernetes Jobs and Pods.

Hi, Thanks for your videos Viktor. I really like them. What about "store git" step? Do you recommend any tool? For instance: 2 repositories, one with my application and another to be a control repo (for argoCD or flux). How can I add my manifest into my control repository using CI? Or it's better to keep a bash script to make all git add+commit commands. What do you think? Any ideas?

Imagine being someone at Werf watching this video 😅

I'm not sure how it adds when considering the functionality discussed is redundant. That said, their documentation is absolutely stunning and very well put together. I feel like every "Giterminism/GitOps CICD" doesn't focus enough on things like hot reloading from local-to-remote, local development options, and better integration with Imperative configuration generators like cdk8s.

Despite the correct facts, the review is very one-sided, as if it was done carelessly. Victor does not describe what problems the werf is trying to solve and how. Perhaps he himself did not figure it out because some of the materials are available only in Russian.

Good review Viktor, thanks for do it

Really interesting and useful Video Viktor. Thanks for share it and eager to see the next one

Thx for the informative review!

Во фланте радуются пипец)

For monorepo, how does werf compare to "nx affected"?

kaniko support is on the roadmap

werf is helm only? That is, it does not support kustomize? Is skaffold its closest relative?

Great video as always! But I have a question.
Wouldn't a CI pipeline manage by Argo Workflows + Events / Tekton (kaniko or buildah for building and pushing images) and cd with ArgoCD accomplish what werf is trying to accomplish, only with much greater customizability and more control + scale?

Hello, Viktor! Thank you for another helpful review! Is there any chance to review the current state of the buildx project?

What do you think about werf? Do you share my opinion or you found it to be useful?

I made a mistake by missing the `–dev` argument that allows you to use Werf during local development and without committing files to Git.

IMPORTANT: For reasons I do not comprehend (and Google support could not figure out), YouTube tends to delete comments that contain links. Please do not use them in your comments.