[00:00.000 --> 00:18.040]  Yeah, I think I will start, otherwise I would know I want to have, I mean, I like to talk
[00:18.040 --> 00:21.080]  a lot, so I won't have enough time anyway.
[00:21.080 --> 00:25.560]  So thanks for coming to my presentation, and today I'm going to talk about the challenges
[00:25.560 --> 00:28.040]  of updating everything.
[00:28.040 --> 00:29.040]  So my name is working.
[00:29.040 --> 00:31.920]  I'm also one of the CI-CD Dev Room maintainer.
[00:31.920 --> 00:36.640]  I'm working for Sousa on all things related to Kubernetes, Rensho.
[00:36.640 --> 00:40.760]  So if there are anything you want to talk about, feel free to reach out after my presentation.
[00:40.760 --> 00:44.440]  But today I'm not here to talk about what I'm doing at work.
[00:44.440 --> 00:48.520]  And here to present a project that I started before joining Sousa, back then when I used
[00:48.520 --> 00:52.160]  to work on Jenkins projects, and that project is named Update CLI.
[00:52.160 --> 00:57.280]  So Update CLI is a common line tool that we use to automate things.
[00:57.280 --> 01:02.040]  So the design is to run it on your machine, on the CI environment, whatever it is.
[01:02.040 --> 01:07.980]  And so you specify in your manifest what's the update strategy would look like.
[01:07.980 --> 01:12.200]  So initially I wanted to talk about, first, Update CLI, and then all the challenges that
[01:12.200 --> 01:16.040]  you have when you want to automate Docker images, when you want to automate infrastructure
[01:16.040 --> 01:17.040]  or whatever.
[01:17.040 --> 01:18.560]  But I won't have the time to do that here.
[01:18.560 --> 01:23.000]  So for those people in Ghent, for the configuration management camp, I will have more time over
[01:23.000 --> 01:24.000]  there.
[01:24.000 --> 01:30.280]  I will just focus on what Update CLI is, what the problem is, and what I'm trying to do.
[01:30.280 --> 01:35.200]  So the challenge that I face is, quite often when I maintain large amounts of projects,
[01:35.200 --> 01:37.320]  something that used to work, to not work anymore.
[01:37.320 --> 01:41.880]  Like you are using Ugo, for example, to generate a website.
[01:41.880 --> 01:46.200]  And then at some point, you cannot deploy the website anymore because even though projects
[01:46.200 --> 01:52.400]  release a new Ugo version, they fail to build the published Docker image associated to that.
[01:52.400 --> 01:57.160]  Or you would realize yesterday I was investigating an issue where Update CLI would deploy and
[01:57.160 --> 02:02.520]  would roll back a version of the NGNX Ingress Controller, and then it ended up that the people
[02:02.520 --> 02:07.780]  maintaining that container just released, deleted the release, forgot to remove the
[02:07.780 --> 02:09.280]  GTIG in those situations.
[02:09.280 --> 02:11.080]  So you would expect something to work.
[02:11.080 --> 02:12.080]  You won't automate.
[02:12.080 --> 02:17.120]  And the thing is, when you get in those situations, you try to understand why it didn't work.
[02:17.120 --> 02:20.200]  I mean, it used to work for years, and then suddenly it doesn't work anymore.
[02:20.200 --> 02:23.920]  And then so you spend time trying to understand what's the latest version, what's the changelog,
[02:23.920 --> 02:26.760]  what's something failed, basically.
[02:26.760 --> 02:30.880]  And so when you want to automate those updates, so you don't have to pay attention to them,
[02:30.880 --> 02:33.320]  I mean, it obviously has benefits, right?
[02:33.320 --> 02:34.320]  I'm curious.
[02:34.320 --> 02:38.720]  Who's using, for example, Tip and Abut or Renovate about to automate things, updates?
[02:38.720 --> 02:41.560]  Yes, a few people.
[02:41.560 --> 02:43.000]  It's only the start.
[02:43.000 --> 02:48.880]  But once you start automating things, you know that, obviously, it gets easier to change
[02:48.880 --> 02:54.720]  your project infrastructure documentation, no matter what, because you get confident
[02:54.720 --> 02:57.800]  in the change that you want to do.
[02:57.800 --> 03:02.320]  And in my case, most of my projects are hosted on Git repositories.
[03:02.320 --> 03:05.680]  And one of the challenges when you have, when you think about those Git repositories is everything
[03:05.680 --> 03:06.960]  is a file.
[03:06.960 --> 03:11.320]  And what you try to do is you try to automate them, but most of the time you have no idea
[03:11.320 --> 03:13.640]  what you're trying to update, right?
[03:13.640 --> 03:17.520]  So for example, Dependabut will just look at a package of GZN.
[03:17.520 --> 03:21.280]  So if you find a package of GZN, we'll list all dependencies and try to update them one
[03:21.280 --> 03:22.280]  by one.
[03:22.280 --> 03:27.440]  But on the other side, for those people using, for example, random GZN file, there is no
[03:27.440 --> 03:31.560]  way to know in advance what should be updated in those files.
[03:31.560 --> 03:35.400]  And then you have all those middle grounds, like, for example, for those people familiar
[03:35.400 --> 03:39.240]  with Dockerfile, you have some instruction that you can automatically update, like the
[03:39.240 --> 03:40.240]  from instruction.
[03:40.240 --> 03:42.800]  It's pretty straightforward to know what you need to update.
[03:42.800 --> 03:45.040]  You don't know what you want to update.
[03:45.040 --> 03:46.320]  That's a different story.
[03:46.320 --> 03:49.280]  But the thing is you know that you want to automate the base image.
[03:49.280 --> 03:52.600]  On the other side, you can put pretty much every information in the run instruction,
[03:52.600 --> 03:58.640]  the label, the end instruction, and that's where things get difficult.
[03:58.640 --> 04:02.560]  So when we started working on a data line, we wanted to think, OK, we want to automate
[04:02.560 --> 04:03.560]  everything.
[04:03.560 --> 04:07.880]  So we want to define where the information is coming from, what are the conditions to
[04:07.880 --> 04:12.520]  automate the thing, and finally, what should be the state of your file on your Git repository.
[04:12.520 --> 04:18.080]  So if I go back to my ego example, the idea is the source of information is the latest
[04:18.080 --> 04:19.080]  ego release.
[04:19.080 --> 04:21.800]  That could be the Git tag, that could be the latest Docker image published, that could
[04:21.800 --> 04:23.720]  be the GitHub release, for example.
[04:23.720 --> 04:28.640]  But at some point, we have to decide what's the source of truth for that specific application.
[04:28.640 --> 04:31.600]  And then you have, like, a bunch of conditions that you want to apply, like, does it make
[04:31.600 --> 04:38.720]  sense to bump the version in production if you fail to bump the version in the dev environment?
[04:38.720 --> 04:41.520]  So you want to be sure that you are using the same version everywhere.
[04:41.520 --> 04:46.520]  And only then, you will bump all the files related to that version.
[04:46.520 --> 04:50.520]  And so when we come back about Update CLI, the idea is we specify a manifest, we have
[04:50.520 --> 04:51.520]  to write a manifest.
[04:51.520 --> 04:54.480]  So that's the main difference, for example, for Dependable.
[04:54.480 --> 04:57.600]  Because Dependable, you just enable the button, it works.
[04:57.600 --> 05:00.080]  But it will only detect what it can detect.
[05:00.080 --> 05:03.240]  But most of the time, you have no idea what you should update.
[05:03.240 --> 05:06.120]  With Update CLI, we went the other way.
[05:06.120 --> 05:10.640]  We write a manifest, so for example, this one is you have the source, the source of
[05:10.640 --> 05:11.640]  truth.
[05:11.640 --> 05:12.640]  In this case, it's a GitHub release.
[05:12.640 --> 05:13.640]  So it can GitHub release.
[05:13.640 --> 05:17.080]  And then you have the specification, where you provide all the parameters for that specific
[05:17.080 --> 05:18.080]  project.
[05:18.080 --> 05:22.960]  So in this case, I am monitoring the go-go-io git repository.
[05:22.960 --> 05:26.080]  This one gives me a version, let's say 100.
[05:26.080 --> 05:27.080]  That's the latest one.
[05:27.080 --> 05:33.640]  And what I want to do is I want to be sure that all my files, named natify.tom.yml, are
[05:33.640 --> 05:34.640]  up to date.
[05:34.640 --> 05:35.640]  So I look at the key.
[05:35.640 --> 05:40.000]  And then if I run this manifest on my machine, it will just dump the file on my machine.
[05:40.000 --> 05:45.520]  If I run this manifest on the CI environment, it will bump the file in the CI environment.
[05:45.520 --> 05:49.680]  And so the next step is, okay, that's one thing to have it working on a machine.
[05:49.680 --> 05:53.400]  But then you also want to be sure that your git repository is up to date and don't pay
[05:53.400 --> 05:55.400]  attention to them.
[05:55.400 --> 05:58.960]  So you can just focus on what really makes sense in your case.
[05:58.960 --> 06:03.620]  And so the next step is, okay, we want to specify where that file is located.
[06:03.620 --> 06:05.520]  So we have a bunch of other resources.
[06:05.520 --> 06:11.960]  In this case, it's a SCM of type git, because I want to update git repositories.
[06:11.960 --> 06:15.640]  And then I specify that I want the pull request approach, where I create a temporary branch
[06:15.640 --> 06:18.800]  and then someone can review my change.
[06:18.800 --> 06:23.920]  And then when you think about all those building blocks, you can really have, like, more advanced
[06:23.920 --> 06:29.160]  scenarios, like this one is another project that we use, where we use it, is when someone
[06:29.160 --> 06:33.640]  really is in a new version of Apno, we use GitHub Action there.
[06:33.640 --> 06:38.200]  That send a bunch of release events automatically to other git repositories.
[06:38.200 --> 06:41.200]  And those git repositories will trigger Update CLI.
[06:41.200 --> 06:43.760]  So Update CLI will retrieve all the different information.
[06:43.760 --> 06:48.720]  So for example, on Apno slash docs, which is obviously the website, we retrieve the latest
[06:48.720 --> 06:52.800]  version of Apno, and then we check that all the download links are up to date.
[06:52.800 --> 06:56.080]  We check that we have the version for that specific website.
[06:56.080 --> 07:01.720]  So we maintain one documentation per major and minor version.
[07:01.720 --> 07:05.000]  So we try to be sure that those files are up to date.
[07:05.000 --> 07:07.360]  And if it's not the case, we open a PR.
[07:07.360 --> 07:11.480]  And then as part of the release process of Apno, someone needs to review the PR and double
[07:11.480 --> 07:16.880]  check that it still contains a file that you want to have there.
[07:16.880 --> 07:19.360]  Another example is the way we automate Hemshot.
[07:19.360 --> 07:25.000]  We define, okay, we are monitoring the Apno UI, which is a front application, and we monitor
[07:25.000 --> 07:26.920]  the backend, the Apno.
[07:26.920 --> 07:30.400]  And then if for some reason there is a new version, then it will automatically bump the
[07:30.400 --> 07:32.400]  Hemshot, bump the metadata, and so on.
[07:32.400 --> 07:36.440]  And once again, we have a human validation where someone can just come, look at the PR,
[07:36.440 --> 07:40.360]  and decide if we want to go one step further.
[07:40.360 --> 07:48.480]  So really briefly here is when automated update is not a so easy challenge, as I initially
[07:48.480 --> 07:53.120]  thought, because so we split the project in three different categories.
[07:53.120 --> 07:54.440]  So the first one is declarative.
[07:54.440 --> 07:59.000]  So the idea is you know in advance what should be updated, and so you define in a manifest
[07:59.000 --> 08:03.560]  how you want to update something, because it's not something that you can define in
[08:03.560 --> 08:04.560]  advance.
[08:04.560 --> 08:08.200]  The other discovery is a bit more like for those people familiar with Dependentbot or
[08:08.200 --> 08:12.040]  Renovatebot, you just run the command and you ask it to automatically detect what could
[08:12.040 --> 08:13.040]  be updated.
[08:13.040 --> 08:16.440]  There are scenarios where you can find that information.
[08:16.440 --> 08:20.640]  For example, on a Maven project, you have the pump.xml, you fetch all the dependencies
[08:20.640 --> 08:21.640]  and update them.
[08:21.640 --> 08:24.880]  That's pretty easy.
[08:24.880 --> 08:30.000]  On other projects like Docker containers, it's kind of a mess over there, so it's super
[08:30.000 --> 08:32.520]  difficult to know what should be the next version.
[08:32.520 --> 08:36.440]  And then on the other side, you have all those situations where you specify a constraint,
[08:36.440 --> 08:40.360]  a version constraint, like you don't want to use a version bigger than the 1.0, but
[08:40.360 --> 08:45.000]  at some point the project upstream is like way further than you are in your project.
[08:45.000 --> 08:49.600]  At some point, you need to be aware that you will need to plan some work to catch up
[08:49.600 --> 08:50.880]  on the upstream project.
[08:50.880 --> 08:54.520]  And so that's another experiment, which is update monitor.
[08:54.520 --> 08:56.000]  So I want to do a quick demo.
[08:56.000 --> 09:01.120]  I don't have good internet connectivity here, so I hope it will work.
[09:01.120 --> 09:07.960]  So on the left side is one of the manifest, is it big enough?
[09:07.960 --> 09:09.360]  Oops.
[09:09.360 --> 09:17.200]  So on the left side, we specify a few things like, okay, in this case, we want to enable
[09:17.200 --> 09:21.120]  the auto merge feature of GitHub, actually, of GitHub PolarQuest.
[09:21.120 --> 09:22.120]  We specify labels.
[09:22.120 --> 09:27.520]  So we automatically open a PR, and if all the tests are passing, it will merge the
[09:27.520 --> 09:28.800]  PR automatically.
[09:28.800 --> 09:33.000]  And so I don't have to pay attention, which reduce, obviously, the noise introduced by
[09:33.000 --> 09:34.160]  those PR.
[09:34.160 --> 09:37.400]  We need to specify which projects we want to go.
[09:37.400 --> 09:40.560]  So in this case, that's the updated website.
[09:40.560 --> 09:43.120]  And finally, we specify where the information is coming from.
[09:43.120 --> 09:45.280]  So this one, we monitor, go, go, go, go.
[09:45.280 --> 09:50.360]  As I said, we could have instead of monitoring the GitHub release, at some point I could
[09:50.360 --> 09:51.360]  have said, okay.
[09:51.360 --> 09:54.200]  I just want to monitor the Docker images.
[09:54.200 --> 10:00.320]  But in that case, I just need to provide a different piece of information.
[10:00.320 --> 10:07.760]  Or you could say, for example, I want to monitor here, writing from the IDD is the easiest
[10:07.760 --> 10:09.480]  way.
[10:09.480 --> 10:17.600]  You can specify different ways of filtering version, because what's something that we
[10:17.600 --> 10:22.840]  notice, for example, is when I said the Docker ecosystem is a mess, is you can put whatever
[10:22.840 --> 10:24.360]  information you want in a tag.
[10:24.360 --> 10:28.040]  So there is pretty much no way, I mean, most of the time, there is no way to know what
[10:28.040 --> 10:29.680]  should be the next version.
[10:29.680 --> 10:33.840]  Then depending on the registries, they don't return you the latest version, because they
[10:33.840 --> 10:36.040]  don't sort the tags in the same way.
[10:36.040 --> 10:42.400]  So at some point, yeah, you need to enforce a specific behavior.
[10:42.400 --> 10:47.840]  And then the target in this case is, if there is a new version of Hugo, we want to be sure
[10:47.840 --> 10:55.040]  that the workflow file has the correct version and that the native file is up to date.
[10:55.040 --> 10:57.080]  So I don't care.
[10:57.080 --> 11:01.440]  And so what it looks like on the other side is just a CLI, as I said.
[11:01.440 --> 11:08.040]  So you can read it from my machine, Linux, Mac, wherever you want to run it.
[11:08.040 --> 11:13.920]  And then, voila, you get the latest version, change log, depending on the situation.
[11:13.920 --> 11:17.560]  And based on that, you can just combine the projects.
[11:17.560 --> 11:24.160]  And so we have a lot of different workflows where we automate things.
[11:24.160 --> 11:27.720]  The last thing, how many time do I have left?
[11:27.720 --> 11:28.720]  Five minutes?
[11:28.720 --> 11:29.720]  Okay.
[11:29.720 --> 11:30.720]  Where is that?
[11:30.720 --> 11:31.720]  It's not this one.
[11:31.720 --> 11:46.720]  So the thing that I was mentioning for monitoring the different versions, so this one is a different
[11:46.720 --> 11:51.880]  way to see the problem is you want to monitor the version that you are using at some point.
[11:51.880 --> 11:57.760]  And so you want to compare, okay, in this case, on one location, I say I want to monitor
[11:57.760 --> 12:04.240]  a version from the native file.tamiaml, so it gets me a version which is 0.1010.
[12:04.240 --> 12:08.000]  And on the other side, I want to compare with what's the latest code version.
[12:08.000 --> 12:14.400]  And so if it does not match, then I know that I need to work on that at some point.
[12:14.400 --> 12:26.480]  And since I have a bit of a time, I can quickly show what the discovery looks like.
[12:26.480 --> 12:35.040]  Yeah, the auto-discovery is a bit more difficult because you need to know in advance what you
[12:35.040 --> 12:40.320]  want to do, but where is that thing?
[12:40.320 --> 12:43.160]  Yeah, this way.
[12:43.160 --> 12:47.320]  As you can see, we don't have a lot of support at this time, so it's mainly around containers
[12:47.320 --> 12:50.640]  because I'm working on containers most of the time.
[12:50.640 --> 12:53.320]  But so it will pass the file, so in this case, it identifies.
[12:53.320 --> 12:58.000]  It's a Rancher project where we have fleets, and then based on that, it will try to fetch
[12:58.000 --> 13:06.240]  all the different versions specified in the fleet project, and it will suggest other versions.
[13:06.240 --> 13:10.440]  So that's it for my presentation.
[13:10.440 --> 13:11.440]  And...
[13:11.440 --> 13:12.440]  Voila.
[13:12.440 --> 13:26.480]  Is there any questions?
[13:26.480 --> 13:27.480]  One time, two times, yes.
[13:27.480 --> 13:28.480]  There is one over there.
[13:28.480 --> 13:29.480]  Hi there.
[13:29.480 --> 13:30.480]  Thanks for the presentation.
[13:30.480 --> 13:42.240]  You were talking about what the Panda was, but you didn't mention about renovate.
[13:42.240 --> 13:47.840]  I wonder how much it overlaps with renovate, if it's a bit more customizable one.
[13:47.840 --> 13:52.360]  So the question, I mentioned the Panda, but I didn't mention that much renovate.
[13:52.360 --> 13:57.360]  So if you compare the Panda, but the renovate is way better than the Panda, but because
[13:57.360 --> 14:01.360]  the Panda, but I didn't have the time to cover the domain.
[14:01.360 --> 14:04.600]  There are a lot of things that I didn't have the time to cover, but for example, one of
[14:04.600 --> 14:08.400]  the features that I really love in renovate, but is they allows you to group PRs which
[14:08.400 --> 14:09.600]  reduce the noise.
[14:09.600 --> 14:13.720]  Because for example, the Panda bot, especially for those people maintaining JavaScript projects,
[14:13.720 --> 14:17.720]  the Panda bot can just open like 10, 20, 30 PRs, and then you have to review all of them
[14:17.720 --> 14:18.720]  tests.
[14:18.720 --> 14:21.000]  And so there are different strategies to update.
[14:21.000 --> 14:25.880]  Renovate bot is just way better in the way that it supports more modules.
[14:25.880 --> 14:32.720]  On the other side, it's not really easy in the case of renovate, but to have workflows
[14:32.720 --> 14:36.240]  where you really want to say, okay, I'll fetch a version, I'll check a bunch of things, and
[14:36.240 --> 14:40.440]  then I'll update other targets, basically.
[14:40.440 --> 14:45.880]  So I would say renovate bot is better in the autodiscovery part, where you can detect things
[14:45.880 --> 14:46.880]  for you.
[14:46.880 --> 14:56.360]  But on the other side, it's not really easy to have like very complex updates in areas.
[14:56.360 --> 15:01.960]  And that's it.
[15:01.960 --> 15:06.520]  So Charles, the floor, thank you.