Yeah, I think I will start, otherwise I would know I want to have, I mean, I like to talk
a lot, so I won't have enough time anyway.
So thanks for coming to my presentation, and today I'm going to talk about the challenges
of updating everything.
So my name is working.
I'm also one of the CI-CD Dev Room maintainer.
I'm working for Sousa on all things related to Kubernetes, Rensho.
So if there are anything you want to talk about, feel free to reach out after my presentation.
But today I'm not here to talk about what I'm doing at work.
And here to present a project that I started before joining Sousa, back then when I used
to work on Jenkins projects, and that project is named Update CLI.
So Update CLI is a common line tool that we use to automate things.
So the design is to run it on your machine, on the CI environment, whatever it is.
And so you specify in your manifest what's the update strategy would look like.
So initially I wanted to talk about, first, Update CLI, and then all the challenges that
you have when you want to automate Docker images, when you want to automate infrastructure
or whatever.
But I won't have the time to do that here.
So for those people in Ghent, for the configuration management camp, I will have more time over
there.
I will just focus on what Update CLI is, what the problem is, and what I'm trying to do.
So the challenge that I face is, quite often when I maintain large amounts of projects,
something that used to work, to not work anymore.
Like you are using Ugo, for example, to generate a website.
And then at some point, you cannot deploy the website anymore because even though projects
release a new Ugo version, they fail to build the published Docker image associated to that.
Or you would realize yesterday I was investigating an issue where Update CLI would deploy and
would roll back a version of the NGNX Ingress Controller, and then it ended up that the people
maintaining that container just released, deleted the release, forgot to remove the
GTIG in those situations.
So you would expect something to work.
You won't automate.
And the thing is, when you get in those situations, you try to understand why it didn't work.
I mean, it used to work for years, and then suddenly it doesn't work anymore.
And then so you spend time trying to understand what's the latest version, what's the changelog,
what's something failed, basically.
And so when you want to automate those updates, so you don't have to pay attention to them,
I mean, it obviously has benefits, right?
I'm curious.
Who's using, for example, Tip and Abut or Renovate about to automate things, updates?
Yes, a few people.
It's only the start.
But once you start automating things, you know that, obviously, it gets easier to change
your project infrastructure documentation, no matter what, because you get confident
in the change that you want to do.
And in my case, most of my projects are hosted on Git repositories.
And one of the challenges when you have, when you think about those Git repositories is everything
is a file.
And what you try to do is you try to automate them, but most of the time you have no idea
what you're trying to update, right?
So for example, Dependabut will just look at a package of GZN.
So if you find a package of GZN, we'll list all dependencies and try to update them one
by one.
But on the other side, for those people using, for example, random GZN file, there is no
way to know in advance what should be updated in those files.
And then you have all those middle grounds, like, for example, for those people familiar
with Dockerfile, you have some instruction that you can automatically update, like the
from instruction.
It's pretty straightforward to know what you need to update.
You don't know what you want to update.
That's a different story.
But the thing is you know that you want to automate the base image.
On the other side, you can put pretty much every information in the run instruction,
the label, the end instruction, and that's where things get difficult.
So when we started working on a data line, we wanted to think, OK, we want to automate
everything.
So we want to define where the information is coming from, what are the conditions to
automate the thing, and finally, what should be the state of your file on your Git repository.
So if I go back to my ego example, the idea is the source of information is the latest
ego release.
That could be the Git tag, that could be the latest Docker image published, that could
be the GitHub release, for example.
But at some point, we have to decide what's the source of truth for that specific application.
And then you have, like, a bunch of conditions that you want to apply, like, does it make
sense to bump the version in production if you fail to bump the version in the dev environment?
So you want to be sure that you are using the same version everywhere.
And only then, you will bump all the files related to that version.
And so when we come back about Update CLI, the idea is we specify a manifest, we have
to write a manifest.
So that's the main difference, for example, for Dependable.
Because Dependable, you just enable the button, it works.
But it will only detect what it can detect.
But most of the time, you have no idea what you should update.
With Update CLI, we went the other way.
We write a manifest, so for example, this one is you have the source, the source of
truth.
In this case, it's a GitHub release.
So it can GitHub release.
And then you have the specification, where you provide all the parameters for that specific
project.
So in this case, I am monitoring the go-go-io git repository.
This one gives me a version, let's say 100.
That's the latest one.
And what I want to do is I want to be sure that all my files, named natify.tom.yml, are
up to date.
So I look at the key.
And then if I run this manifest on my machine, it will just dump the file on my machine.
If I run this manifest on the CI environment, it will bump the file in the CI environment.
And so the next step is, okay, that's one thing to have it working on a machine.
But then you also want to be sure that your git repository is up to date and don't pay
attention to them.
So you can just focus on what really makes sense in your case.
And so the next step is, okay, we want to specify where that file is located.
So we have a bunch of other resources.
In this case, it's a SCM of type git, because I want to update git repositories.
And then I specify that I want the pull request approach, where I create a temporary branch
and then someone can review my change.
And then when you think about all those building blocks, you can really have, like, more advanced
scenarios, like this one is another project that we use, where we use it, is when someone
really is in a new version of Apno, we use GitHub Action there.
That send a bunch of release events automatically to other git repositories.
And those git repositories will trigger Update CLI.
So Update CLI will retrieve all the different information.
So for example, on Apno slash docs, which is obviously the website, we retrieve the latest
version of Apno, and then we check that all the download links are up to date.
We check that we have the version for that specific website.
So we maintain one documentation per major and minor version.
So we try to be sure that those files are up to date.
And if it's not the case, we open a PR.
And then as part of the release process of Apno, someone needs to review the PR and double
check that it still contains a file that you want to have there.
Another example is the way we automate Hemshot.
We define, okay, we are monitoring the Apno UI, which is a front application, and we monitor
the backend, the Apno.
And then if for some reason there is a new version, then it will automatically bump the
Hemshot, bump the metadata, and so on.
And once again, we have a human validation where someone can just come, look at the PR,
and decide if we want to go one step further.
So really briefly here is when automated update is not a so easy challenge, as I initially
thought, because so we split the project in three different categories.
So the first one is declarative.
So the idea is you know in advance what should be updated, and so you define in a manifest
how you want to update something, because it's not something that you can define in
advance.
The other discovery is a bit more like for those people familiar with Dependentbot or
Renovatebot, you just run the command and you ask it to automatically detect what could
be updated.
There are scenarios where you can find that information.
For example, on a Maven project, you have the pump.xml, you fetch all the dependencies
and update them.
That's pretty easy.
On other projects like Docker containers, it's kind of a mess over there, so it's super
difficult to know what should be the next version.
And then on the other side, you have all those situations where you specify a constraint,
a version constraint, like you don't want to use a version bigger than the 1.0, but
at some point the project upstream is like way further than you are in your project.
At some point, you need to be aware that you will need to plan some work to catch up
on the upstream project.
And so that's another experiment, which is update monitor.
So I want to do a quick demo.
I don't have good internet connectivity here, so I hope it will work.
So on the left side is one of the manifest, is it big enough?
Oops.
So on the left side, we specify a few things like, okay, in this case, we want to enable
the auto merge feature of GitHub, actually, of GitHub PolarQuest.
We specify labels.
So we automatically open a PR, and if all the tests are passing, it will merge the
PR automatically.
And so I don't have to pay attention, which reduce, obviously, the noise introduced by
those PR.
We need to specify which projects we want to go.
So in this case, that's the updated website.
And finally, we specify where the information is coming from.
So this one, we monitor, go, go, go, go.
As I said, we could have instead of monitoring the GitHub release, at some point I could
have said, okay.
I just want to monitor the Docker images.
But in that case, I just need to provide a different piece of information.
Or you could say, for example, I want to monitor here, writing from the IDD is the easiest
way.
You can specify different ways of filtering version, because what's something that we
notice, for example, is when I said the Docker ecosystem is a mess, is you can put whatever
information you want in a tag.
So there is pretty much no way, I mean, most of the time, there is no way to know what
should be the next version.
Then depending on the registries, they don't return you the latest version, because they
don't sort the tags in the same way.
So at some point, yeah, you need to enforce a specific behavior.
And then the target in this case is, if there is a new version of Hugo, we want to be sure
that the workflow file has the correct version and that the native file is up to date.
So I don't care.
And so what it looks like on the other side is just a CLI, as I said.
So you can read it from my machine, Linux, Mac, wherever you want to run it.
And then, voila, you get the latest version, change log, depending on the situation.
And based on that, you can just combine the projects.
And so we have a lot of different workflows where we automate things.
The last thing, how many time do I have left?
Five minutes?
Okay.
Where is that?
It's not this one.
So the thing that I was mentioning for monitoring the different versions, so this one is a different
way to see the problem is you want to monitor the version that you are using at some point.
And so you want to compare, okay, in this case, on one location, I say I want to monitor
a version from the native file.tamiaml, so it gets me a version which is 0.1010.
And on the other side, I want to compare with what's the latest code version.
And so if it does not match, then I know that I need to work on that at some point.
And since I have a bit of a time, I can quickly show what the discovery looks like.
Yeah, the auto-discovery is a bit more difficult because you need to know in advance what you
want to do, but where is that thing?
Yeah, this way.
As you can see, we don't have a lot of support at this time, so it's mainly around containers
because I'm working on containers most of the time.
But so it will pass the file, so in this case, it identifies.
It's a Rancher project where we have fleets, and then based on that, it will try to fetch
all the different versions specified in the fleet project, and it will suggest other versions.
So that's it for my presentation.
And...
Voila.
Is there any questions?
One time, two times, yes.
There is one over there.
Hi there.
Thanks for the presentation.
You were talking about what the Panda was, but you didn't mention about renovate.
I wonder how much it overlaps with renovate, if it's a bit more customizable one.
So the question, I mentioned the Panda, but I didn't mention that much renovate.
So if you compare the Panda, but the renovate is way better than the Panda, but because
the Panda, but I didn't have the time to cover the domain.
There are a lot of things that I didn't have the time to cover, but for example, one of
the features that I really love in renovate, but is they allows you to group PRs which
reduce the noise.
Because for example, the Panda bot, especially for those people maintaining JavaScript projects,
the Panda bot can just open like 10, 20, 30 PRs, and then you have to review all of them
tests.
And so there are different strategies to update.
Renovate bot is just way better in the way that it supports more modules.
On the other side, it's not really easy in the case of renovate, but to have workflows
where you really want to say, okay, I'll fetch a version, I'll check a bunch of things, and
then I'll update other targets, basically.
So I would say renovate bot is better in the autodiscovery part, where you can detect things
for you.
But on the other side, it's not really easy to have like very complex updates in areas.
And that's it.
So Charles, the floor, thank you.