Avec une équipe mobile en pleine croissance et des versions hebdomadaires, il est essentiel de disposer d'un pipeline CI fiable. Nous devons être en mesure de créer et de tester nos applications, puis de les déployer sur l'App Store et le Google Play Store. Nous conservons également des versions préliminaires internes afin de tester les dernières fonctionnalités.
Découvrez comment nous utilisons ClickUp, Fastlane et GitHub Actions pour automatiser notre intégration continue (CI) et notre livraison continue (CD).
La vie d'un bug 🐜
Commençons par passer rapidement en revue notre processus de gestion et de correction des bugs.
- Un bug (ou une demande de fonctionnalité) est signalé et une tâche est créée dans ClickUp.
- La tâche est attribuée à un développeur et fixée dans une PR par rapport à la branche de staging.
- La CI exécute tous les tests, construit l'application, déploie un aperçu web et télécharge tout vers la tâche ClickUp.
- Notre équipe d'assurance qualité vérifie la correction et, si elle est satisfaisante, la tâche est marquée comme terminée.
- La PR est automatiquement fusionnée dans l'étape de test.
- La branche de staging est créée et déployée sur notre TestFlight interne.
- Chaque mercredi, une branche de publication est créée, développée et testée.
- Le vendredi, nous créons une version sur GitHub et la CI la déploie sur l'App Store et le Play Store.
Une tâche ClickUp contient toutes les informations relatives au bug. Nous utilisons des statuts personnalisés tels que « En cours » ou « Révision du code » pour suivre le bug. Les flux de travail CI modifient automatiquement le statut. Les champs personnalisés contiennent des informations supplémentaires telles que la personne qui a signalé le bug, celle qui travaille dessus, la date de publication, etc.
Flux de travail PR 📜
Les deux premières étapes décrites ci-dessus ne sont pas vraiment liées à l'intégration continue, mais la troisième a un intérêt...
Notre flux de travail de développement s'applique à toutes les PR. Il vérifie les lints, le formatage et exécute tous les tests avant de commencer à créer les artefacts Android et iOS.
Lorsqu'une compilation est réussie, la CI publie un message dans la tâche liée. Les ingénieurs QA peuvent se rendre sur le PR, télécharger les artefacts de compilation ou utiliser l'aperçu Web.
Un message CI automatisé publié dans la tâche ClickUp liée après une réussite de compilation.
Configuration de Flutter sur le CI Runner 🛠
Nous utilisons l'action GitHub bien connue subosito/flutter-action pour configurer Flutter sur la CI. Par défaut, elle installera la dernière version stable de Flutter. Pour éviter de perturber vos flux de travail CI lors de la sortie d'une nouvelle version de Flutter, vous devez spécifier la version manuellement.
Si vous avez plusieurs flux de travail, il est préférable de stocker la version Flutter dans un fichier. Nous utilisons FLUTTER_VERSION à la racine du référentiel.
Une autre solution simple consiste à stocker la version Flutter en tant que secret GitHub et à y accéder à l'aide de {{ secrets. FLUTER_VERSION }}.
Aperçu Web 🕸
Grâce à la capacité de Flutter à fonctionner sur le Web, nous pouvons créer un aperçu Web entièrement fonctionnel des demandes de tirage. À l'aide du package device_preview, la taille et les paramètres de l'appareil peuvent être ajustés.
La prévisualisation s'est avérée très utile et n'est pas seulement utilisée par notre équipe d'assurance qualité. Les concepteurs et les chefs de produit l'apprécient également pour itérer rapidement sur de nouvelles fonctionnalités.
via Flutter
Comment créer un aperçu Web 🐶
Pour commencer, assurez-vous que votre application est compatible avec Flutter web, car toutes les API ne sont pas prises en charge.
Dans notre application, par exemple, nous avons dû désactiver les notifications push et les sockets Web.
Cet exemple de flux de travail crée un aperçu Web de votre application Flutter et le télécharge dans un compartiment S3. Nous utilisons une variable d'environnement ENABLE_DEVICE_PREVIEW pour désactiver device_preview en production.
L'étape Fix base href est nécessaire car l'aperçu ne se trouvera pas à la racine du compartiment.
Et quelques lignes de code pour activer de manière conditionnelle le device_preview.
Les variables d'environnement sont un outil puissant qui permet à l'algorithme de tree shaking de Flutter de supprimer le code de débogage pour les versions finales.
Fastlane 💨
Fastlane simplifie considérablement la création, la signature et le déploiement des applications Flutter. Il gère nos certificats, nos profils d'approvisionnement et d'autres paramètres. Nous utilisons les secrets GitHub pour stocker les mots de passe et les jetons en toute sécurité.
Actions Fastlane utiles :
- fastlane match pour créer et stocker des clés et des profils iOS dans un référentiel GitHub
- build_app pour créer des applications iOS et Android
- upload_to_testflight et livrer pour déployer les versions iOS
- upload_to_play_store pour déployer les versions Android
Échantillon de build de développement iOS 🍏
N'oubliez pas setup_ci, cela vous évitera des erreurs étranges 👾. En savoir plus sur Fastlane pour les applications Flutter.
Signature Android 🔒
La manière la plus simple de signer en toute sécurité les versions Android consiste à stocker les jetons sous forme de secrets GitHub et à utiliser des variables d'environnement et une clé temporaire. jks créés par la CI :
Nous stockons la clé .jks sous forme de chaîne codée en base64 dans GitHub Secrets et la décodons dans le flux de travail :
Flux de travail de publication et de production 🚀
Le flux de travail de pré-lancement s'exécute pour les branches qui commencent par release/v. Il supprime tout le code de débogage et interne afin de garantir que nous testons le même code que celui qui sera lancé.
De plus, le flux de travail de pré-lancement publie des messages sur différents canaux Slack afin d'informer les équipes d'assurance qualité et de marketing d'une nouvelle version à l'aide de webhooks entrants.
Une fois que tout a été testé de manière approfondie, nous créons une version sur GitHub qui déclenche le flux de travail de production. Elle compile et signe l'application avec des certificats de production, puis l'envoie à l'App Store.
Plus d'astuces pour votre CI 🦾
Si vous utilisez le déclencheur push pour GitHub Actions, vous risquez de rencontrer des problèmes en cas de poussées multiples successives vers la même branche. Plusieurs instances du flux de travail seront lancées, ce qui ralentira la compilation ou causera d'autres problèmes.
- Nous vous recommandons d'utiliser l'action « Annuler le flux de travail » pour annuler toutes les instances précédentes du flux de travail.
- Si vous recherchez une solution simple et facile à maintenir pour générer des nombres de build séquentiels, essayez le générateur de nombres de build. Vous pouvez également utiliser GITHUB_RUN_ID, mais celui-ci ne peut pas être personnalisé.
- Découvrez l'application ClickUp GitHub pour voir les branches, les validations et le statut GitHub directement dans vos tâches ClickUp. Utilisez les automatisations ClickUp ou l'API publique de ClickUp pour des automatisations avancées.
Résumé 🍩
La mise en place de votre CI est un processus amusant. Il est facile de se lancer et vous pouvez le faire évoluer au fur et à mesure. Notre CI s'inspire de l'une des valeurs fondamentales de ClickUp : Progresser vers la perfection. Nous travaillons en permanence à l'amélioration de la CI pour nos équipes d'assurance qualité et d'ingénierie.
La combinaison de ClickUp, GitHub Actions et Fastlane est très puissante et permet de créer un pipeline CI/CD flexible et entièrement automatisé en moins d'une heure. Essayez-le !
Nous avons de nombreux sujets intéressants en préparation, alors continuez à consulter le blog ClickUp Engineering! 🦄