Aller au contenu principal
CI/CD

Gérez vos builds de dev et de prod avec les actions GitHub

Utilisez Capgo pour déployer votre build de dev sur un canal spécifique, et laissez votre équipe tester votre application Ionic Capacitor sans attendre la validation d'Apple et Google

Gérez vos builds de développement et de production avec les actions GitHub

Ce tutoriel se concentre sur l'hébergement GitHub, mais vous pouvez l'adapter à n'importe quelle autre plateforme CI/CD avec quelques ajustements.

Préface

Assurez-vous d'avoir d'abord ajouté votre application Capacitor à Capgo ; ce tutoriel se concentre uniquement sur la phase d'upload.

Convention de commit

Commencez par suivre la convention de commit commits conventionnels` cela aidera les outils à comprendre comment incrémenter le numéro de version ; cela s'apprend en 5 min.

Commits conventionnels

actions GitHub pour le tag

Ensuite, vous devez créer votre première action GitHub pour automatiser le build et la création de tags.

Créez un fichier à ce chemin : .github/workflows/bump_version.yml

avec ce contenu :

name: Bump version

on:
  push:
    branches:
      - main
      - development

jobs:
  bump-version:
    if: "!startsWith(github.event.head_commit.message, 'chore(release):')"
    runs-on: ubuntu-latest
    name: "Bump version and create changelog with standard version"
    steps:
      - name: Check out
        uses: actions/checkout@v6
        with:
          fetch-depth: 0
          filter: blob:none
          token: '${{ secrets.PERSONAL_ACCESS_TOKEN }}'
      - name: Git config
        run: |
          git config --local user.name "github-actions[bot]"
          git config --local user.email "github-actions[bot]@users.noreply.github.com"
      - name: Create bump and changelog
        if: github.ref == 'refs/heads/main'
        run: npx capacitor-standard-version
      - name: Create bump and changelog
        if: github.ref != 'refs/heads/main'
        run: npx capacitor-standard-version --prerelease alpha
      - name: Push to origin
        run: |
          CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
          remote_repo="https://${GITHUB_ACTOR}:${{ secrets.PERSONAL_ACCESS_TOKEN }}@github.com/${GITHUB_REPOSITORY}.git"
          git pull $remote_repo $CURRENT_BRANCH
          git push $remote_repo HEAD:$CURRENT_BRANCH --follow-tags --tags

Cela créera une release pour chaque commit de votre branche principale, ainsi qu'une alpha release pour development, et enfin une entrée dans le changelog pour chaque commit dans CHANGELOG.md.

Ne vous inquiétez pas si vous n'avez pas ce fichier, il sera créé pour vous.

Pour que cela fonctionne, vous devez créer un TOKEN D'ACCÈS PERSONNEL et l'ajouter aux secrets GitHub secrets as PERSONAL_ACCESS_TOKEN.

Ceci est nécessaire pour permettre à la CI de commit le changelog et l'incrémentation de version.

Lors de la création du token, choisissez l'expiration comme never et le scope comme repo.

Configurez la version saisissez votre package.json Utilisez pour cela la dernière version publiée sur le store.

Ceci n'est nécessaire que la première fois, les outils s'occuperont ensuite de la mise à jour.

Vous pouvez maintenant commit ces deux fichiers et voir votre premier tag apparaître dans GitHub !

capacitor-standard-version est le package qui fait la magie ; par défaut, il met aussi à jour votre numéro de version sur Android et iOS

actions GitHub pour le build

Créez un fichier à ce chemin : .github/workflows/build.yml

avec ce contenu :

name: Build source code and send to Capgo

on:
  push:
    tags:
      - '*'
      
jobs:
  deploy:
    runs-on: ubuntu-latest
    name: "Build code and release"
    steps:
      - name: Check out
        uses: actions/checkout@v6
      - name: Install dependencies
        id: install_code
        run: npm i
      - name: Build
        id: build_code
        run: npm build
        env:
          MY_ENV_VAR: ${{ secrets.MY_ENV_VAR }}
      - name: Create Release Alpha
        if: "contains(github.ref, '-alpha.')"
        id: create_release_prepro
        run: npx @capgo/cli@latest bundle upload -a ${{ secrets.CAPGO_TOKEN }} -c development
      - name: Create Release Production
        if: "!contains(github.ref, '-alpha.')"
        id: create_release_prod
        run: npx @capgo/cli@latest bundle upload -a ${{ secrets.CAPGO_TOKEN }} -c production

Cela installera et compilera votre dépendance avant de l'envoyer vers Capgo.

Si votre commande de build est différente, vous pouvez la modifier dans l'étape build_code suivante.

Si vous avez besoin d'une variable d'environnement, utilisez MY_ENV_VAR et configurez le secret dans les paramètres de votre projet GitHub, puis dans secrets, puis l'action GitHub.

Pour que l'upload Capgo fonctionne, vous devez récupérer votre clé API pour Capgo, l'ajouter dans le secret de votre dépôt GitHub as CAPGO_TOKEN.

Vous pouvez maintenant commit ces deux fichiers et voir votre première version apparaître dans Capgo !

L'ajout du commit générera un nouveau build Capacitor pour les canaux de production et de développement.

Vous devriez ajouter vos tests à l'étape de build Ionic pour être certain que votre code fonctionne.

Allez sur votre dashboard Capgo et vérifiez votre build qui vient d'apparaître, vous avez maintenant votre système CI/CD.

Continuez avec Gérer les builds de développement et de production avec les actions GitHub

Si vous utilisez Gérer les builds de développement et de production avec les actions GitHub pour planifier le routage des canaux et le déploiement progressif, connectez-l’avec Canaux pour les détails d'implémentation des canaux, Canaux pour les détails d'implémentation des canaux, Canaux pour les détails d'implémentation des canaux, Solution de test bêta pour le workflow produit de la solution de test bêta, et Solution de ciblage de version pour le workflow produit de la solution de ciblage de version.

Live updates pour les apps Capacitor

Quand un bug de la couche web est en production, déployez le correctif via Capgo au lieu d'attendre des jours l'approbation des stores. Les utilisateurs reçoivent la mise à jour en arrière-plan, tandis que les changements natifs suivent le circuit de validation habituel.

Les derniers articles du blog

Capgo vous apporte les meilleures informations pour créer une application mobile vraiment professionnelle.