Garbage Collector

The little space of a writer, tinkerer, and a coffee addict

Manage your project documentation as Code

- 15 minutes read time

As an architect, the main product I deliver is a document named “Technical Architecture Document”. This document is basically a high level specification (not because it’s rocket science, it’s just a detailed global perspective) explaining how a software project will be implemented with the rest of the information system. And in most of the case, the template for this document is an Office suite-related document type such as a Microsoft Office document, or anything else.

What is GitOps ?

- 11 minutes read time

In my experience with the software delivery chain, we talk a lot about how the software is produced and delivered, but when it comes to make it live, the topic is less studied. Maybe that’s because the deployment is situated in the “Ops” domain of the DevOps timeline while the software production is on the “Dev” side. And we usually like to focus on Dev and less on Ops I suppose. Since I’ve mainly worked in the deployment part, I think it’s a very interesting topic because it’s one of the best examples to demonstrate how well the DevOps culture is implemented in a team or not. And one of the best examples in my opinion is the GitOps practice.

Terraform your CICD Toolchain : SonarQube

- 3 minutes read time

So, in the previous article we’ve Terraformed GitHub (that must hurt), so let’s continue with another tool commonly used in a CICD process : SonarQube.

For a brief introduction in case you don’t know this tool, SonarQube (or SonarCloud for its SaaS version) is an open-source software published under LGPL v3 made for Static Code Analysis having both free and paid Enterprise plans. Basically, SonarQube will analyse the source code, use a big set of rules associated to the language, and throw issues if it found bugs, regressions, security hotspots, duplicated code lines, code test coverage, or code smells. Code smells are more optimization or cleanup opportunity than actual bugs, for example : remove commented code, remove unused imported library, etc.

Terraform your CICD Toolchain : GitHub

- 6 minutes read time

When you’re running and managing the CICD Toolchain of a big organization, you may want to establish some conventions and usage rules to avoid having to manage a big inconsistent mess. One possibility to avoid this, after you had established your various naming conventions and usages, is to use Terraform to maintain all of the objects constitutes your application projects.

act for testing Github Action locally

- 7 minutes read time

Following my previous article about GitHub Actions, here is a new one that will explain how to locally test your Actions. Unlike the good old Jenkins on which you can copy/paste your pipeline code in a test job and run it (that’s dirty but it works), GitHub Actions requires to always commit and push your changes and wait for the runner to take it. When you’re like me and using a die and retry development process, it’s a waste of time.

Blog avec Hugo et publication automatisée

- 8 minutes read time

Après avoir mis en place mon nouveau blog avec le générateur Hugo, il m’avait fallu voir comment automatiser la publication. En effet, Hugo génère dans un dossier public/ les pages web statiques et celles-ci doivent être déposées sur un serveur web pour les présenter. Voici donc ce que j’ai construit rapidement pour qu’une publication soit aussi simple qu’un git commit; git push.

Ansible : Utiliser ses API avec Python

- 3 minutes read time

Ansible : Utiliser ses API avec Python

Depuis quelques temps j’ai enfin trouvé des idées de petits outils à développer avec Python pour pouvoir apprendre à manipuler ce langage.

Utilisant beaucoup Ansible de manière professionnelle (je vous invite à lire la serie de billets écrite à ce sujet si ce n’est déjà fait), et celui-ci étant développé en Python, je m’appuie dans notre contexte sur nos inventaires pour fournir diverses informations à d’autres systèmes ou encore à des utilisateurs.

Ansible - Quelques bonnes pratiques

- 5 minutes read time

Et voici le dernier article de cette série consacrée à l’outil de déploiement Ansible. Vous y trouverez essentiellement des ressources utiles, bonnes pratiques acquises avec l’expérience, etc.

Bonnes pratiques et ressources

Quelques bonnes pratiques

La documentation officielle Ansible en propose une très bonne liste. Nous allons en reprendre quelques unes ici. J’ajouterai également celles apprises avec l’expérience.

Ansible - Les rôles

- 8 minutes read time

Pour cette quatrième partie, nous nous intéressons aux rôles Ansible.

Les rôles Ansible

Les rôles partagent de nombreux points communs avec les playbooks. En effet, ils utilisent les mêmes instructions et le même code déclaratif. La principale différence est qu’il s’agit d’un ensemble structuré de fichiers et de dossiers qui contiendront chacun une liste d’action précise.

Ansible - Un premier playbook

- 5 minutes read time

Troisième partie consacrée à l’outil Ansible, nous allons attaquer l’écriture et l’exécution de playbooks.

Un premier playbook

Nous avons pas mal parlé des exécutions ad hoc d’Ansible permettant de lancer unitairement un module et obtenir le résultat. Les Playbooks ont pour intérêt d’écrire un scénario complet d’exécution de plusieurs modules avec des conditions et des critères de succès/échec et des actions selon l’évènement déclenché. Les playbooks sont écrits en YAML et utilisent un langage déclaratif simple propre à Ansible.

Ansible - L'Inventaire

- 6 minutes read time

Deuxième partie de la série consacrée à Ansible. Cette fois nous parlerons plus en détail de l’inventaire, à quoi ça sert, comment l’organiser, comment l’exploiter, etc.

L’inventaire Ansible

L’inventaire est la liste de hosts qu’Ansible est capable de gérer. Il peut se définir de deux façons : sous forme INI ou bien en YAML. L’inventaire par défaut est celui situé dans /etc/ansible/hosts, mais celui-ci peut être un fichier appelé à la volée.