Une politique courante en pratique Agile est d’avoir un tronc toujours compilable. Cela permet notamment à n’importe quel développeur qui veut reprendre le code de ne pas tomber sur des erreurs de compilation qu’il ne maîtrise pas et qui risquent de l’empêcher de tester ses propres modifications. Par extension, cela permet d’envisager l’utilisation de serveurs d’intégration qui permettent de tester en conditions réelles la compilation, le test et le déploiement du produit.
Un problème courant est de pouvoir vérifier avant enregistrement sur le tronc si la version est correcte. En effet, si le développeur omet par exemple d’ajouter au tronc des fichiers nécessaires, la compilation peut fonctionner sur son poste mais pas sur un autre environnement. Trouver d’où vient la source du problème peut même s’avérer long et fastidieux.
Une solution permettant de s’assurer que le tronc est toujours compilable est de faire intervenir dans le processus d’enregistrement des sources un serveur intermédiaire : le développeur enregistre localement ses modifications, les reporte sur le serveur à partir du gestionnaire de versions. Si la compilation est valide sur le serveur, il peut enregistrer les modifications sur le tronc.
Avec des gestionnaires de versions distibués (Bazaar, Git, Mercurial…), ce processus est facilement envisageable. Le développeur travaille sur son poste avec une branche locale du tronc. Une fois son travail effectué, il enregistre (commit local) les modifications puis les reporte sur le serveur (push). Quand la modification est validée, il peut reporter la modification sur le tronc (push, également).
Le cas de SVN ou des autres types de gestionnaires de versions est plus complexe à envisager. Il faut en effet créer tout d’abord une branche à partir du tronc, branche qui recevra les modifications à valider. Le développeur travaille sur cette branche (checkout, update) et y enregistre ses modifications (commit). Une fois validée, il les récupère à partir du serveur (checkout, update). Quand la modification est validée, il ne reste à faire qu’une fusion entre la branche et le tronc.
En somme, ce processus est adaptable mais nécessite plus d’efforts : les modèles de gestionnaires de versions distribués abstraient les branches et simplifient les passages de modifications entre branches par rapport aux modèles client-serveur. Ces derniers rendent compliquée la tâche de reporter une modification d’une machine à une autre (d’un poste de développeur à un serveur d’intégration, par exemple). De manière générale, un gestionnaire de versions distribué s’adaptera mieux aux processus et politiques de développement.
À lire, au sujet des gestionnaires de versions et des processus :