EDIT: This article is slitghly outdated as the workflow I use to maintain this website has evolved and improved over time. I’ll eventually write a V2 of that article at some point.
-This website is built with the HUGO static website generator using the anatole theme.
-The website’s source code is hosted in this GitHub repository.
I make my changes (e.g. creating an new article, update the theme, add new parameters to the website, etc…) locally on my computer inside the git repository in the dev branch.
+Every changes I made (e.g. creating a new article, update the theme, add new parameters to the website, …) are done in my local git repository on the dev branch.
+Once the changes are pushed to the above GitHub repository, I create a pull request from the dev branch to the main one, which triggers CI / CD pipelines (which run on my own self-hosted runners):
[...]
Read MoreEDIT: This article is slitghly outdated as the workflow I use to maintain this website has evolved and improved over time. I’ll eventually write a V2 of that article at some point.
-This website is built with the HUGO static website generator using the anatole theme.
The website’s source code is hosted in this GitHub repository.
To manage this website, I use an automated CI / CD workflow:
+I make my changes (e.g. creating an new article, update the theme, add new parameters to the website, etc…) locally on my computer inside the git repository in the dev branch.
+Every changes I made (e.g. creating a new article, update the theme, add new parameters to the website, …) are done in my local git repository on the dev branch.
+Once the changes are pushed to the above GitHub repository, I create a pull request from the dev branch to the main one, which triggers CI / CD pipelines (which run on my own self-hosted runners):
I make my changes (creating an new article, update the theme, add new parameters to the website, etc…) locally on my computer inside the git repository in the dev branch.
-Once the changes are done, I push them to the GitHub repository and I create a pull request from the dev branch to the main one, which triggers a CI pipeline:
This CI pipeline is divided into two jobs:
-
The CI pipeline has one “Test” stage which, as the name implies, runs a bunch of tests (e.g. spellcheckers & linters):
+
The CD pipeline has two stages:
+
The build job automatically builds the website against the new changes I made and, if the build succeeds, it automatically pushes the built website to the dev branch (and thus, add it to the current merge request).
+The “Build” stage builds the website via hugo and then commits the built changes to my repository (still on the dev branch).
The test job automatically runs a bunch of tests / linters against the website’s files in the repository, to make sure the changes I made are correctly written / syntaxed.
-Once both of the above CI jobs succeeded (meaning the website has been successfully built, pushed to the dev branch of the repository, and the tests went through without any error), I launch a job on my Jenkins server targeting the dev environment *(edit: the trigger of that job is now automated via GitHub actions as well):
-
This Jenkins job runs a simple Ansible playbook (see that playbook here) that aims to update the website’s sources on the targeted environment against the related GitHub branch (dev branch –> development environment, main branch –> production environment):
-
I can then review what my changes on my development environment.
-Once the changes have been reviewed and declared “ready” to go to production, the only thing I need to do is to merge the changes to the main branch on the GitHub repository and relaunch my Jenkins job, targeting the “prod” environment this time, so the changes are pushed against the main branch to the VPS which hosts this website:
-
This workflow aims to evolve and be improved over time but it’s a good example of a simple; yet effective, flexible and reliable automated CI / CD workflow you can use to manage your projects! 😄
+Once the “Build” stage has finished successfully, the “Deploy” stage is triggered.
+
It allows to automatically deploy the website by remotely triggering the related job on my Jenkins server for my website deployment. This Jenkins job can either target my dev or prod environment (the former being hosted on a virtual server in my homelab, the latter being hosted on a VPS), thanks to a dedicated parameter.
Under the hood, this Jenkins job runs a simple Ansible playbook (see that playbook here) that aims to update the website’s sources on the targeted environment against the related GitHub branch (dev branch –> development environment, main branch –> production environment).
When opening a pull request from the dev branch to the main branch, the “Deploy” stage of my GitHub CD pipeline automatically triggers the related Jenkins job (which itself triggers the related Ansible playbook) targeting my dev environment, so my changes gets automatically deployed and I can review them on my development environment.
Once I reviewed the changes on my development environment and they are ready to go to production, I can just merge the pull request to the main branch which will trigger a new run of the CD pipeline with the “Deploy” stage targeting the prod environment this time!
This workflow may evolve and be improved over time but it’s a good example of a simple; yet effective, flexible and reliable automated CI / CD workflow you can use to manage your projects! 😄
I contribute to many open source projects and I’m always willing to help, share and learn in the process!
Here are the main projects I actively contribute to:
Arch Linux is a lightweight and flexible Linux distribution that focuses on simplicity, modernity, pragmatism, user centrality and versatility.
Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox.
Arch-Update is an update notifier & applier for Arch Linux that assists you with important pre / post update tasks.
It has various features such as a clickeable systay applet & an automated check for update, and is designed to follow usual system maintenance steps, as described in the Arch Wiki:
It offers to read latest Arch news before updating the system, offers to remove orphan & old cached packages, to process pacnew files, to restart services that need a post upgrade restart, it checks for pending kernel updates requiring a reboot to be applied, etc… It optionally supports AUR & Flatpak packages as well as desktop notifications.