Thank you for being here. We are going to talk about our journey from Jenkins to Github actions.
Benoît & Rémi
Rémi
Benoît
Benoît
I made a talk 3 years ago about how we deployed our instances. We still used the same process, but no more the same tools
The main difference compared with 2022, it's github actions do not exists in 2015 when we started using Jenkins
Benoît
With our old Jenkins server, we had a single physical server
It was very old and deploy, at the begining, with our infrastructure as code, Puppet
But over the years and new verison of puppet, it was no more synchronized with your puppet code beacause of, basically, plugins
Also, for convenience, everybody was admin
I was the only one who maintained the server
Rémi
When we told our sysadmins that we were doing a talk about Jenkins,
Here was the reply of Cédric...
Rémi
This brings us to the next slide about why migrate ?
Rémi
We had 2 obviouses choices. Github actions or gitlab-ci
Benoît
So in 2021 we started to use github actions on some repo for testing our code, as the community.
in 2024, we have Jenkins, GHA and gitlab-ci in our infrastructure, we choose to remove one of these 3 ... This is the beginning of the end of Jenkins
In June, we made an inventory of all Jenkins pipeline based on groovy
In July, we deployed docker based runner on your fresh new Kubernetes cluster and we create a central GHA repo
In Augustus, we had Jenkins and gihub actions works in //. But gha do not deploy anything
In septembre, we made the switch and we decommission Jenkins
It was a quick migration, only 3 months
Benoît
One of the big part was to verify if our "old" deployement steps was still used and suits to our needs. We have some questions to ask to ourself
Rémi
keep workflows thin and easy to understand
Rémi
We are hosting ourselve the runners and orchestrating them with the
action runner controler, so we can benefit from auto-scaling, and so on
Benoît
We have now 3/4 differents actions runner images used depending on our needs
One with for Plone with all battery included, I speak about library
One other to ...
Benoît
Here we see what dev have to understand to deploy on app.
We choose to use zest.releaser because we work with this package to release our eggs, so dev know and use often zest.releaser
Benoît & Rémi
Same as Jenkins:
- Staging: every merge to `main` auto-deploys to staging instances (copy of some prod instances)
- Prod: only annotated tag on `main` + schedule (3 AM next day)
- Rollback: git tag revert + redeploy (immutable images retained) (! Database)
Rémi
As you saw on the demo, the last step is often a call to a rundeck job.
This allows us to make operations needed to promote a new app version like images pull, instances reboot and so on.
FYI, it will be deprecated when we will migrate to kube.
Rémi
During the process, we kept an eye to observability, with things like mattermost notifications, actions logs, plone logs, and so on.
Benoît
One week before the end of migration, one disk crash on your old OVH server (11 years) not able to recover