Comment 'git build' a remplacé Jenkins

Si vous en avez assez de maintenir votre usine logicielle, pourquoi ne pas assurer l'intégration continue à la source sur le poste du développeur ?

Si la complexité et le temps de build et de test vous le permet, alors vous pouvez déplacer la contrainte du passage des tests avant le partage du code.
Et vous pouvez donc ajouter une nouvelle commande à git: git build !

Principe

Ce principe est connu sous le nom de “build incassable”. On en trouve des traces dans un thread datant de 2004, avec une mise en application plus récente.
Voici les étapes avec git:

1. À configurer: la commande de build de votre clone local:

   # Exemple de configuration de la commande de build pour un projet java.
   git config private-build.command "mvn clean install"
   

   Cette commande est spécifique pour chaque repo cloné.
2. Produire un commit dans le repo initial s'il existe des changements non commités afin de rebaser les changement du repo distant
3. Faire un clone local temporaire
4. Lancer le build dans le temporaire
5. Pusher les changements
6. Appliquer ces changements dans le repo initial

Le script

git-build.sh

Installation

Ajouter juste le script à votre PATH.
Par exemple, sous GNU/Linux, vous pouvez le déposer dans /usr/local/bin/git-build, il sera disponible automatiquement dans le shell.
Le nom du script suit la syntaxe "git-{commande}" il est donc possible de l'invoquer par git build. La complétion est aussi activée !
Il fonctionne aussi sur mac. Il n'est pas compatible en l'état avec Microsoft Windows.

Références

• Gist de David Gageot
• Tweet de mise à jour pendant Devoxx
• Projet de Evgeny Mandrikov
• Compte-rendu de la soirée Git et Astuces (Alpes JUG)

Avantages

• Si vous utilisez un IDE comme eclipse par exemple, comme votre workspace n'est plus l'endroit où vous buildez et passez les tests avant le push, vous pourrez commencer à travailler sur votre prochain commit sans interférence.
• Vous gardez du feedback sur le déroulement du processus grâce aux contrôles d'erreurs qui parsèment le script et aux notifications qui en découlent: notify-send sous GNU/Linux et growlnotify sous Mac.
• Lorsque tous les membres de l'équipe appliquent le script, vous pouvez en théorie vous passer d'usine d'intégration continue puisque n'est partagé que le code “vert”. Dans la pratique, on peut garder une usine logicielle pour faire du déploiement continu en production par exemple.

Par extension, on pourrait aussi se donnner un git release pour releaser une version à déployer. Voire même un git prod pour pousser en production aussi régulièrement qu'on commit (avec le git rollback qui va avec si on casse la production pour ne pas effrayer ses testeurs ou ses ops).
Et sinon, l'intégration continue a 14 ans cette année. C'est donc un concept qui est n'est pas réçent à l'échelle de l'informatique.

---