 היי, אני עודד, אני עורכה בוייפר כובנציסטים, אני פלטפון אינג'ניר. So, you set up your cool new GitOps repo. You read all the articles and you saw the sessions, and you know that you should probably, the best way about it is to set up all your clusters as separate folders in the repo main branch. You set up your Argo instance and it reconciles every change you make in those folders to your cluster. Everything works. And now you want to make a new change. So we start with the lab cluster, you edit the file, it automatically reconciles to the cluster, everything works, amazing. You're testing a change, it's good, you want to promote it. Okay, no problem. You create a branch, you copy the files, commit the files, open a pull request, maybe it needs to be reviewed and then you merge it. Amazing. Now the change is promoted to the next dev environment. But you probably need to promote it again. We have multiple clusters, multiple environments, multiple sites, so we promote it again. Another branch, another copying of files, make sure you don't miss any file, commit them, create pull requests, have them reviewed and merged. But we're still in staging, right? There's more to go. And more and more. And it's not great. So I wrote a tool to help me with that and it's called Telefoniska. So the basic functionality of Telefoniska, it watches over merged pull request, that changes files in specific folders in your repo and just opens pull request that syncs those changes to new folders. A PR is merged and new PR is created by Telefoniska. It's tool agnostic because it basically manipulates files and pull requests so it can work with AgustD but it can also work with Terraform or Flux or any other GitOps repo or tool. It supports multi-stage promotion and you get control over granularity of the promotion. So let me go over this. The first scenario, the simplest one, from dev to prod, you merge something to dev, it opens a pull request for production. The second example is a multi-stage flow where you merge something to dev, it opens a pull request to prod. When you merge that, it opens the second pull request. You merge that, it opens the third. It kind of works you through the flow. The third example, just so that you can merge multiple folders in one pull request, maybe in dev where you don't care about blast radius, you can just deploy to all your dev environment at once. The fourth example is kind of a fan-out approach where you just have the tool open multiple pull requests and the user can merge them as he sees fit. You can also mix and match with all of those. You can have complex flows or simple ones. Because it uses the super familiar pull request user experience, user are familiar with it, you can interact with it using the CLI or the web UI and Telefoniska also interact with the user with comments and labels. So the whole user experience is very familiar. And you can use GitHub's features like co-donors and pull request status checks to further customize your flow depending on what your organization needs. Telefoniska also warns the user on drift between environments because Telefoniska strives to keep environments in sync. It syncs component folders in their entirety. It means it copies all the files in one component in dev to some component in pod, for example. So if some earlier change was not promoted, the new change will take the older change along in the promotion path. So in this case, Telefoniska warns the user, shows him what kind of drift exists with details, and the user can make an informed decision. He can either take the old change along with it, along in the promotion flow, or he can manipulate the git state to reach the desired result. All those behaviors are controlled with an in-repo configuration file in the root of the repo, and because you now have a file that describes the promotion flow, people can discover it. New engineers can use the repo. They can understand how that specific team promotes stuff on their infrastructure. If you make a change, you can peer-review the flow. The flow is now a part of the infrastructure as code repo, and it can be shared with other teams or other organization, discussed and discovered, as I said. I think I ran for this pretty fast, or I even have time to go a bit over the configuration. I'm not going to walk through it step by step. I just mentioned there's another feature that I didn't talk about. There's a few features. It can run in dry run mode. It can auto-approve PR, which is sometime useful in some cases. You can control the behavior using labels. You can open a pull request and label it and get another flow. In this case, it can open a PR for multiple clusters in production in one PR. It can aggregate a few promotions in one PR, which is something desirable for speed. You can balance it with risk, of course. That's it, actually. The project is a very early stage. It was written by a mediocre software engineer. I appreciate any feedback on the code, documentation. You can reach out to me or do it electronically. This is it. Thank you. You can probably take one question while the next speaker is setting up. Do you want to unplug here? One question? No pressure. I set it up because I said there was one, so you feel like it has to be still good. Here you go. I wanted to understand telephony is a part of Argo's initiative. In our environment, we use... It's an open source, right, without license. Do I need to do something extra, or is it some helm thing we have to install? The installation, there's two ways. You could use it as a GitHub action, which is the easiest setup, but it's a bit slow. We internally use it as we run an actual web hook server. It's actually run on our infrastructure, and it's the preferred way because everything works fast. If you put a label or you comment something, you get instant feedback. The GitHub action is... It starts a container. It's a slow process, but it's a great way to test the tool to start with it. Because it's the installation, you can set up a web hook, you need a secret GitHub application. It's a bit involved. The GitHub action weighs zero. And you have a UI as well, right? The UI is GitHub pull request UI. The whole interaction with the user is done using comments on the PR and labels on the PR, and there's no other UI element. In ARGOSID, we have an ARGOSID UI, right? We can see everything in pictorial conditions. All the information needed is either in the Git or in some comment in the pull request. There's no extra UI. I use the CLI a lot. I open pull requests and view them for the CLI. So right from deployment till the pull request, we can use Telephone Insta, right? Right from deployment till the pull request. Thank you. I give a round of applause. Thank you.