- 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.
- 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.
- 9 minutes read time
This may sound a little incongruous if for you the Continous Integration / Continuous Delivery patterns are for software development, but yes, you can maintain a book with the same principles. Recently, I’ve compiled the Linux Explained articles into an e-book.
- 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.
- 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.
- 6 minutes read time
Some months ago, I’ve made a series of articles about the misbrands, a collection of brands logos derivations that put a name onto the logo of a competitor product. They were really fun for me and I’ve put some on my work laptop.
- 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.
- 6 minutes read time
GitHub Actions is a Continuous Integration, Delivery, and Deployment workflow manager made by the code repository hosting service GitHub. GitHub was a little late in the CI/CD pipeline management compared to its competitor GitLab and the good old Jenkins. After a beta testing period, the service opened in 2018.
- 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.
- 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.
- 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.
- 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.
- 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é.
- 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.
- 13 minutes read time
Changeons de sujet par rapport à mes précédents articles. Travaillant dans le domaine de l’intégration et déploiement continu (CICD), j’ai eu envie de faire découvrir des outils que j’utilise au quotidien. Le premier est Ansible, un outil de déploiement que j’affectionne particulièrement.