Forum général.cherche-logiciel Équivalent de XL Release et XL Deploy

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
0
8
sept.
2021

Salut,

Quelqu'un connaîtrait-il un équivalent des logiciels XL Release et XL Deploy de Digital.ai (anciennement XebiaLabs) en logiciel libre ou Open Source (même avec moins de fonctions).

Si vous ne connaissez pas des 2 logiciels :
- XL Release : permet de gérer les étapes d'une release. On définit des phases (par exemple : Build, Test, Recette, Prod), puis on définit les étapes pour chaque phase.
Par exemple, pour Build : si on commit sur git avec un tag de n° de version (ou sur la branche Release - mais je ne suis pas fan de l'utilisation de branche Release … cependant c'est une autre histoire), on déclenche un build Jenkins, à l'issue du build, un fichier dar est généré pour être utilisé par XL Deploy.
La phase de Test contient une étape de déploiement sur l'environnement de test par XL Deploy puis on peut lancer des tests (unitaires, et Selenium).
L'intérêt de XL Release est aussi de pouvoir ajouter des étapes avec une intervention humaine : comme un test utilisateur pendant la phase de recette (et le testeur vient cliquer pour dire que le test est OK ou pas), un Go/No Go avant la mise en Prod etc.
- XL Deploy : permet de déployer une application associée à un numéro de version sur plusieurs environnements. L'avantage c'est de pouvoir facilement upgrader de version : seule la différence entre les versions est effectuée … mais aussi downgrader : on peut revenir à une version d'application précédente.

Bref, ce n'est pas pour faire de la pub pour ces produits mais je n'entends parler que d'eux. Je suppose qu'il y a des équivalents au moins commerciaux mais je ne les ai pas trouvé, c'est toujours sur ces 2 que je tombe.

Merci d'avance pour votre partage.

  • # GitLab ?

    Posté par  (Mastodon) . Évalué à 7.

    Salut,

    J'utilise un gitlab installé dans mon infra de boulot, et je peux y générer les étapes que tu décris par "CI": Continuous Integration.

    Je crée un fichier .gitlab-ci.yml à la racine de mon repo, dans lequel je déclare mes étapes de lint / tests / build, il est déclenché à chaque commit. Si il y a un tag (une release), je peux faire des trucs différents: par exemple déployer une package sur pypi…

    Il y a aussi la notion d'artifact, qui te permets de récupérer une archive, par exemple un truc déployable.

    Je ne suis pas fan de la branche "release", les développements sont sur une branche "develop" et les tags sont dans "master". J'utilise gitflow pou gérer les features / release / bugfix…

    Courage !

    • [^] # Re: GitLab ?

      Posté par  . Évalué à 4.

      pour compléter, la notion de satellite sur XL* est implémenté dans les gitlab-runner sur Gitlab.

      • [^] # Re: GitLab ?

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 11 septembre 2021 à 17:32.

        J'ai aussi utilisé GitLab pour faire des builds et de l'intégration continue : c'est fait pour ça et ça le fait bien (j'ai même une démo vidéo en préparation).
        J'ai même utilisé GitLab pour faire du déploiement.

        Mais ce que fait bien XL Release et que fait beaucoup moins bien GitLab c'est de gérer l’enchaînement de phases et de tâches dans les phases. Avec certaines tâches qui sont automatisés (déclencher des build ou des déploiements) et d'autres qui sont manuelles (et ça GitLab ne l'a pas par défaut) pour indiquer qu'on a bien effectué telle ou telle tâche ou qu'on a l'autorisation.
        De plus, ce que permet XL Release c'est d'affecter telle ou telle tâche à une personne ou à un groupe : la tâche pour autoriser est complété par des managers, la confirmation de déploiement en PROD par des Ops !
        Enfin, XL Release permet également de conserver l'historique du pipeline pour visualiser un enchaînement passé. Il permet également de modifier l’enchaînement des tâches (pour une release) tout en laissant le modèle (template) intact.

        Bref, GitLab est un super outil mais il ne fait pas ce que fait XL Release (et réciproquement).

  • # Méthodologies plutôt que des logiciels

    Posté par  (site web personnel) . É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:

    • 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!

    • [^] # Re: Méthodologies plutôt que des logiciels

      Posté par  (site web personnel) . Évalué à 1.

      Chacun ses idées sur les plugins dans les outils de CI/CD : je ne te rejoins pas du tout la-dessus.

      Cependant, les outils dont je parle XL Release & XL Deploy ne sont pas des outils de CI/CD, il utilisent des outils de CI/CD (typiquement Jenkins ou Gitlab).

      Merci quand même.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.