Devriez-vous utiliser les actions GitHub ou un serveur de build auto-hébergé ?

GitHub Actions est une plate-forme CI/CD qui permet aux développeurs de créer, tester et déployer automatiquement des applications sur GitHub, sans utiliser d’outils externes. Avec sa facilité d’utilisation, avez-vous même besoin d’un serveur de build externe ?

Actions GitHub

Cependant, ils sont généralement compliqués à configurer, c’est là que GitHub Actions offre une alternative aux codeurs de tous les jours. C’est beaucoup plus simple et souvent gratuit pour la plupart des utilisateurs, et bien qu’il s’agisse d’un outil gratuit, il résiste aux solutions propriétaires, en particulier avec les mises à jour récentes et le support de la communauté.

La configuration en un clic et la facilité d’utilisation de GitHub Actions en font un excellent outil d’entrée de gamme pour apprendre l’automatisation de la construction, d’autant plus que vous n’avez pas à configurer vous-même toute l’infrastructure pour commencer, et vous n’avez pas besoin de votre propres serveurs fonctionnant 24h/24 et 7j/7 pour gérer les builds.

La plupart des types d’applications auront des modèles déjà créés, ce qui signifie que la création automatique de votre application est généralement aussi simple que de cliquer sur l’onglet « Actions » de votre référentiel et de configurer un modèle prédéfini. GitHub peut même vous en recommander un en fonction de votre base de code :

Vous pouvez également écrire vos propres fichiers de configuration YAML, capables d’utiliser tous les outils et conteneurs Docker disponibles pour créer n’importe quelle application, sur les exécuteurs Windows et Linux. Ceux-ci peuvent exécuter tous les types de scripts que vous souhaitez, y compris les scripts Bash/PowerShell situés dans votre référentiel.

L’une des meilleures fonctionnalités de GitHub Actions est le marché communautaire, qui fonctionne comme un gestionnaire de packages pour les outils souvent utilisés dans les scripts de construction. Ceux-ci peuvent vous faire gagner beaucoup de temps qui serait consacré à l’automatisation des scripts vous-même. Par exemple, une tactique de déploiement courante consiste à télécharger des artefacts de génération dans un compartiment de stockage Amazon S3, et de nombreux outils sur le marché peuvent le faire pour vous.

En utilisant le marché, GitHub Actions peut faire pratiquement tout ce que d’autres solutions autonomes peuvent faire, juste avec un peu plus d’effort manuel. Après tout, il ne s’agit que d’exécuter des scripts de base sur un système Linux ou Windows.

Par exemple, des outils comme Jenkins offrent une intégration avec des logiciels de gestion des problèmes comme Jira ou Trello, ou des intégrations de journalisation avec Slack. Ceux-ci sont intégrés au logiciel et faciles à configurer, et ce sont d’excellents arguments de vente pour les systèmes de construction autonomes. Cependant, les actions GitHub peuvent également être configurées pour faire toutes ces choses en configurant des outils du marché.

L’un des principaux inconvénients des actions GitHub est la structure de tarification. Chaque compte ou organisation GitHub dispose d’un nombre défini de minutes de serveur de build qui est partagé entre tous les référentiels. Chaque minute qu’un serveur GitHub passe à exécuter votre build utilise des minutes de ce bucket. Le niveau gratuit est de 2000 minutes, soit la moitié de celui de Windows, ce qui est encore plus que suffisant pour la plupart des utilisateurs occasionnels.

Vous pouvez payer plus pour GitHub Pro, Team ou Enterprise pendant plus de minutes, mais vous pouvez également contourner complètement ce problème en fournissant votre propre runner auto-hébergé. Si vous avez un serveur supplémentaire qui traîne, vous pouvez le configurer assez rapidement pour accepter les tâches GitHub Actions. Selon les performances de ce serveur, il peut même être beaucoup plus rapide que l’hébergement partagé de GitHub Action. Vous pouvez lire notre guide sur la configuration de vos propres coureurs auto-hébergés pour en savoir plus.

Dans l’ensemble, GitHub Actions est fantastique pour les amateurs et fonctionne suffisamment bien pour que la plupart des petites équipes n’aient aucun problème à créer leurs projets à l’aide du service.

Serveurs de build externes

D’autre part, un serveur de build externe, tel que Jenkins ou TeamCity, fournit généralement des fonctionnalités plus avancées pour la création, le test et le déploiement d’applications, et est généralement préféré par les grandes équipes et les grandes entreprises pour avoir une plus grande flexibilité.

Si votre équipe a de nombreux projets, disposer d’un emplacement centralisé pour gérer l’automatisation et le déploiement de ces projets est très utile. Cela sépare les préoccupations de chaque service et permet au contrôle de code source de se concentrer sur l’hébergement de votre code, et au serveur de build sur sa construction.

Par exemple, si vous souhaitez gérer les scripts de construction pour de nombreux référentiels, vous devrez le faire à partir des paramètres de chaque référentiel. Mais avec un serveur de build, vous pouvez créer des groupes de configurations de build qui utilisent toutes le même modèle et apporter des modifications au modèle. Il est également plus facile de voir ce qui se passe avec votre automatisation en général lorsque vous avez un joli tableau de bord

Séparer le système de construction du contrôle de source permet également une plus grande flexibilité dans le choix de vos outils et services. Par exemple, si vous souhaitez utiliser d’autres solutions de contrôle de code source telles que Gitlab ou BitBucket, vous pouvez facilement les remplacer sans modifier la configuration de votre serveur de génération. Avec GitHub Actions, vous êtes essentiellement limité à l’utilisation de GitHub.

Les solutions autonomes peuvent également utiliser des fichiers de configuration de style YAML, mais ont généralement plus de fonctionnalités intégrées et offrent un meilleur contrôle sur les étapes et l’automatisation. Par exemple, TeamCity décompose la construction en étapes individuelles, chacune pouvant exécuter différents scripts, actions ou exécutables, et pouvant être configurée avec une plus grande fidélité qu’un simple fichier YAML.

Enfin, les fonctionnalités et les intégrations offertes par les solutions propriétaires sont utiles et généralement agréables à avoir. Par exemple, TeamCity propose une intégration d’application Slack personnalisée, qui peut enregistrer les erreurs de construction directement dans votre équipe.

Dans l’ensemble, si votre équipe a plusieurs projets et se soucie de leur gestion efficace, il peut être intéressant d’envisager de configurer votre propre serveur CI/CD.

Heureusement, de nombreuses bonnes solutions CI/CD sont gratuites ou open source. Jenkins est entièrement open source, mais nécessite un auto-hébergement. JetBrains TeamCity est gratuit si vous êtes auto-hébergé, mais propose également un service cloud payant. Travis CI est uniquement payant, mais il s’agit d’une autre solution populaire utilisée dans l’industrie.