Votre projet est maintenant sur un système de contrôle de source. Cela signifie que la gestion de plusieurs versions de votre logiciel, le suivi des modifications et l’intégration des corrections ou des nouvelles fonctionnalités sont désormais beaucoup plus simples.
Pourquoi ne pas profiter également de l’intégration continue ?
A partir de 4D v19, vous pouvez lancer la compilation de votre projet avec une commande. Ainsi, vous disposez désormais de toutes les briques nécessaires pour automatiser votre chaîne d’intégration.
Ce billet de blog vous donnera un exemple d’automatisation avec le gestionnaire GitHub et les actions GitHub.
Qu’est-ce qu’une action GitHub ?
Les actions GitHub vous permettent d’automatiser des tâches. Elles sont déclenchées par des événements tels que la soumission d’un code.
Pourquoi des actions GitHub ?
L’automatisation des flux de travail est une nécessité dans le monde du développement logiciel d’aujourd’hui. Les équipes de développement utilisent des serveurs CI/CD pour automatiser les processus d’intégration et de déploiement continus (CI/CD) dans leur cycle de vie logiciel.
Les actions GitHub permettent aux utilisateurs de construire, tester et livrer leur code directement à partir de GitHub sans utiliser un serveur externe tel que Jenkins ou TeamCity. GitHub héberge des machines virtuelles sur les systèmes d’exploitation Linux, Windows et macOS.
Comment utiliser les actions GitHub ?
Vous devez créer un flux de travail. Un workflow est une procédure automatisée que vous ajoutez à votre référentiel. Dans l’onglet action, vous pouvez en choisir un dans le catalogue de flux de travail ou créer le vôtre.
Dans cet exemple, nous utilisons le « simple workflow » proposé par Github :
Cela a créé un script dans le dossier « .github/workflows » de notre dépôt. Dans ce script, vous pouvez définir :
- l’événement déclencheur : sur push/pull/schedule
- l’OS de la machine virtuelle :runs-on
- …
Pour plus de détails sur les syntaxes et les possibilités, jetez un œil à la documentation GitHub.
Ensuite, nous modifions le fichier README.md de notre référentiel, qui déclenche le workflow. Dans l’onglet action, la modification est visible, le workflow est dans une file d’attente :
Voilà ! Le script a été exécuté.
Nous avons maintenant accès aux informations de l’OS, et à la machine virtuelle utilisée, en vérifiant si elle correspond à la configuration que nous avons demandée.
Tous les logs de notre script sont maintenant visibles :
Exemple concret
Maintenant que nous avons vu comment créer et configurer des actions GitHub, voici un workflow créé par Eric Marchand.
Eric est l’un des développeurs de notre équipe 4D pour iOS. Il a développé plusieurs actions git pour son propre usage, utilisées sur un serveur GitLab pour nos dépôts privés et sur GitHub pour le dépôt public.
Voici un exemple de la façon de compiler un projet et de publier la version sur GitHub :
Tout d’abord, nous avons un projet 4D avec du code partagé qui compile les autres projets passés en paramètres lors du lancement (avec un script bash sur macOS runner). Ce projet convertit les erreurs de compilation au format log GitHub. Il est stocké sur un dépôt Github contenant des actions telles que la compilation, la génération d’une version, etc. Ces actions peuvent ensuite être utilisées dans n’importe quel autre projet.
Deuxièmement, pour exécuter le projet et donc appeler une action telle que la compilation, nous devons exécuter une application 4D. Une application 4D peut être téléchargée sur un serveur. Elle doit être installée et exécutée sur les serveurs GitHub. Vous devrez ajouter la clé SERVER_URL dans le paramètre« Action Secret » de votre référentiel pour chaque projet.
Enfin, vous créez des workflows déclenchés par une pull request dans vos projets, qui appelle le workflow « build » de votre dépôt « action centralisée ».
Retrouvez le référentiel avec la base et les différents workflows et un exemple d’intégration dans un projet.
Faites-nous part de vos commentaires en rejoignant la conversation sur le Forum 4D!