Lane — qu'est-ce que c'est, création et utilisation dans Fastlane

Qu'est-ce qu'un Lane dans Fastlane

Lane — est le bloc de construction de base de Fastlane, définissant un scénario d'automatisation nommé. Chaque lane décrit une séquence d'actions à exécuter pour atteindre un objectif spécifique : compiler une application, lancer des tests, télécharger un build vers le store ou configurer l'environnement. Un lane est déclaré dans Fastfile et exécuté par la commande fastlane [nom_lane] depuis la racine du projet.

Le concept de lane est emprunté au Ruby DSL et assure la lisibilité des scénarios. Le développeur voit tout le processus CI/CD comme une séquence d'appels d'actions avec des noms et des paramètres compréhensibles. Un lane peut être simple (une seule commande) ou complexe (branchements, boucles, appels à d'autres lanes).

Chaque lane après exécution retourne un résultat — un objet contenant le statut d'exécution et les données des actions. Le résultat peut être utilisé dans d'autres lanes ou transmis au système CI/CD pour la prise de décisions. Si une action dans un lane se termine par une erreur, l'exécution du lane s'arrête et le bloc error est appelé.

Syntaxe lane : déclaration et exécution

La syntaxe de déclaration d'un lane suit un modèle simple du Ruby DSL : le mot-clé lane, le nom du scénario sous forme de symbole Ruby (symbol), le bloc do ... end avec le corps du scénario. Le nom du lane doit être unique au sein de la plateforme et être composé de lettres, de chiffres et de tirets bas.

L'exécution d'un lane se fait via la ligne de commande : fastlane build (pour le lane nommé :build) ou bundle exec fastlane build (si Fastlane est installé via Bundler). Pour les lanes de plateforme, utilisez fastlane ios build ou fastlane android build.

# Déclaration d'un lane simple
lane :test do
  scan(scheme: 'App', devices: ['iPhone 15'])
end

lane :build_and_deploy do
  cocoapods
  test
  gym(scheme: 'App', export_method: 'app-store')
  pilot(skip_waiting_for_build_processing: true)
end

# Exécution : fastlane build_and_deploy

Un lane peut contenir une logique conditionnelle basée sur des paramètres ou des variables d'environnement. Utilisez if/unless pour sauter des étapes dans certaines conditions. Les boucles each sont également disponibles pour traiter des tableaux, ce qui est pratique pour construire plusieurs cibles ou schémas d'application dans un seul lane.

Valeur de retour d'un lane

Lane peut retourner une valeur qui sera accessible au code appelant. Pour retourner une valeur, utilisez le return standard de Ruby ou la dernière expression du bloc lane. La valeur retournée peut être une chaîne, un nombre, un hash ou le résultat d'une action. Cela permet d'utiliser le résultat d'un lane dans un autre lane pour prendre des décisions.

Par exemple, le lane :get_version peut retourner la version actuelle de l'application depuis Info.plist, et le lane :deploy l'utiliser pour formater un message dans Slack. Les valeurs de retour sont particulièrement utiles dans les private lanes, où le résultat est nécessaire pour un traitement ultérieur dans le lane appelant.

Paramètres des lanes : transmission et traitement

Les paramètres d'un lane rendent les scénarios flexibles et réutilisables. Un lane accepte des paramètres via le hash options, transmis lors de l'exécution depuis la ligne de commande : fastlane deploy scheme:AppStore version:2.1.0. À l'intérieur du lane, les paramètres sont accessibles via options[:scheme] et options[:version].

Pour les paramètres obligatoires, vérifiez la présence de la valeur au début du lane et appelez UI.user_error! avec un message explicite. Pour les paramètres facultatifs, définissez des valeurs par défaut via l'opérateur ||. Fastlane prend également en charge les paramètres typés via la méthode options avec indication du type, de la valeur par défaut et de la description.

# Lane avec traitement de paramètres
lane :deploy do |options|
  scheme = options[:scheme]
  version = options[:version] || '1.0.0'
  beta = options[:beta] || false

  UI.user_error!("Scheme non spécifié") unless scheme

  match(type: beta ? 'adhoc' : 'appstore')
  gym(scheme: scheme, export_method: beta ? 'ad-hoc' : 'app-store')

  if beta
    pilot(distribute_external: true)
  else
    deliver(submit_for_review: true)
  end
end

# Exécution : fastlane deploy scheme:MyApp beta:true version:2.1.0

Pour travailler avec des variables d'environnement dans un lane, utilisez ENV['VARIABLE_NAME']. Fastlane charge automatiquement les fichiers .env du répertoire fastlane. C'est la méthode standard pour transmettre des données sensibles — clés API, mots de passe et tokens — dans l'environnement CI/CD sans les stocker dans le Fastfile.

Validation des paramètres

Pour un fonctionnement fiable d'un lane, la validation des paramètres en entrée est nécessaire. Utilisez UI.user_error! avec une description du problème si un paramètre obligatoire est absent ou a un type incorrect. Fastlane fournit la méthode options, qui permet de définir le type (String, Boolean, Integer, Array), la valeur par défaut et la description pour chaque paramètre — la validation est effectuée automatiquement au lancement du lane.

Vous pouvez également utiliser des vérifications via le bloc verify : verify do |value| value.length > 0 end pour les paramètres de type chaîne. En cas de format incorrect, Fastlane affiche un message clair indiquant le format attendu et la valeur fournie, ce qui facilite le débogage dans l'environnement CI/CD.

Regroupement des lanes : before_all, after_all et gestion des erreurs

Fastlane fournit des hooks de cycle de vie pour exécuter du code avant et après chaque lane. Le bloc before_all s'exécute avant chaque lane sur une plateforme donnée ou globalement. Le bloc after_all s'exécute après la fin réussie d'un lane. Le bloc error s'exécute en cas d'erreur dans un lane.

Les hooks permettent de centraliser la logique répétitive : installation des dépendances dans before_all, envoi de notifications dans after_all, nettoyage des fichiers temporaires et notification des erreurs dans le bloc error. Cela réduit la duplication de code et rend les lanes plus propres.

# Hooks de cycle de vie des lanes
default_platform(:ios)

before_all do
  cocoapods(try_repo_update_on_error: true)
  ensure_git_status_clean
end

after_all do |lane|
  slack(message: "Lane #{lane} terminé avec succès")
end

error do |lane, exception|
  slack(
    message: "Lane #{lane} a échoué avec l'erreur : #{exception}",
    success: false
  )
end

lane :deploy do
  match(type: 'appstore')
  gym(export_method: 'app-store')
  deliver
end

Le bloc error reçoit deux arguments : le nom du lane (symbol) et l'objet d'exception. À l'intérieur du bloc, vous pouvez envoyer une notification dans Slack, écrire un journal dans un fichier ou lancer un scénario de récupération alternatif. Si le bloc error se termine avec succès, Fastlane ne considère pas la build comme échouée au niveau CI/CD.

Private lanes et réutilisation

Private lane — est un lane déclaré via private_lane au lieu de lane, qui n'apparaît pas dans la liste des commandes disponibles et ne peut pas être lancé directement depuis le terminal. Les private lanes sont conçus pour encapsuler des étapes répétitives appelées depuis plusieurs lanes publics.

Les private lanes sont particulièrement utiles pour les séquences complexes d'actions qui doivent être exécutées dans un ordre strictement défini. Par exemple, un private lane :setup_signing peut être appelé depuis les lanes :build_dev, :build_staging et :build_production avec différents paramètres, mais n'a pas de sens en tant que commande séparée.

# Private lanes pour la réutilisation
private_lane :setup_environment do |options|
  cocoapods(try_repo_update_on_error: true)
  match(type: options[:type], readonly: true)
  increment_build_number
end

lane :dev_build do
  setup_environment(type: 'development')
  gym(export_method: 'development')
end

lane :appstore_build do
  setup_environment(type: 'appstore')
  gym(export_method: 'app-store')
  deliver
end

Les private lanes peuvent appeler d'autres private lanes, formant une hiérarchie d'abstractions. Il est recommandé de limiter la profondeur d'imbrication à 2–3 niveaux pour préserver la lisibilité du Fastfile. Documentez chaque private lane avec un commentaire décrivant son objectif et les paramètres attendus.

Exemples de lanes pour iOS et Android

Examinons des exemples pratiques de lanes pour des projets iOS et Android. Les lanes iOS utilisent généralement scan pour les tests, match pour les certificats, gym pour la compilation et pilot ou deliver pour la livraison. Les lanes Android utilisent gradle pour la compilation, supply pour la publication et firebase_test_lab pour les tests dans le cloud.

// Lane pour CI/CD complet d'application iOS
lane :ci_full_ios do
  scan(scheme: 'App', code_coverage: true)
  gym(scheme: 'App', export_method: 'app-store')
  pilot(distribute_external: true)
  slack(message: 'CI/CD iOS terminé avec succès')
end

/* Lane pour CI/CD complet d'application Android */
lane :ci_full_android do
  gradle(task: 'testReleaseUnitTest')
  gradle(task: 'bundleRelease')
  supply(track: 'internal')
end

En combinant les lanes pour iOS et Android, vous pouvez créer un processus CI/CD unifié pour une application multiplateforme. Utilisez les blocs de plateforme platform :ios et platform :android pour regrouper les lanes spécifiques à chaque plateforme, et appelez-les depuis un lane orchestrator commun qui gère l'ordre d'exécution.

Meilleures pratiques pour l'écriture de lanes

Lors de l'écriture de lanes, il est recommandé de suivre un ensemble de pratiques qui assurent la lisibilité, la maintenabilité et la fiabilité des scénarios. La première règle — chaque lane doit effectuer une seule tâche. Si un lane fait trop de choses, divisez-le en plusieurs lanes et private lanes.

Deuxième règle — le nommage des lanes doit être un verbe ou une phrase verbale : build, deploy, test, upload_screenshots. Évitez les noms abstraits comme process ou do_all. Utilisez des tirets bas pour séparer les mots dans le nom du lane.

Troisième règle — gérez les erreurs explicitement. Utilisez UI.user_error! pour des messages compréhensibles sur les problèmes. Ne vous fiez pas aux messages d'erreur standard de Fastlane — donnez au développeur le contexte : Fichier GoogleService-Info.plist introuvable — ajoutez-le au projet au lieu de File not found.

Quatrième règle — testez les lanes localement avant de les lancer sur le CI/CD. Fastlane prend en charge le mode dry-run via le flag --dry-run, qui montre quelles actions seront exécutées sans les lancer réellement. Utilisez fastlane run_test pour tester isolément des lanes individuels avant l'intégration.

Documentation des lanes

La documentation de chaque lane est une pratique importante pour le développement en équipe. Fastlane prend en charge la génération automatique de documentation à partir du bloc desc placé avant la déclaration du lane. Le texte de desc s'affiche lors de l'exécution de fastlane lanes et fastlane list, aidant les développeurs à comprendre l'objectif de chaque scénario sans lire le code source du Fastfile.

Pour documenter les paramètres, utilisez les commentaires Ruby avec une description des valeurs attendues. Fastlane peut générer un README.md avec la liste complète des lanes et leur description via la commande fastlane generate_docs, ce qui facilite l'adaptation des nouveaux membres de l'équipe aux processus CI/CD du projet.