Pourquoi il est important de bien choisir son workspace lors d’une build
Le workspace d’une build est le passage obligé lors de sa création. SI il est mal fait, la build ne pourra pas être utilisée à 100% de ses capacités.
Prenons un exemple avec le source suivant:
Il y a 2 applications: App_X et App_Y. J’ai configuré 2 builds quasiment identiques pour App_X:
Ces 2 builds ont que leurs workspaces de different:
Ces 2 builds feront exactement la même chose tant qu’elles seront lancées manuellement. Une première différence peut apparaître au lancement car la build possède la tâche suivante:
S’il y a beaucoup de fichiers, la première build sera donc plus longue et surtout si un label est posé, il le sera sur tout le source: ce qui ne sera pas très pratique lorsque l’on voudra récupérer le source de App_X posé sur cette build: on récupérera aussi celui de App_Y! Imaginons maintenant que l’on veuille que les builds soient en mode intégration continue, c’est à dire qu’à chaque check-in du projet la build se lance. Les 2 builds vont avoir un comportement différent.
C’est pas magique: la seule façon de savoir quelle build doit être lancée à chaque check-in et de confronter les fichiers du changeset, et les workspaces des builds. Si un des fichiers est compatible avec le workspace de la build, cette build est lancée. Modifions maintenant un fichier du projet App_Y. Il se passe la chose suivante: la build App_X est activée alors que l’on n’a pas du tout modifié le project App_X et la build App_X_2 n’est bien sur pas lancée:
Ces quelques secondes passées à la définition du workspace font donc toute la différence!
End of line
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
