Un linter est un outil qui analyse votre code source pour signaler les erreurs de programmation, les bugs, les erreurs de style etc (source: Wikipedia).

Il y a plusieurs raisons d’utiliser des linters: Il est plus efficace de détecter les erreurs de syntaxe. Il n’est pas nécessaire de déboguer des erreurs simples comme les fautes de frappe – le linter le fait pour vous. L’ensemble de la base de code ressemble à une seule personne. Les programmeurs peuvent se concentrer sur la résolution des problèmes, au lieu de nettoyer le code. Vous pouvez trouver des linters pour la plupart des langages de programmation, par ex. Rubocop pour Ruby ou ESLint pour JavaScript.

Il existe aussi de nombreuses façons d’intégrer un linter dans votre workflow:

  • plugin de votre éditeur de texte
  • Les Github Actions
  • Les Github apps

C equi va nous intéresser dans cet article aujourd’hui sont les Github Actions. Mais avant, découvrons ce qu’est l’intégration continue et le déploiement continue.

NB: Bien que ces deux types d’intégrations aient des diiférences, leur atout principal de faciliter la vie aux développeurs en automatisant les processus ennyeux et détaillés. En gros, ils vous permettent de corriger les détails de syntaxe et d’organisation de code sans foutre en l’air votre branche de production

L’intégration continue

Elle se concentre sur la construction du code à publier plus rapidement, mais ne définit pas quand il sera publié sur la branche de production. Bien que cette approche soit fortement influencée par les méthodologies agiles, il est également possible de mener un projet en livrant une nouvelle version de l’application, une fois par an. Ce ne serait pas sage, mais c’est possible.

De plus, quelqu’un doit encore être responsable de valider les nouvelles versions de l’appli, et de les rendre disponible au public. C’est un moyen plus sûr de travailler sur des applications qui doivent être peaufinées et qui seront mises à la disposition d’un grand groupe d’utilisateurs. Les logiciels de comptabilité destinés aux petites et moyennes entreprises ou une application de marché B2C en sont de bons exemples.

L’intégration continue (ou CI en anglais)

Celui-ci se concentre sur la mise en production directe de tous les changements. Avec tous les tests et la livraison automatisés, le déploiement est transformé en flux plutôt qu’en un lot de modifications pour intégrer le code. Dans l’idéal, le code est en constante évolution, des tests automatisés évitent les plantages et les utilisateurs bénéficient de nouvelles fonctionnalités tous les jours, voire toutes les heures. L’approche fonctionne bien lorsque le besoin d’un travail continu ou d’une stabilité n’est pas si critique. Les applications d’entreprise internes prenant en charge le travail quotidien en sont un excellent exemple.

Les Gitrhub Actions

Les Github Actions sont un service de CI/CD offert par GitHub. Ils vous permettent d’automatiser votre WorkFlow, en laissant GitHub s’occuper d’un nombre de tâches qui peuvent être déclenchées par différents événements sur la plateforme.

Comment intégrer les Github Actions dans votre projet

Créez un dossier workflows dans le dossier .github (que vous pouvez ajouter à la racine de votre projet). GitHub localisera les fichiers YAML à l’intérieur du dossier.github/workflows.

Maintenant, à chaque pull prequest, vous remarquerez au bas de page une section linters check dans laquelle les linters parcourront tous les dossiers de votre projet et les fichiers de code et afficheront les éventuels erreurs de code, comme ci-dessous

les linters

Il vous suffit de les corriger et de d’envoyer vos commits sur la même branche, et un nouveau check sera déclenché. La vie n’est pas belle ?

Alors, dites moi utilisez-vous plus souvent les linters et CD/CI dans votre workflow ? Si oui, lesquels ?

 

Sources:

 

Vous êtes libre de recevoir mon cours gratuit sur les fondations du coding et le problem solving

* indicates required