Les Autres Forges

GitLab CI, Bitbucket Pipelines, Jenkins et portabilité

Pourquoi connaître plusieurs plateformes ?

Tu pourrais te demander : "Si je connais GitHub Actions, pourquoi apprendre autre chose ?" Excellente question. Voici la réponse :

• Le marché du travail : certaines entreprises utilisent GitLab, d'autres Bitbucket, d'autres encore Jenkins. Connaître plusieurs plateformes te rend beaucoup plus employable.
• Les besoins varient : un projet open source ira naturellement sur GitHub, mais une entreprise avec des serveurs internes préférera peut-être GitLab auto-hébergé.
• La portabilité : comprendre les concepts communs te permet de passer d'une plateforme à l'autre en quelques heures, pas en quelques semaines.
• L'esprit critique : connaître les alternatives te permet de choisir le bon outil plutôt que de subir un choix par défaut.

GitLab CI/CD - La Forge Impériale

GitLab est souvent considéré comme le concurrent le plus complet de GitHub. Sa force principale : tout est intégré. CI/CD, registre de conteneurs, gestion de projet, sécurité - tout est dans une seule plateforme.

Le fichier .gitlab-ci.yml

Comme GitHub Actions utilise des fichiers dans .github/workflows/, GitLab utilise un unique fichier à la racine du dépôt : .gitlab-ci.yml.

stages:
  - test
  - deploy

test:
  stage: test
  script:
    - echo "Tests en cours..."

deploy:
  stage: deploy
  script:
    - echo "Déploiement en cours..."
  only:
    - main

Les concepts clés de GitLab CI

Exemple plus complet

stages:
  - build
  - test
  - deploy

variables:
  APP_NAME: "mon-application"

