Monster builds


Publié par
Alexandre ALQUIER

23 juin 2010

On parle ici de builds comme celui de JIRA, qui, avant que des mesures d’amélioration ne soient prises, prenait entre 30 et 60 heures à s’exécuter. Dans un cas comme celui-ci, la perte de vélocité de l’équipe de développement qu’entraîne le temps de build est souvent la principale raison pour chercher des pistes d’amélioration.

1. Optimisation

La première chose à faire est d’optimiser le build en capturant le « profil » de celui-ci. On analyse le processus de build pour savoir où celui-ci passe le plus de temps. Il est alors possible d’optimiser le build pour lui éviter les opérations inutiles ou des goulots d’étranglement. Pour Ant, un outil est disponible à l’adresse https://antutility.dev.java.net/.

2. Compatibilité

Un moyen très simple de réduire le temps d’un build est de réduire la taille de la matrice de compatibilité du projet. On entend par « matrice de compatibilité », un matrice contenant les combinaisons possible de configuration supportée pour le navigateur, le JDK, la base de données… Celle-ci a impact direct sur le temps d’exécution d’un build, puisque le nombre de cas de tests est directement proportionnel à sa taille.

3. Planification

La bonne planification des builds est très importante. Elle doit se faire en fonction du temps d’exécution des builds. On planifiera par exemple une compilation chaque heure, l’exécution des tests unitaires deux fois par jour et des tests fonctionnels chaque nuit.

4. Parallélisme

Si le ratio <temps de test>/<temps de build> est important, il est intéressant de paralléliser les tests. Par exemple, si un projet comporte 45 cas différents dans sa matrice de compatibilité, on pourra diviser le build en 15 plans à exécutés en parallèle, qui compileront chacun l’application en entier mais n’effectueront que 3 cas de tests chacun.

Pour en savoir plus: http://www.atlassian.com/summit/2010/presentations/development-speed/monster-builds-how-to-tame-them.jsp