Avoir son Gitlab Runner rien qu'à soi
Gitlab propose une fonctionnalité d’intégration continue qui utilise des “Gitlab Runners”.
Il s’agit en fait de process qui vont s’occuper de faire tourner toutes les tâches utiles pour la CI tout en étant détachés de la plateforme Gitlab elle-même.
De cette manière, la charge n’est pas portée par la forge logicielle elle-même et peut même être mise en place sur un serveur dédié (ce qui est recommandé).
Un même serveur peut héberger plusieurs runners, chacun pouvant avoir une tâche particulière (un runner pour les projets Java, un pour les projets Ruby, etc).
20 Aug 22 15:09 +0200
-
5 min read
03 - Pourquoi ces choix ?
Alors, je vous ai présenté à peut près toute la stack technique, mais je n’ai pas expliqué le pourquoi.
Je vais essayer de le faire tout en restant le plus concis possible.
Concernant l’IDE, je pense que le post précédent donnait assez d’explications.
La base de données Pour une architecture aussi simple et fortement relationnelle, un SGBDR me semblait tout indiqué. Donc, une technologie SQL.
Pour une petite application, il ne restait donc plus que MariaDB et PostgreSQL.
18 Apr 21 16:15 +0200
-
3 min read
02 - Les choix techniques
Pour démarrer ce projet, il a fallu commencer par choisir soigneusement les différents composants que je pensais utiliser.
J’ai essayé d’utiliser au maximum des composants libres et Open-Source ou alors présentant une alternative simple à mettre en oeuvre.
Il y a donc :
L’IDE
La base de données
Le framework pour le Front End
Le framework pour le Back End
L’hébergement des sources
Le choix de l’IDE Travaillant depuis des années avec l’excellent IntelliJ IDEA édité par Jetbrains, c’est tout logiquement que j’ai décidé de l’utiliser.
17 Apr 21 13:48 +0200
-
2 min read