build:
  stage: build
  script:
    - echo "Construction de $APP_NAME..."
    - mkdir -p build
    - cp src/*.py build/
  artifacts:
    paths:
      - build/

test-unitaire:
  stage: test
  script:
    - echo "Tests unitaires..."
    - python -m pytest tests/

test-lint:
  stage: test
  script:
    - echo "Vérification du style..."
    - python -m flake8 src/

deploy:
  stage: deploy
  script:
    - echo "Déploiement de $APP_NAME..."
  only:
    - main
  when: manual

Les forces de GitLab

• Tout-en-un : CI/CD, registre de conteneurs Docker, gestion de projet, wiki, pages statiques - tout est intégré nativement.
• Auto-hébergement : tu peux installer GitLab sur tes propres serveurs. C'est un avantage énorme pour les entreprises qui veulent garder le contrôle de leurs données.
• Registre de conteneurs intégré : chaque projet GitLab a son propre registre Docker, prêt à l'emploi.
• Environnements de déploiement : GitLab permet de définir des environnements (staging, production) et de visualiser les déploiements directement dans l'interface.

Bitbucket Pipelines - La Forge des Guildes Marchandes

Bitbucket est la forge de l'écosystème Atlassian - la même famille que Jira (gestion de projet) et Confluence (documentation). Si ton entreprise utilise Jira, Bitbucket s'intègre naturellement.

Le fichier bitbucket-pipelines.yml

Bitbucket utilise aussi un fichier YAML à la racine du dépôt :

pipelines:
  default:
    - step:
        name: Tests
        script:
          - echo "Tests en cours..."

  branches:
    main:
      - step:
          name: Tests
          script:
            - echo "Tests en cours..."
      - step:
          name: Déploiement
          script:
            - echo "Déploiement en cours..."

Les concepts clés de Bitbucket Pipelines

Exemple avec Pipes

Les Pipes sont une spécificité de Bitbucket - ce sont des intégrations prêtes à l'emploi :

pipelines:
  default:
    - step:
        name: Tests
        caches:
          - node
        script:
          - npm install
          - npm test
    - step:
        name: Notification Slack
        script:
          - pipe: atlassian/slack-notify:2.0.0
            variables:
              WEBHOOK_URL: $SLACK_WEBHOOK
              MESSAGE: "Build terminé avec succès !"

Les forces de Bitbucket

• Intégration Jira : les commits et branches sont automatiquement liés aux tickets Jira. Tu crées une branche depuis un ticket, et tout est tracé.
• Pipes : des intégrations pré-construites qui simplifient les tâches courantes (déploiement AWS, notifications, etc.).
• Dépôts privés gratuits : historiquement, Bitbucket offrait des dépôts privés gratuits avant GitHub.
• Intégration Confluence : la documentation est directement liée au code.

Les autres forges notables

Le monde des forges ne se limite pas à ces trois géants. Voici d'autres acteurs importants :

Jenkins - Le Vétéran

Jenkins est l'un des plus anciens outils de CI/CD. Il est entièrement auto-hébergé et extrêmement flexible.

• Points forts : personnalisation infinie, immense écosystème de plugins (plus de 1800), gratuit et open source.
• Points faibles : interface vieillissante, configuration complexe, maintenance nécessaire.
• Fichier de config : Jenkinsfile (syntaxe Groovy)

pipeline {
    agent any
    stages {
        stage('Test') {
            steps {
                sh 'echo "Tests en cours..."'
            }
        }
    }
}

Jenkins reste très utilisé dans les grandes entreprises qui ont investi massivement dans leurs infrastructures.

CircleCI - Le Sprinter du Cloud

CircleCI est une plateforme CI/CD cloud-native, reconnue pour sa rapidité et son efficacité.

• Points forts : très rapide, excellent support Docker, bonne interface.
• Points faibles : coût qui augmente vite avec l'usage, moins de fonctionnalités annexes.
• Fichier de config : .circleci/config.yml

Travis CI - Le Pionnier Open Source

Travis CI a été historiquement la plateforme CI/CD favorite des projets open source. Il a popularisé le concept de CI/CD intégrée aux forges.

• Points forts : simple à configurer, pionnier de l'intégration avec GitHub.
• Points faibles : a perdu en popularité après son rachat, offre gratuite réduite.
• Fichier de config : .travis.yml

Forgejo/Gitea Actions - L'Alternative Libre

Forgejo et Gitea sont des forges auto-hébergées, légères et open source. Leur système d'Actions est compatible avec GitHub Actions - tu peux souvent réutiliser tes workflows directement !

• Points forts : léger, auto-hébergé, compatible GitHub Actions, respectueux de la vie privée.
• Points faibles : communauté plus petite, moins d'actions tierces disponibles.
• Fichier de config : .forgejo/workflows/ ou .gitea/workflows/ (même syntaxe que GitHub Actions)

Tableau comparatif

Voici un résumé pour t'aider à comprendre les différences :

Comment choisir la bonne plateforme ?

Le choix dépend de ton contexte. Voici un guide simple :

• Tu fais de l'open source ? - GitHub. La communauté est là, les contributeurs connaissent la plateforme.
• Ton entreprise veut tout contrôler en interne ? - GitLab auto-hébergé. Données sur tes serveurs, personnalisation totale.
• Ton équipe utilise déjà Jira ? - Bitbucket. L'intégration native avec l'écosystème Atlassian est un gain de temps énorme.
• Tu veux une solution légère et libre ? - Forgejo/Gitea. Parfait pour un serveur personnel ou une petite équipe.
• Tu as un système complexe existant ? - Jenkins. Sa flexibilité est inégalée pour les cas particuliers.

La portabilité - L'art de ne pas être prisonnier

Un piège courant : mettre toute ta logique CI/CD dans le fichier YAML de ta plateforme. Si tu changes de forge un jour, tu dois tout réécrire.

La solution ? Garder la logique dans des scripts, pas dans le YAML.

Mauvaise approche (tout dans le YAML)

# .github/workflows/ci.yml - Difficile à porter
name: CI
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -r requirements.txt
      - run: python -m pytest tests/ --cov=src
      - run: python -m flake8 src/ --max-line-length=120
      - run: echo "Tous les tests passent !"

Bonne approche (logique dans un script)

D'abord, crée un script scripts/test.sh :

#!/bin/bash
# scripts/test.sh - La logique est ici, pas dans le YAML
echo "Installation des dépendances..."
pip install -r requirements.txt

echo "Lancement des tests..."
python -m pytest tests/ --cov=src

echo "Vérification du style..."
python -m flake8 src/ --max-line-length=120

echo "Tous les tests passent !"

Ensuite, chaque fichier YAML appelle simplement ce script :

# GitHub Actions
- run: bash scripts/test.sh

# GitLab CI
script:
  - bash scripts/test.sh

# Bitbucket Pipelines
script:
  - bash scripts/test.sh

Résultat : si tu changes de plateforme, tu n'as qu'à réécrire le fichier YAML minimal. Toute ta logique reste intacte.

Exercice pratique - Forger sur trois enclumes

Étape 1 - Créer le dépôt

mkdir multi-forge
cd multi-forge
git init -b main

Étape 2 - Créer le script de test

Crée un dossier scripts/ et un fichier scripts/test.sh :

mkdir scripts

Écris le contenu de scripts/test.sh :

#!/bin/bash
# scripts/test.sh - Script de test portable

echo "=== Lancement des tests ==="

# Test 1 : vérifier que le fichier README existe
if [ -f "README.md" ]; then
    echo "PASS : README.md existe"
else
    echo "FAIL : README.md manquant"
    exit 1
fi

# Test 2 : vérifier que le dossier scripts existe
if [ -d "scripts" ]; then
    echo "PASS : dossier scripts/ existe"
else
    echo "FAIL : dossier scripts/ manquant"
    exit 1
fi

echo "=== Tous les tests passent ==="

Rends-le exécutable :

chmod +x scripts/test.sh

Étape 3 - Créer un README

echo "# Multi-Forge" > README.md
echo "Projet de démonstration CI/CD multi-plateforme." >> README.md

Étape 4 - Écrire le pipeline GitHub Actions

mkdir -p .github/workflows

Contenu de .github/workflows/ci.yml :

name: CI
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Lancer les tests
        run: bash scripts/test.sh

Étape 5 - Écrire le pipeline GitLab CI

Contenu de .gitlab-ci.yml (à la racine) :

stages:
  - test

test:
  stage: test
  script:
    - bash scripts/test.sh

Étape 6 - Écrire le pipeline Bitbucket Pipelines

Contenu de bitbucket-pipelines.yml (à la racine) :

pipelines:
  default:
    - step:
        name: Tests
        script:
          - bash scripts/test.sh

Étape 7 - Tout commiter

git add .
git commit -m "Ajouter les pipelines CI pour GitHub, GitLab et Bitbucket"

Étape 8 - Lancer la vérification

bash verifier.sh

.\verifier.ps1

Récapitulatif des concepts

Récapitulatif des fichiers de configuration