Retour aux articles
3 min de lecture

Taskfile pour l'automation de projet

Task runner avec docs intégrées, descriptions, et syntaxe YAML.

DevExAutomationTools

Les Makefiles marchent. Je les utilise depuis des années. Mais la DevEx est restée bloquée en 1976.

Taskfile te donne la même automation avec des descriptions de tâches, de l’aide intégrée, et du YAML au lieu de l’enfer des tabulations. C’est ce que Makefile aurait dû devenir!

Ce que les Makefiles font mal

Lance make dans la plupart des projets et t’as soit une erreur, soit ça build un truc random. Lance make help et rien se passe à moins que quelqu’un ait écrit une target custom avec grep et awk.

Les descriptions de tâches? Tu les écris en commentaires en espérant que quelqu’un lise le fichier. Les dépendances entre tâches? Ça marche, mais la syntaxe ressemble à du bruit de ligne.

Les Makefiles sont super pour ce qu’ils font. Mais la découvrabilité est terrible.

Taskfile corrige les problèmes de DevEx

Lance task sans arguments et t’as une liste des tâches disponibles avec leurs descriptions. Lance task --list et tu vois tout organisé!

Chaque tâche a une description. Tu sais ce qu’elle fait avant de la lancer.

version: '3'

tasks:
  dev:
    desc: Démarre le serveur de dev
    cmds:
      - npm run dev

  test:
    desc: Lance la suite de tests
    cmds:
      - pytest tests/

  deploy:
    desc: Déploie en production
    deps: [test, build]
    cmds:
      - ./scripts/deploy.sh

Pas de tabulations qui cassent. Pas de syntaxe spéciale à retenir. Juste du YAML qui fait ce que t’attends.

Utilise-le comme point d’entrée du projet

J’organise mes projets avec un Taskfile.yaml à la racine et des scripts dans tasks/. Taskfile devient le point d’entrée, les scripts font le vrai boulot.

project/
├── Taskfile.yaml
├── tasks/
│   ├── setup.sh
│   ├── deploy.py
│   ├── backup.nu
│   └── check.sh
├── src/
└── tests/

Ton Taskfile.yaml appelle juste les scripts:

version: '3'

tasks:
  setup:
    desc: Initialise l'environnement de dev
    cmds:
      - bash tasks/setup.sh

  deploy:
    desc: Déploie l'application
    cmds:
      - python tasks/deploy.py {{.ENV}}

  backup:
    desc: Sauvegarde la base de données
    cmds:
      - nu tasks/backup.nu

  check:
    desc: Vérifie la santé du système
    cmds:
      - bash tasks/check.sh

Les scripts peuvent être dans n’importe quel langage. Bash pour le système, Python pour la logique, Nushell pour traiter les données. Taskfile s’en fout. Il les lance juste!

Pourquoi cette structure marche

Les scripts deviennent complexes. Taskfile les garde organisés et découvrables.

Les nouveaux devs lancent task et voient ce qui est disponible. Pas besoin de chasser dans les scripts bash ou lire les README!

Tu peux tester les scripts indépendamment. Lance bash tasks/setup.sh direct si t’as besoin de debug. Taskfile c’est juste le point d’entrée.

Les dépendances marchent comme tu t’y attends:

tasks:
  build:
    desc: Build l'application
    cmds:
      - bash tasks/build.sh

  test:
    desc: Lance les tests
    deps: [build]
    cmds:
      - bash tasks/test.sh

  deploy:
    desc: Déploie en production
    deps: [test]
    cmds:
      - python tasks/deploy.py

Lance task deploy et ça lance build, puis test, puis deploy. Propre et prévisible!

Variables et templating

Passe des variables à tes tâches:

tasks:
  deploy:
    desc: Déploie vers un environnement
    cmds:
      - python tasks/deploy.py --env={{.ENV}}

  logs:
    desc: Affiche les logs d'un service
    cmds:
      - bash tasks/logs.sh {{.SERVICE}}

Appelle avec task deploy ENV=prod ou task logs SERVICE=api.

Tu peux définir des valeurs par défaut:

tasks:
  deploy:
    desc: Déploie vers un environnement
    vars:
      ENV: staging
    cmds:
      - python tasks/deploy.py --env={{.ENV}}

Répertoires spécifiques par tâche

Lance les tâches depuis des répertoires spécifiques:

tasks:
  frontend:
    desc: Démarre le serveur de dev frontend
    dir: frontend/
    cmds:
      - npm run dev

  backend:
    desc: Démarre le serveur backend
    dir: backend/
    cmds:
      - go run main.go

La tâche change de répertoire avant de s’exécuter. Plus propre que des cd dans les scripts!

Tâches silencieuses et contrôle de l’output

Certaines tâches sont bruyantes. Contrôle l’output:

tasks:
  install:
    desc: Installe les dépendances
    cmds:
      - npm install
    silent: true

  status:
    desc: Vérifie le statut des services
    cmds:
      - task: check-db
      - task: check-api
    silent: true

  check-db:
    cmds:
      - bash tasks/check-db.sh

  check-api:
    cmds:
      - bash tasks/check-api.sh

Quand utiliser Makefiles à la place

Si tu build du C, du C++, ou n’importe quoi qui nécessite un vrai tracking de dépendances basé sur les timestamps de fichiers, utilise Make. C’est fait pour ça!

Taskfile c’est pour lancer des commandes, pas tracker les dépendances de fichiers sources. Il sait pas si un fichier a changé. Il lance juste des tâches.

Pour l’automation de projet, les workflows de dev, et les scripts de déploiement, Taskfile gagne sur la DevEx.

Commencer

Installe-le:

# macOS
brew install go-task

# Linux
sh -c '$(curl --location https://taskfile.dev/install.sh)' -- -d -b ~/.local/bin

# Ou utilise ton gestionnaire de paquets

Crée un Taskfile.yaml:

version: '3'

tasks:
  hello:
    desc: Dit bonjour
    cmds:
      - echo 'Bonjour de Taskfile'

Lance task hello. C’est tout!

Commence à déplacer tes scripts dans tasks/ et référence-les depuis Taskfile.yaml. Ton projet devient instantanément plus découvrable.

Bref

Tu peux faire la même chose avec Make. Les Makefiles marchent super, c’est battle-tested, installé partout, et si tu connais la syntaxe, c’est rapide à écrire.

Taskfile a de la doc intégrée et de la syntaxe YAML. C’est tout. Make reste super!

La réalité est souvent plus nuancée. Moi, la nuance ça m'ennuie. Je préfère la clarté.

Commentaires