Aller au contenu principal

Comment personnaliser les scripts de build avec Capacitor CLI

Apprenez à personnaliser vos scripts de build avec Capacitor CLI pour des déploiements efficaces et des mises à jour d’app adaptées à chaque plateforme.

Comment personnaliser les scripts de build avec Capacitor CLI Capgo illustration du blog

Capacitor CLI permet de personnaliser le processus de build de votre application pour les plateformes iOS, Android et web. En ajustant les scripts de build, vous pouvez :

  • Accélérer les mises à jour: Publiez vos modifications instantanément, sans attendre les stores.
  • Contrôler les déploiements: Effectuez un rollback ou ciblez des groupes d'utilisateurs spécifiques.
  • Sécuriser votre application: Use encryption to protect updates.
  • Optimiser les builds: Adjust settings for platform-specific needs.

Aperçu rapide des fonctionnalités clés :

  • Fichiers de configuration : Utilisez capacitor.config.json et package.json pour gérer les paramètres de build.
  • Scripts personnalisés: Ajoutez des tâches prebuild et postbuild pour l’automatisation.
  • Build hooks: Exécutez code lors de certaines étapes du processus de build.
  • Variables d’environnement: Simplifiez les builds spécifiques à l’environnement avec .env fichiers.

Capgo, un outil de déploiement, améliore ce processus avec mises à jour automatisées, suivi des versions et optimisation globale des performances. Continuez la lecture pour découvrir comment configurer et personnaliser vos scripts de build afin d’optimiser leur efficacité.

Présentation de Capacitor Configurer

Site de documentation du framework Capacitor

Processus de build par défaut dans Capacitor

Comprendre la façon dont Capacitor gère son processus de build par défaut est essentiel si vous souhaitez le personnaliser efficacement. Ci-dessous, nous détaillons le processus de build de Capacitor CLI et ses fichiers de configuration clés.

Étapes de build standard

Capacitor suit un processus étape par étape pour transformer votre application web en builds spécifiques à chaque plateforme. Voici ce qui se passe lors du build par défaut :

Phase Description Résultat
Build web Compile les assets web à l'aide des outils de votre framework Bundle web optimisé
Copie des assets Déplace les assets web vers les dossiers des plateformes natives Répertoires d'assets spécifiques à la plateforme
Native Build Runs platform-specific build commands Binaires prêts à être déployés
Vérification Vérifie l’intégrité du build et les dépendances Statut du build et avertissements

Fichiers de config principaux

Deux fichiers de configuration clés déterminent la façon dont Capacitor gère vos builds :

capacitor.config.json
C’est le fichier de configuration principal de votre projet Capacitor. Il définit les paramètres essentiels de vos builds :

{
  "appId": "com.example.app",
  "appName": "MyApp",
  "webDir": "dist",
  "bundledWebRuntime": false,
  "plugins": {
    "SplashScreen": {
      "launchShowDuration": 3000
    }
  }
}
  • appId: Un identifiant unique pour votre application.
  • appName: Le nom de votre application.
  • webDir: Spécifie où Capacitor doit chercher les assets web (ex : dist).
  • plugins: Permet de configurer les paramètres spécifiques aux plugins, comme les options SplashScreen.

package.json
Ce fichier contient les scripts de build et les dépendances qui influencent le processus de build :

{
  "scripts": {
    "build": "npm run build:web && cap sync",
    "build:web": "vite build",
    "cap:build": "cap build"
  }
}
  • Le webDir paramètre dans capacitor.config.json indique à Capacitor où localiser vos assets web compilés pour les inclure dans les builds natifs.
  • Après avoir modifié capacitor.config.json, vous devez exécuter cap sync pour vous assurer que vos projets natifs sont à jour.

Ensuite, nous allons voir comment modifier ces paramètres pour personnaliser davantage vos builds.

Modifier les scripts de build

Vous pouvez ajuster le processus de build par défaut de Capacitor pour mieux répondre aux besoins de votre projet. Voici comment :

Paramètres du fichier de config

