CI/CD : comment bien choisir entre CircleCI et GitHub Actions

CircleCI vs GitHub Actions : les grands points de comparaison

CircleCI et GitHub Actions sont tous deux disponibles en mode SaaS ou dans une distribution self-managed.

Compatibilité avec les dépôts de code. Avec les options SaaS de ces outils, les équipes doivent établir un accès permanent entre la plateforme et leurs dépôts pour récupérer le code source de l’application. CircleCI fonctionne avec des dépôts publics ou privés entreposés dans GitHub ou Bitbucket. En comparaison, GitHub Actions n’est disponible que pour les référentiels stockés sur GitHub. Avant de choisir CircleCI ou GitHub Actions, les membres de l’équipe devront confirmer que leurs répertoires de code sont pris en charge par leur plateforme préférée.

Interfaces utilisateur. Certains développeurs privilégient GitHub Actions parce qu’il est plus étroitement intégré à leurs dépôts de code sur GitHub. Les équipes apprécieront l’UI familière. Si les référentiels d’un groupe ne sont pas liés à GitHub, CircleCI inclut certaines fonctionnalités depuis son UI, qui peuvent s’avérer bénéfiques. Pour une organisation qui souhaite héberger le pipeline d’une application et le dépôt de code au même endroit, GitHub Actions pourrait avoir l’avantage.

Temps de calcul. Les usagers de dépôts publics disposeront de temps de calcul gratuits et illimités sur GitHub Actions. Cependant, les utilisateurs de dépôts privés du tiers gratuit de GitHub Actions sont restreints à 2 000 minutes de temps de calcul par mois.

Le tiers gratuit de CircleCI octroie 30 000 crédits – la façon dont CircleCI mesure l’usage des utilisateurs et des instances de calcul par build – chaque mois pour les repositories privés et publics. Par exemple, les 30 000 crédits du volet gratuit permettent de disposer de 3 000 minutes de build en s’appuyant sur une instance de calcul moyenne Docker ou Linux, à raison de 10 crédits par minute. Voici une autre manière de présenter les choses :

• Le service gratuit de GitHub Actions offre des minutes illimitées pour les dépôts publics.
• Le module gratuit de GitHub Actions est limité à 2 000 minutes pour les dépôts privés.
• La version gratuite de CircleCI ne fait pas de différence entre les dépôts publics et privés.
• Le niveau gratuit de CircleCI comprend en général 3 000 minutes de calcul.

Lorsque les équipes comparent les deux plateformes, elles constatent que GitHub Actions est plus rentable pour les utilisateurs de référentiels publics. Cependant, CircleCI peut offrir une meilleure offre pour les projets avec des dépôts privés.

Versions payantes. Une équipe qui opte pour la version payante de CircleCI bénéficiera de tailles d’instance de calcul plus importantes et de plus de crédits par mois. Ces fonctionnalités permettent aux programmeurs d’exécuter plus de builds avec des crédits supplémentaires, et ce plus rapidement avec plus de puissance de calcul. Les services payants de CircleCI autorisent également un plus grand nombre d’utilisateurs, ce qui s’applique aux dépôts privés. Sur les actions GitHub, les niveaux payants débloquent plus de minutes de temps de construction. L’éditeur détaille ici les fonctionnalités disponibles dans les versions Free, Team et Enterprise.

Instances de calcul. CircleCI permet aux builds d’être interprétés sur de nombreuses instances de calcul, dont les machines AWS équipées de processeurs Graviton ou d’autres, dotées de GPU, ou – en option – depuis des VM hébergées par les développeurs. CircleCI supporte des configurations macOS, Windows, Linux et Docker/Linux. Pour certains projets, il peut être judicieux d’utiliser une instance de taille supérieure pour améliorer les temps de build, au prix d’une dépense plus importante de crédits. GitHub Actions exécute ses runners (les workloads liés à la chaîne CI/CD) sur une machine virtuelle Standard_DS2_V2 sur Microsoft Azure (2 vCPU, 7 GO de RAM, 14 Go d’espace de stockage temporaire sur SSD, 8 Go d’espace sur HDD). Un flux Actions appelle à chaque exécution une nouvelle VM qui s’éteint à la fin d’un job. Il est possible de choisir des versions spécifiques de Windows Server, macOS ou Ubuntu.

