Buddy Works

Un pipeline est l'unité de travail dans Buddy, et vous le construisez de deux façons. L'éditeur visuel vous laisse glisser des actions dans une chaîne et fixer leur ordre, tandis que la vue YAML expose la même configuration sous forme de texte. C'est de l'automatisation de build que vous pouvez lire. Les changements faits dans l'un apparaissent dans l'autre, l'approche visuelle n'exclut donc personne de ceux qui préfèrent une configuration versionnée. Choisissez celle qui convient à votre équipe.

Chaque build tourne dans un conteneur isolé, ce qui tient les dépendances d'un projet à l'écart de celles d'un autre. Vous pouvez choisir des environnements Intel, ARM, Linux, Windows, Mac ou NixOS, et les étapes peuvent tourner en matrice, toutes en même temps ou une par une. Cela compte quand vous devez tester le même code sur plusieurs plateformes avant la release. Pas de mauvaise surprise liée à un état partagé.

Les actions de déploiement publient vers une longue liste de cibles, dont des fournisseurs cloud, des VPS et du bare metal. L'automatisation des déploiements cesse donc d'être un script que vous maintenez à la main. Il existe des modes avec et sans agent, des déploiements conscients des changements qui n'envoient que ce qui a bougé, des approbations manuelles pour les releases verrouillées et un rollback en un clic si une release tourne mal. Pour les équipes qui déploient souvent, le bouton de rollback mérite à lui seul sa place. Buddy peut monter un environnement neuf pour chaque branche, pull request, stage ou démo. Ils tournent sur le cloud de Buddy ou dans votre propre infrastructure si vous utilisez bring-your-own-cloud. Chaque PR et chaque branche obtient sa propre URL, les testeurs et les clients peuvent donc voir un build en direct sans attendre un serveur de staging partagé. Pratique pour les revues.

Les actions de déploiement publient vers une longue liste de cibles, dont des fournisseurs cloud, des VPS et du bare metal. L'automatisation des déploiements cesse donc d'être un script que vous maintenez à la main. Il existe des modes avec et sans agent, des déploiements conscients des changements qui n'envoient que ce qui a bougé, des approbations manuelles pour les releases verrouillées et un rollback en un clic si une release tourne mal. Pour les équipes qui déploient souvent, le bouton de rollback mérite à lui seul sa place.

Les outils de revue visuelle lancent des tests d'interaction et des tests visuels sur différents navigateurs, systèmes et viewports en même temps. Vous pouvez les brancher sur Playwright, Selenium ou Cypress, et Buddy garde une référence pour signaler ce qui a réellement changé. Le support de Figma et Storybook permet de vérifier les changements de design contre l'interface réelle. Fini les suppositions.

Au-delà du CI/CD, Buddy regroupe des briques réseau et d'hébergement. Les tunnels se connectent à des réseaux externes avec une protection OAuth, SAML ou OIDC, les domaines gèrent les applis multi-tenant avec des certificats SSL automatisés, et le cloud de développement exécute des applis sur des MicroVM directement depuis un pipeline. Cela fait beaucoup de surface, et c'est le but : moins de comptes séparés à gérer. Moins de pièces mobiles.

Vous pouvez piloter toute la plateforme depuis l'interface, l'API, une CLI, Terraform ou YAML. Cette souplesse explique pourquoi les équipes de plateforme la choisissent : l'infrastructure peut être définie comme du code et relue comme n'importe quel autre changement, et les pipelines peuvent être générés par programme plutôt que cliqués à la main. Faut-il la choisir plutôt qu'un simple service de CI ? Cela dépend de la part de la chaîne de livraison que vous voulez réunir au même endroit.