Vous pouvez ajuster le processus de build en modifiant le capacitor.config.json fichier. Voici un exemple de configuration :

{
  "appId": "com.example.app",
  "webDir": "www",
  "server": {
    "hostname": "localhost",
    "androidScheme": "https",
    "iosScheme": "https",
    "allowNavigation": ["*.example.com"]
  },
  "android": {
    "buildOptions": {
      "keystorePath": "release.keystore",
      "keystorePassword": "mypassword",
      "keystoreAlias": "release",
      "keystoreAliasPassword": "mypassword"
    }
  },
  "ios": {
    "scheme": "App",
    "automaticProvisioning": true
  }
}

Voici quelques paramètres clés que vous pouvez modifier :

  • webDir : Spécifie l'emplacement de vos assets web compilés.
  • server : Configure le serveur de développement, incluant l'hostname et les permissions de navigation.
  • android/ios: Permet des paramètres de build spécifiques à la plateforme, comme les détails du keystore pour Android ou les options de provisionnement pour iOS.

Créer des scripts NPM

Pour optimiser votre workflow, ajoutez des scripts NPM personnalisés à votre package.json fichier. Voici un exemple :

{
  "scripts": {
    "prebuild": "node ./scripts/prepare-env.js",
    "build": "npm run build:web && cap sync",
    "build:web": "vite build",
    "build:ios": "cap build ios --release",
    "build:android": "cap build android --release",
    "postbuild": "node ./scripts/notify-completion.js"
  }
}
  • prebuild et postbuild: utilisez-les pour des tâches comme configurer l’environnement ou envoyer des notifications à la fin du build.
  • build:platform: commandes spécifiques à la plateforme pour compiler des applications Android ou iOS.

Poussez l’automatisation plus loin en ajoutant des build hooks.

Configuration des hooks de build

Pour un contrôle plus avancé, utilisez les build hooks pour exécuter du code personnalisé à des étapes précises du build. Voici un exemple de configuration dans capacitor.config.ts:

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.example.app',
  plugins: {
    CapacitorHooks: {
      beforeBuild: async () => {
        console.log('Running pre-build tasks...');
        // Add your pre-build tasks here
      },
      afterBuild: async () => {
        console.log('Running post-build tasks...');
        // Add your post-build tasks here
      }
    }
  }
};

export default config;

Avec les build hooks, vous pouvez :

  • Valider les prérequis avant le démarrage du build
  • Transformer les assets pendant le processus
  • Déclencher des notifications à des points clés
  • Mettre à jour les numéros de version automatiquement
  • Lancez vos tests automatisés sans effort

Cette approche vous offre plus de flexibilité et de contrôle sur l'ensemble du cycle de vie du build.

Personnalisation avancée du build

Sur des projets de grande envergure, optimiser votre processus de build peut faire une grande différence. Voici comment gérer efficacement les builds spécifiques à chaque environnement et les personnalisations par plateforme.

Variables d’environnement

Configurez vos variables d'environnement en créant des .env fichiers distincts pour chaque environnement :

  • .env.development
  • .env.staging
  • .env.production

Ensuite, configurez votre script de build pour charger le fichier approprié selon l'environnement :

import { defineConfig } from '@capacitor/cli';

export default defineConfig({
  ios: {
    buildConfig: {
      environment: process.env.BUILD_ENV || 'development',
      configurations: {
        development: {
          signing: {
            debug: true,
            automaticProvisioning: true
          }
        },
        production: {
          signing: {
            release: true,
            provisioningProfile: 'dist/profile.mobileprovision'
          }
        }
      }
    }
  }
});

Vous pouvez affiner ces paramètres pour répondre aux exigences spécifiques de chaque plateforme.

Builds spécifiques aux plateformes

Pour personnaliser les builds pour Android et iOS, utilisez la structure suivante :