À noter que l’instance dédiée à macOS ne dispose pas de la même configuration (3 vCPU, 14 Go de RAM, 14 Go d’espace disque SSD). Les développeurs peuvent également gérer leurs propres VM avec GitHub Actions. Cela offre davantage d’options pour le support des distributions Linux (CentOS, Ubuntu, SLES, Oracle Linux, Fedora, Debian, openSUSE, RHEL, et Linux Mint), mais aussi des architectures matérielles (x86-64, ARM32, ARM64). Il est conseillé de recourir à ces VM « self hosted » avec des dépôts privés et d’y appliquer des règles strictes de sécurité.

Séparation des fichiers. Alors que CircleCI oblige les pipelines à exister sous la forme d’un fichier YAML de configuration unique, les pipelines de GitHub Actions peuvent être divisés en fichiers YAML distincts pour chaque flux de travail. Par exemple, les usagers de GitHub Actions peuvent constituer plusieurs fichiers YAML ; une équipe peut séparer les fichiers en fonction de l’environnement pour lequel elle a testé et construit une application. Cette fonctionnalité peut aider les développeurs à créer une conception plus propre en faveur des applications qui utilisent un processus de build différent pour un environnement de développement et de production.

Accès aux builds. CircleCI offre un accès SSH aux builds alors que GitHub Actions ne le fait pas par défaut. Avec l’accès SSH, les programmeurs pourront facilement déboguer des problèmes avec des commandes non présentes ou des fichiers dans des répertoires inattendus.

Orbs contre Actions

Les deux plateformes CI/CD proposent une commande réutilisable et simplifiée qui permet à un pipeline d’intégrer des processus prédéfinis et couramment utilisés. Chez GitHub, cette fonctionnalité est nommée Actions. L’équivalent dans CircleCI est appelé orbs. Grâce à cette fonctionnalité, les équipes de développement peuvent gagner du temps et limiter la complexité des processus.

Différences de conception. De nombreux orbs – c’est-à-dire des commandes – existent pour des services souvent utilisés par les fournisseurs de cloud computing, tels que AWS, Azure et Google Cloud Platform. Par exemple, les programmeurs peuvent utiliser un orbe CircleCI pour appeler une commande comme aws-ecr/build-and-push-image.

Avec cet orb, CircleCI va construire une image Docker et la pousser automatiquement vers le dépôt ECR souhaité. Pour les processus internes sensibles, les développeurs peuvent créer des orbes privés uniquement accessibles à leur organisation IT.

Les actions GitHub sont supportées de manière similaire par les fournisseurs de clouds, mais n’offrent pas d’option pour publier une action de manière privée. Par exemple, la création et la mise à jour d’une image sur ECR avec les actions GitHub se présentent comme suit :

- name: Login to Amazon ECR

     id: login-ecr

     uses: aws-actions/amazon-ecr-login@v1

- name: Build, tag, and push image to Amazon ECR

     env:

          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}

          ECR_REPOSITORY: my-ecr-repo

          IMAGE_TAG: ${{ github.sha }}

     run: | 

          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .

          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

Alors que l’équivalent orbs ressemble à ceci :

- aws-ecr/build-and-push-image:
 
     account-url: AWS_ECR_ACCOUNT_URL

     region: AWS_REGION
 
     repo: '${MY_APP_PREFIX}'
 
     tag: '${CIRCLE_SHA1}'

Lorsque les programmeurs utilisent CircleCI, ils découvriront probablement que la plateforme fournit les paramètres pour former une opération et qu’Orbs peut gérer le reste. À l’inverse, GitHub Actions demande plus d’entrées et requiert spécifiquement les commandes Docker. Le design de CircleCI peut être considéré comme plus propre et plus simple, tandis que GitHub Actions offre un contrôle plus granulaire en exposant les commandes que CircleCI garde derrière le rideau.

Conclusion

Bien que CircleCI et GitHub Actions accomplissent les mêmes tâches, chaque service a une atmosphère et une philosophie différentes.

Les équipes IT peuvent se sentir obligées d’utiliser un outil plutôt qu’un autre, en fonction de leur dépôt et de la compatibilité perçue des processus. Si les équipes le peuvent, elles devraient essayer chaque service afin que les développeurs puissent évaluer chaque option et déterminer au mieux quel outil est le mieux adapté aux processus de construction et de test et à la taille des déploiements de leur organisation.