 Thanks for joining me, guys. Thank you very much for your time. If you had a chance to define what is tomorrow, what will it be for you? This is my take, taken by Sir Ken Robinson. Take a look. Do it in a very geeky way. So, it's a mystical land where 99% of all human productivity, motivation and achievement is stored. So, eventually to be less sarcastic, it means that if I want to do something ambitious, I will delay it for tomorrow. And why it's relevant? It's relevant for us because if you want to tackle our CI-CD system, it's a very tough cookie to crack. Because two things. One of them is, spoiler alert, most of us already have a CI-CD system, so why replace it? It doesn't make any sense. And the second thing, because it's a very, very fundamental part of the court of the developer operation, any mistakes that we'll do investing in a new technology in our CI-CD system would be very hard to fix if we have any mistakes, as well as the adoption rates, etc. My name is Elad. I recently, recently, today joined Terra Sky as a tech lead at the city office. And I would like to discuss to you about what we can do and explore much of ways to solve our problem. So, like every day in the office, our type of the development process is a developer pushing its code throughout a pull request into our Git repository, and it makes sense for us. And of course, we have Jenkins, I don't know if you know, the master change to a controller as the semantics change, everyone think about it. And what happened here? So, of course, if you're taking some kind of crazy trip into a memory lane, we're managed static slaves, and now the nodes, we manage it by ourselves. It's crazy. But a few years ago, this is how we handle our orchestration of job in Jenkins. We already know that if we have, for example, here Java 11, if we want to orchestrate it, we need to have a slave. There's several are going to be some kind of computers that we need to connect to. We'll preload and install other requirements, but it seems crazy today doing so, no? So, it was hilarious in the past. What we should do next? And in this case, and it was introduced around four years ago, maybe a bit more. The Jenkins Kubernetes plugin has showed why it was so important. We invested a lot of compute moving into Kubernetes. Kubernetes in its nature, it's stateless. Your provisioning compute based on your requirements. But Jenkins in its main strategy is static by definition. So, how can you solve it? We solved it by the Jenkins Kubernetes plugin, and how we do it. The plugin enabled dynamic scaling of compute and memory resources out of the Kubernetes clusters. How it looks like, as you see in the picture. So, we're developing in our dev environment, we're pushing the code. Now, we have a webhook that's triggering our Jenkins. And then, the Jenkins files describe the information that I want to run in the pipeline. So, what's the benefit of it? The benefit of it is that, besides running and managing, again, static scripts and managing by ourselves, we can have one source of truth where it could describe everything that happened inside the pipeline. And I know this is a known practice that we're using daily, and I'm sure most of you are also doing it. And it's our source of truth. But when we go and try to deploy it and run it in some kind of, as we said, Kubernetes pod in the Kubernetes world, we use the Kubernetes template as a YAML file. And as you see here, we can describe the metadata, right? It means the containers that I want to run. So, for example, if I want to run and build a docker, not the docker, sorry, and Node.js application, I will instance the docker container with Node.js. And also, I need to define the agents to communicate back to the Jenkins. And then I can set up more requirements. So, for example, how much memory and CPU I need to consume, and this execution alone. And this is a stateless execution. After you're running this pod, it will be eliminated and back into new resources. And of course, we run to run our pipeline business logic. And how are we going to do it? We're going to do it by running a pipeline, Jenkins pipelines, agents, Kubernetes, label, and load the files. And of course, after doing all the configuration, all the bootstrap, the business logic is steps that we want to run, building this NPM package, running Glint, sending it maybe to a docker registry. All of it will be in the logic and the step section. What's happened behind the scenes? So behind the scenes, every time they're using the Kubernetes Jenkins plug-in, there are some components behind of it. The runtime, which executes everything, which is the pod itself and every other aspect of the Kubernetes cluster. The spec, which is a metadata spec defining any pod that you create in Kubernetes. And of course, you have two more things which is really important. One of them is a Jenkins agent. And you know how much hassle we need when we need to configure it and communicate back to the master or controller in our case, when we need to get all the information back about how the execution of the pipeline went. Good, bad, and also streaming of the STD out and STD out and STD out of all the outputs. And of course, we have the docker and docker. Why are we using the docker and docker? The docker and docker is very common practice. When you want to run a dockerized application inside a docker also container, you want to do it in order to make a separation between the running components, because if you will not use docker and docker, when you will run it on the main docker itself, then it can crash it and make problems. This is a bit maybe less relevant for today because when it's encapsulated under a pod, then if something crashed, the pod will be crashed, but it will not affect any other pod, or for this sake our component is clustered. So it's a bit less relevant today. And of course, we understand that in a mature company we have multiple runtime environments, we have multiple development languages, we have multiple compilers that we're using different, a machine architecture like ARM, X86, each one of them requires some more tweaks in the make files or any configuration files, it's a bit more complex because right now, even if we have the Jenkins file, and even if we have the best usage of the Kubernetes Jenkins plugin, we still need to manage it in some kind of a repository, for example, our Chef agents, Go, Helm, Java, Node.js, and of course, if you want to manage it, then you want to manage revisions, and managing the revisions means that you have a different directory. And you'll see where I'm going to, it's a lot of management, and you need to handle it version by version. So it's a good way to continue, but it's still more complex. And of course, when we're talking about Jenkins, we talked about orchestrating the jobs, but what about Jenkins itself? How are we going to install it? Is it magically going to happen? So when you're talking about Jenkins, you can try to manage a cool one-seat driver, a seat car driver with a bunch of cool plugins that how many communicate and work with each other. But guys, it's not working. If you have experience with Jenkins, you know that this is going to happen, and again, and again, and again. And this is crazy, because you know why it's so crazy? Because at the end, any one of us just excluded a plugin, just bypassed another thing, and if you're talking about managing Jenkins, the Jenkins itself is not just the pipeline, and orchestrated in a runtime environment, we can spin up Jenkins with all the plugins. I don't want to manage each plugin life second differently. It's not going to happen if I want to promote some kind of, let's call it, cloud-native deployment of Jenkins itself. So how am I going to do it? I'm going to introduce, and this is something that I think very well-adopted in the last three years, is that it's the Helmchart of the Jenkins, which is officially supported by the community, and the Jenkins configuration as a code. And what nice in this plugin, it's enabling you to define under one Helmchart all the configuration of the Jenkins itself, the image, how the ingress to expose it to the other word, TLS, et cetera, but also with the Jenkins configuration of the plugin, you can define all the configuration of the Jenkins. And what's best of it is that the next time you want to go to another company before you're going to manage upgrade of Jenkins files, you have a snapshot. And when you have the snapshot, you will define every plugin, every configuration in a baseline that's stabilized between all the relations of the plugins. So in order to move forward, you just need to install Helmcharts, divide these values, YAML files, with all the configuration, and wire it together. So it seems like Jenkins rows. So we can drop here, give you more, about 20 minutes to grab something more to it, but, and I think we're yet enough, but it's not the case. As you see, there is a lot of configurations, there's a lot of things to do, still a lot of manual wiring need to be done, and it's not a cloud native solution. So why it's so complex? It's so complex because when you need to deep dive into your pipeline, and again in a previous company, we use this architecture, but still we had a lot of groovy code that need to be checked. A lot of libraries that we built on top of the Jenkins files, it's too much. There are much more simple way to do so. Can we find another way to do it? So to summarize this section, I think that our relation with Jenkins now, it's a bit complicated. Jenkins, and to be frank, has been around for quite a lot of time, but beside of its amazing plugin system, the core of Jenkins didn't change, and depend on multiple plugins and the relation between them to create a very robust solution that as I said, in the heart of the DevOps operation, it's too risky to do today. So if I want to move forward, I'll try using the CNC-NF and to be more precise, this is a continuous delivery foundation, and maybe we have a solution in our landscape. So of course, as I told you, the name of the session was Jenkins in the X-Factory show. There was Jenkins 6, and here it is. So this is from the CDF landscape when you dive into Jenkins 6. And let's try to figure out what's good, what's not good. Can you hear? Okay, sorry, I'll not be here. So we have an automated CI-CD solution for Kubernetes, which is great. We have a cloud-native pipeline, another one. It's using Tecton. Tecton is a great product to orchestrate your workflow, pipeline workflow. It was ported, worked from Knative, and now it's a very popular project. It seems like it's an incubating status. I don't know what it means, but I think it's okay, and it's have a decent amount of stars. So it seems like a very, very good project. Let's see, before we invest, and as we said, it's very critical, let's see what's happening. So it was developing back in time in 2018, and it was introduced by James Shaken, which is, he was one of the main influence and developer of both Groovy and Camel, and it was adopted by Cloudies. He was working and maybe still working in Cloudies, and it was a blast. A year after, it was stabilized, and Gentigus number two supported more practices on the CI-CD world, such as monorepos, extending build tools, such KPEC and BuildPECs, and it was great. And in 2020, this is where the CD Foundation has established, and it was one of the earliest adopters of this foundation. And by 2021, it was introducing also Gentigus number three. In version three, it was a major refactoring. It included Tecton, as I showed you, Lighthouse to support Git-based operation, a very robust Gentigus JX CLI, and it was great. And everything was fine, and in my previous company, we even started developing some kind of a prototype application of it, and it was very good, but it was very opinionated. As you can see back in the time, and it was like three years ago, I opened a ticket. I wanted to implement some kind of a pipeline in a company, and in the company, I want to use not a chart museum, but a factory. When you decide to say, I'm opinionated, it means that your framework, your platform, is deciding something for you. So of course, over time, there was support, there was a plug-in, or any other way to extend it, but over time, when we want to use some kind of opinionated framework or platform, you need to understand that if you decide it, you need to embrace it. They have a guidance on how to do it, and it should be very good for you. But something happened. As you see here, this is Contributor's page of the Gentigus JX website, and as you can see here, it was great for around three years, but I think we all see there is no contributions today, at least not something that can help us as a community, because we want our software to be evolved, especially the software that we put all the money in. And Cloudbees, and I don't know how to backtrace it to a specific time, they had a distribution, a managed distribution, which is also very important for us. But now when you go to the website, you see the page say, okay, guys, Cloudbees, Gentigus distribution is not available. You're all welcome to go to the website, to the GitHub, and work with the project, but we do not support it anymore. Guys, we may have a problem. If you look on the Git tickets, let's see how much traffic we have on the issues in GitHub. This is around 20 tickets that was opened in 2023. Some of them are really just at high level. Some kind of find a contribution, a Gentigus contribution award. Great, I want to see who it is. But it was, it's not active. And I think that the last thing to put here is that we do see as a, TOC is a technical overseas committee, because it's a clear state that we're looking for more contributors. So guys, I think that we have a problem. We spend a lot of time, we spend a lot of money. This is our CICD system. What's going to happen now? So I think that at this moment, you're going to say, dude, what are you doing? You're just depressing us. You don't see, you don't give us any solution. You're just telling us what is wrong. But I think, I think it's important, because I'm going to show you the next big thing. I want to show you what platform will solve all the problems. Make sense? No, I'm not going to do it. Why? Because I'm not going to be here in three year times, telling you again, I selected another technology, which is amazing, but now guys, it's all dead. This is what I've done in Yala DevOps three years ago. So shame on me. So I think I want to take another approach when we're talking today. There are success stories, and there are not success stories, to be politically correct. And I think that the next time we're deciding on the ICD system, instead of selecting a specific technology, let's try to focus on the pin points, the decision-making process. What's important for us when we're deciding our next solution? So we are open source, we love open source, we understand that CSNF is the greatest open source committee that I think ever happened after, of course, the foundation of the Linux foundation itself. And what you see here, taken from the CSNF website, and it is describing what is project maturity. And of course, crossing the Kazam first when they presented this slide is how the open source owners taking the measurements to move from an early adopters, this is very cool technology, let's use it to really move into a border market mainstream customers. And this is a very, very important one. But it's also very important for us to decide if we want to be an early adopters, or if we want to take only after it was stabilized. And in our case, it's graduated. But I'm saying graduated. Let's see, you know, like, what is so amazing in the open source world? Everything is open. You can understand every aspect of decision making in CSNF. And this is why they're so great. And as you can see here, they're telling us what is graduated. So graduated means at least two big companies. I said big company, but I think two major companies that influence on the contribution level, they spend time, company time, influence on the project itself. They may be the owners, but they maybe have a lifting some of the contribution on the project. It could be doing an external auditing of security concept, security auditing of the project itself to make a governance status of the project itself. And also it's important that it will be used by a real company solution. It could be a private one, it could be another open source, but it's really, really important. So this is the first lesson. So in my opinion, this is only me. Next time I will decide on a solution for my customers, for my previous company, or for any other company, I will stick to this table. I will stick to the maturity. And when you're talking about CSNF, it's so easily can be disrupted. So please, don't bite off more than you can chew. I think we can spend years understanding what's the landscape of CSNF. And we have another project and another project. I used Knative, there is other projects doing the same thing for running serverless computing, which one I selected. I think that we need to focus on the graduate project. And this is a very important take away. When you focus about a graduate, and if you agree with me, I think there are four candidates that you need to look for. One of them is the Argo CD. The second one is Jenkins. And Jenkins is a damn good project and it's okay to stick with it. And of course, when you're talking about orchestration of a pipeline, it could be Tecton, or it could be Argo workflow, which is another project. And if you're talking about GitHub separation, Argo CD and Flux are very much a project using production. You can read about Vimwell, by other projects as well, as well as Argo CD that we discussed. We have a commercial product that backed by this technology if you don't want to use open source project. And I think that it's not the only way to go. Take a look on this diagram. I think that if you come into a company and you will tell your managers, okay, you have a CI CD, throw everything away, just put everything new, it's not going to happen. So, it's totally okay to keep your Jenkins as configured. Use Helm charts, use configuration as code, use the Kubernetes plugin. Okay, it's okay to manage your revision of configuration based on the pipeline. It's totally okay. Take the CD part and break it down. And when it may break it down, it's totally okay that your CI CD will trigger the build of this GitOps and Argo CD to orchestrate your CD part. So, why not combining with Kubernetes? So, for this, for example, I have an application developed in TypeScript. I'm pushing my code to my GitOps repository. Everything is going to CI CD throughout Jenkins. I'm using build packs and some other technology. But with here, I can divide and conquer. I can decide that for the CI, I know it's working, it's okay. Maybe I'm going to replace it in the future. Let's divide it. And the CD part can be used by another technology, for example, could be by Argo CD or any other technology, I think. I think it's totally okay to say that we can use commercial products. And this is something that was very, very problematic for me. When I adopted Jenkins 6 in my company and in my previous company, and we just as we said, rolled back, I think one of the things wasn't just because it's a lack of support. It's working. But for a mature company, when you do evaluations, when you do anything that's important for managing for a long scale, you need to know if you have a managed service or not. And by cloud-based deciding to push out from this project, it was very hard. Because even if I was saying in the future I will move to a managed service, it's not going to happen. And by taking a very opinionated standalone project which is currently not under development or basically nothing, it's okay to decide to go with the commercial solutions. So, for example, using GitLab, which is doing CI CD, great CI CD, and the CD part is implemented by Flux. Or Harness, which is, you just acquired, I think it was a year ago, maybe less drone. So now we have a full CI CD system. Don't be tempted by the buzzword. Don't be tempted by the technology. It's just a technology, it's just a buzzword. Your solution, your requirements is to develop a full CI CD solution that it works. And Codefresh, which is giving you, for example, implementation for ArgoCity, and all Argo workflow, which is very, very important. Also, don't put your time only on technology. And another example is TAP, the Tanzu application platform includes also a CI CD system that can be used as part of your developing your application. AWS has everything, it's okay. So I think what I want to do, I want to try to summarize it up. I'm not going to tell you which kind of technology to use. What I was trying to tell you is that before you're selecting your next best in line project, before you're moving on to another project, think about the maturity of the project. Think about the landscape of CSNF, and if you decided to go with the incubation project, or go with the fully graduated project. And the same thing is that the second thing is Jenkins is still live. There is no need to push yourself out of Jenkins and tell you that you have to migrate. It's absolutely okay if you're using the best practices. It's okay to use Jenkins today. It's absolutely okay. And the other solution is that it's okay to use Manage... And the other point, sorry, is it's okay to use Manage solution. It's okay, it's fine. At least it's not something that you can pour it off or something that you can change over time. At least you have a company that's backing up, and it's okay for a company. I think, in my opinion, it's okay to decide it. And of course, if you want to go fully blown, you can still use Jenkins Insects. I think some other people will not agree with me, but this was my take. And guys, thank you very much for your time. I really appreciate it.