const platformConfig = {
  android: {
    buildType: process.env.BUILD_TYPE || 'debug',
    keystoreConfig: {
      path: process.env.KEYSTORE_PATH,
      password: process.env.KEYSTORE_PASSWORD,
      alias: process.env.KEYSTORE_ALIAS
    }
  },
  ios: {
    scheme: process.env.APP_SCHEME || 'App',
    xcodePreferences: {
      automaticSigning: false,
      developmentTeam: process.env.DEVELOPMENT_TEAM
    }
  }
};

Ces configurations vous permettent d'adapter vos builds pour chaque plateforme, garantissant des déploiements plus fluides.

Fonctionnalité Android iOS
Symboles de debug ProGuard fichiers de mapping fichiers dSYM
Variantes de build debug, release, staging debug, release
Code Signature Gestion du keystore Profils de provisionnement
Gestion des assets Optimisation de res/drawable Catalogues d'assets

Voici d'autres conseils pour optimiser vos builds :

  • Utiliser les mises à jour partielles pour gagner du temps lors des déploiements
  • Configurer le suivi des erreurs pour identifier rapidement les problèmes
  • Créer des systèmes de canaux pour les versions de test bêta
  • Activer le chiffrement de bout en bout pour une distribution sécurisée

Associées à des outils comme Capgo pour l’analyse et les mises à jour sécurisées, ces techniques vous donnent plus de contrôle sur votre processus de déploiement [1].

Problèmes et solutions des scripts de build

Lorsque vous travaillez avec des configurations de build personnalisées, il est essentiel de résoudre rapidement les erreurs pour que le processus de build se déroule sans accroc.

Corriger les erreurs courantes

De nombreux problèmes de scripts de build proviennent de la configuration de l'environnement ou de dépendances. Voici comment résoudre les plus courants :

Variables d'environnement manquantes

Si vous rencontrez une erreur de ce type :

error: Cannot find environment configuration for BUILD_ENV

Vous pouvez la corriger en créant un .env.local fichier à la racine de votre projet. Voici un exemple :

BUILD_ENV=development
CAPACITOR_PLATFORM=ios
BUILD_TYPE=debug

Échecs de build par plateforme

Pour les erreurs de signature Android, utilisez cette commande :

npx cap build android --keystorePassword=$KEYSTORE_PASSWORD --keystoreAlias=$KEYSTORE_ALIAS

Pour les problèmes de profil de provisionnement iOS, essayez ceci :

npx cap build ios --configuration=release --type=development
Type d'erreur Cause courante Solution
Configuration de signature Détails du keystore manquants Définissez KEYSTORE_PATH et identifiants
Environnement de build Variables non définies Créer par plateforme .env fichiers
Dépendances Incohérences de version Mise à jour package.json et synchroniser

Après avoir appliqué les correctifs, assurez-vous que vos changements sont solides en lançant des tests de build approfondis.

Tester les scripts de build

Une fois les erreurs résolues, validez vos scripts de build avec ces étapes :

  • Vérification automatisée: Exécutez les commandes clés pour confirmer que le processus de build fonctionne comme prévu.
npm run build
npx cap sync
npx cap copy
  • Validation de l'environnement: Vérifiez qu'aucune variable d'environnement ne manque avant de lancer le build.
const requiredVars = ['BUILD_ENV', 'KEYSTORE_PATH'];
requiredVars.forEach(varName => {
  if (!process.env[varName]) {
    throw new Error(`Missing required env var: ${varName}`);
  }
});
  • Débogage des scripts de build: Ajoutez des scripts détaillés pour détecter d'éventuels problèmes pendant le build.
{
  "scripts": {
    "build:debug": "NODE_ENV=development npx cap build --verbose",
    "build:release": "NODE_ENV=production npx cap build --verbose"
  }
}

Conseils supplémentaires pour les tests :

  • Utiliser Docker conteneurs pour isoler les builds.
  • Valider les fichiers de configuration avant de lancer le processus.
  • Tester avec plusieurs Node.js versions.
  • Vérifiez que les exigences spécifiques à la plateforme sont remplies.
  • Surveillez les performances du build pour d’éventuelles optimisations.

Capgo Fonctionnalités de build

