Pour trouver d'autres logiciels qui t'aident dans ces tâches que les deux que tu proposes, cherche des outils de continuous integration ou continuous delivery (soit CI/CD en combo, car souvent l'un va avec l'autre). Dans mon expérience le logiciel qu'on utilise importe peu: il faut qu'il soit simple, facilement maintenable par l'équipe (en particulier stable) et extensible (par exemple: peut lancer un script shell) mais si ces conditions sont remplies alors peu importe.
Donc GitLab, Jenkins, GoCD, Concourse, etc. marchent, des trucs propriétaires à l'infra gérée comme GitHub Actions, Circle CI, ou Travis CI peuvent aussi être intéressants à examiner même si je ne recommande pas leur utilisation.
Dans les choses que font bien ces logiciels il y a:
Réagir à un évènement (git push, cron)
Lancer un programme en réaction (terraform, compilateur, analyse statique de code, tests, etc.)
Mettre des credentials à disposition de ces programmes.
Stocker des fichiers (éventuellement download/upload).
Avec ça on peut facilement créer des chaînes de CI/CD.
Ce qui distingue entre eux ces logiciels sont les aspects de type:
Est-ce que le journal des évènements et programmes lancés est constant (pas modifiable).
La gestion des secrets.
La possibilité de combiner les tâches en enchaînements plus ou moins complexes.
La possibilité de redémarrer les tâches qui ont planté.
La possibilité de consulter des métriques (notamment "cycle time")
Tous ces logiciels ont plein de fonctions (ou plugins) largement inutiles:
- Gestion des schémas de base de donnée
- Plugins ansible
- Plugin kubernetes
- Plugin ...
Pour la base de données, il vaut mieux gérer ça dans la couche logicielle que dans le système de déploiement: la fonction est presque certainement incluse dans l'interface BDD du logiciel et il y a presque toujours des connaissances "buisness logic" importantes pour les migrations de schéma... c'est une très mauvaise idée d'éparpiller ces connaissances à divers degré du projet. Donc on zappe le fonctions "BDD" des outils CI/CD – qui de toutes façons sont trop compliqués et pas assez flexibles, donc aucune plus-value.
Pour les plugins ansible, kubernetes, etc... il faut s'en passer. La raison est que même si le système CI/CD est en rade, il faut pouvoir déployer, tester, etc. donc toutes ces tâches doivent être implémentées par des programmes dispos dans le repo du projet (typiquement dossiers development et operation). Au final, on se retrouve avec très peu de logique dans le système de CI/CD... et c'est tant mieux, comme ça c'est facile d'en changer!
# Méthodologies plutôt que des logiciels
Posté par Michaël (site web personnel) . En réponse au message Équivalent de XL Release et XL Deploy. Évalué à 5.
Pour trouver d'autres logiciels qui t'aident dans ces tâches que les deux que tu proposes, cherche des outils de continuous integration ou continuous delivery (soit CI/CD en combo, car souvent l'un va avec l'autre). Dans mon expérience le logiciel qu'on utilise importe peu: il faut qu'il soit simple, facilement maintenable par l'équipe (en particulier stable) et extensible (par exemple: peut lancer un script shell) mais si ces conditions sont remplies alors peu importe.
Donc GitLab, Jenkins, GoCD, Concourse, etc. marchent, des trucs propriétaires à l'infra gérée comme GitHub Actions, Circle CI, ou Travis CI peuvent aussi être intéressants à examiner même si je ne recommande pas leur utilisation.
Dans les choses que font bien ces logiciels il y a:
Avec ça on peut facilement créer des chaînes de CI/CD.
Ce qui distingue entre eux ces logiciels sont les aspects de type:
Tous ces logiciels ont plein de fonctions (ou plugins) largement inutiles:
- Gestion des schémas de base de donnée
- Plugins ansible
- Plugin kubernetes
- Plugin ...
Pour la base de données, il vaut mieux gérer ça dans la couche logicielle que dans le système de déploiement: la fonction est presque certainement incluse dans l'interface BDD du logiciel et il y a presque toujours des connaissances "buisness logic" importantes pour les migrations de schéma... c'est une très mauvaise idée d'éparpiller ces connaissances à divers degré du projet. Donc on zappe le fonctions "BDD" des outils CI/CD – qui de toutes façons sont trop compliqués et pas assez flexibles, donc aucune plus-value.
Pour les plugins ansible, kubernetes, etc... il faut s'en passer. La raison est que même si le système CI/CD est en rade, il faut pouvoir déployer, tester, etc. donc toutes ces tâches doivent être implémentées par des programmes dispos dans le repo du projet (typiquement dossiers
developmentetoperation). Au final, on se retrouve avec très peu de logique dans le système de CI/CD... et c'est tant mieux, comme ça c'est facile d'en changer!