Normalement chaque membre d'une équipe travaille dans son propre plan de travail individuel, à l'écart des autres. Il peut éventuellement souhaiter partager son travail avec les autres et se procurer les modifications de ses coéquipiers. Pour ce faire, il utilise les flux.
Les flux sont les endroits où une équipe partage et intègre son travail en cours.
Un flux peut être considéré comme un espace de travail partagé mis à jour par des membres d'une équipe à mesure qu'ils modifient le projet. Ce modèle permet à des individus de travailler sur un projet d'équipe, de partager leur travail avec d'autres à mesure des modifications et d'accéder au travail des autres tandis que le projet évolue.
A mesure de l'avancement de leur travail, les membres d'une équipe partagent ce travail en le publiant dans le flux. De même, lorsqu'ils souhaitent récupérer les derniers travaux effectués disponibles, ils les intègrent aux modifications du flux. Le flux se modifie donc en permanence, à mesure que les membres de l'équipe y enregistrent leurs nouveaux travaux.
Le flux correspond réellement à l'état en cours du projet. A tout moment, un membre de l'équipe peut intégrer des modifications du flux sachant qu'elles sont toujours à jour.
Modèle de programmation en équipe
Les systèmes de contrôle de version offrent deux fonctionnalités importantes requises pour travailler dans une équipe :
un historique du travail soumis par l'équipe
un moyen de coordonner et d'intégrer ce travail.
Conserver un historique est essentiel pour pouvoir comparer le travail en cours au travail précédemment effectué, revenir à un travail précédent mieux fait, etc. La coordination du travail est primordiale de façon à disposer d'une définition de l'état en cours du projet, intégrant le travail de l'équipe. Le modèle de flux permet d'effectuer cette coordination.
Un modèle optimiste est un modèle dans lequel chaque membre de l'équipe peut apporter des modifications à toute ressource à laquelle il peut accéder. Deux membres d'une équipe pouvant publier dans le flux des modifications apportées à la même ressource, des conflits que vous devrez régler peuvent se produire. Ce modèle est dit optimiste car il engendre peu de conflits.
En général, une ressource n'est pas un élément isolé. Elle contient des dépendances implicites ou explicites à d'autres ressources. Par exemple, des pages Web sont liées à d'autres pages Web et du code source contient des références à des artefacts décrits dans d'autres ressources de code source. Une ressource n'est pas un élément isolé.
La publication des ressources sur le flux peut affecter ces dépendances. Il est important de garantir l'intégrité des dépendances car le flux représente l'état en cours du projet : à tout moment, un membre de l'équipe doit pouvoir utiliser le contenu du flux comme base d'un nouveau travail.
Le flux idéal des opérations est donc celui dans lequel l'intégrité du flux est préservée.
L'enchaînement idéal des opérations est le suivant :
Démarrer sur une base saine : Avant de commencer, récupérez l'état en cours du projet. Si vous êtes sûr de ne pas avoir en local de travaux qui vous tiennent à coeur, la méthode la plus rapide consiste à sélectionner dans le flux les projets qui vous intéressent, puis à sélectionner "Ajouter à l'espace de travail". Cette opération remplace l'intégralité de vos ressources par celles du flux.
Effectuer les modifications : Travaillez localement dans votre plan de travail en créant des ressources, en modifiant celles existantes et en sauvegardant au fur et à mesure.
Synchroniser : Lorsque votre travail est prêt pour publication, effectuez une synchronisation avec le flux.
Intégrer les modifications : Examinez les modifications entrantes et ajoutez-les dans votre plan de travail local. Cette opération permet de déterminer la présence de modifications risquant de nuire à l'intégrité des éléments à publier. Traitez les conflits. Testez de nouveau et effectuez des vérifications d'intégrité (par exemple, vérifiez qu'aucun lien hypertexte n'est brisé, que le code a bien été compilé, etc.).
Publier : Une fois que vous êtes sûr que vos modifications sont intégrées au contenu de flux le plus récent, publiez-les dans le flux. Par prudence, répétez l'étape 4 si vous supposez la présence de nouvelles modifications entrantes.
Bien entendu, il s'agit là d'un enchaînement idéal des opérations. Dans certains cas vous êtes sûr que les modifications entrantes n'affecteront pas votre travail et vous pouvez publier sans effectuer d'intégration des modifications. Mais les membres d'une équipe doivent toutefois faire l'effort de suivre approximativement l'enchaînement d'opérations décrit ci-dessus afin de préserver l'intégrité du flux.