Interface du dashboard Capgo Live Update

Capgo pousse les scripts de build à un niveau supérieur grâce au déploiement automatisé, ce qui améliore l’efficacité et simplifie le processus.

Mises à jour rapides de l’app

Capgo’s update performance is impressive:

  • 95 % des utilisateurs actifs recevoir les mises à jour sous 24 heures.
  • Taux de réussite de 82 % pour la livraison des mises à jour à l’échelle mondiale.
  • Un temps de réponse moyen de API de 434 ms à l’échelle mondiale.

La plateforme utilise des mises à jour partielles, ce qui signifie que seules les modifications sont téléchargées. Cette approche réduit la consommation de bande passante et accélère le processus de mise à jour. De plus, l’ensemble du processus de build est entièrement automatisé, ce qui fait gagner du temps et de l’effort.

Automatisation du build

Capgo fonctionne sans accroc avec les principales plateformes CI/CD, offrant une variété d’intégrations :

Plateforme CI/CD Fonctionnalités d’intégration Avantages
GitHub Actions GitHub Builds automatisés, déclencheurs de déploiement Déploiement continu
GitLab CI Automatisation du pipeline, contrôle de version Workflow optimisé
Jenkins Workflows personnalisés, hooks de build Évolutif pour les entreprises

La mise en place d'un build automatisé coûte généralement environ 300 $ par mois, ce qui est bien plus abordable que les solutions traditionnelles, qui peuvent atteindre 6 000 $ par an.

Normes de sécurité

Capgo privilégie la sécurité grâce à un framework robuste qui comprend :

  • Chiffrement de bout en bout des paquets de mise à jour.
  • Gestion sécurisée des clés.
  • Conformité aux directives d’Apple et de Google.

Fonctionnalités de gestion de versions

  • Options de rollback instantané.
  • Suivi des versions déployées.
  • Gestion des canaux de mise à jour pour les releases progressives.

Ce framework de sécurité a été rigoureusement testé sur des centaines d’applications d’entreprise. Pour les équipes ayant besoin d’une sécurité accrue, Capgo propose également des solutions auto-hébergées avec des configurations personnalisables.

Le système de canaux de Capgo rend la distribution des mises à jour flexible. Les développeurs peuvent cibler des groupes d'utilisateurs spécifiques avec différentes versions, ce qui est idéal pour les tests bêta ou les déploiements progressifs.

Résumé

Aperçu des étapes de build

Les scripts de build personnalisés permettent des déploiements automatisés et cohérents en exploitant les hooks de build, les variables d'environnement et les commandes spécifiques à chaque plateforme. Ces processus créent une base solide pour les améliorations de déploiement rendues possibles par Capgo.

Avantages de Capgo

Capgo simplifie le déploiement, avec plus de 23,5 millions de mises à jour livrées sur 750 applications en production [1]. Its partial update system reduces both bandwidth usage and deployment time.

La plateforme offre des mises à jour rapides, une optimisation des performances à l'échelle mondiale, un chiffrement de bout en bout pour la sécurité et un système de distribution flexible basé sur les canaux. Cette configuration permet des mises à jour ciblées, des tests bêta et le respect des règles des stores, tout en conservant un cadre de sécurité solide.

Continuer la lecture : Comment personnaliser les scripts de build avec Capacitor CLI

Si vous utilisez Comment personnaliser les scripts de build avec Capacitor CLI pour planifier l'automatisation CI/CD, et le connecter avec CI/CD Capgo pour le workflow produit dans le CI/CD de Capgo, Capgo Native Build pour le workflow produit dans les Native Builds de Capgo, Intégrations Capgo pour le workflow produit dans les intégrations de Capgo, Intégration CI/CD pour le détail d'implémentation dans l'intégration CI/CD, et Intégration GitHub Actions pour les détails d'implémentation de l'intégration GitHub Actions.

Live updates pour les apps Capacitor

Lorsqu'un bug de la couche web est en ligne, 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 offre les meilleures informations pour créer une application mobile vraiment professionnelle.