Le processus commence par une tâche dans votre système de suivi des problèmes ou de gestion de projet : Jira, Bugzilla, Mantis, OnTime ou votre propre solution interne. L'essentiel est que tout ce que vous faites soit associé à une tâche. Qu'il s'agisse d'une nouvelle fonctionnalité ou d'une correction de bogue, créez une tâche à cet effet.

Ensuite, vous créez une branche pour cette tâche.

Nous recommandons une convention de dénomination simple pour les branches : Un préfixe ("tâche" dans l'exemple) suivi du numéro de la tâche dans l'outil de suivi des problèmes. Cela vous permet de conserver une traçabilité complète des modifications.

Travaillez sur la branche des tâches et faites autant de vérifications que nécessaire. Expliquez chaque étape dans les commentaires afin d'éclairer l'examinateur.

Lorsque la tâche est terminée, définissez un attribut "status" sur la branche comme étant "résolu".

Vous pouvez également le marquer comme terminé dans votre outil de suivi des problèmes. Tout dépend de votre ensemble d'outils et de la manière dont vous allez mettre en œuvre le flux de travail.

Une fois que vous avez marqué votre tâche comme étant terminée, elle peut être revue par un collègue.

C'est maintenant au tour du réviseur d'examiner vos modifications et de voir s'il peut repérer des bogues, des erreurs ou des incohérences dans votre style de codage, ou tout aspect de la conception qui devrait être modifié. Si c'est le cas, la tâche est rouverte et le cycle recommence.

La validation est une étape facultative.

Certaines équipes "valident" la tâche - un autre membre de l'équipe effectue un bref test exploratoire pour s'assurer que la nouvelle fonctionnalité ou le changement a un sens. Ils ne recherchent pas les bogues (les tests automatisés s'en chargent), mais examinent le changement du point de vue du client. Le statut peut être défini comme "validé" dans l'attribut.

Configurez votre système d'intégration continue (CI) pour surveiller toutes les branches qui ont un ensemble d'attributs donné. Une branche ne sera prise en compte par le système d'IC que lorsqu'elle atteindra un statut donné (dans ce cas, "validée").

Une fois la tâche révisée/validée, la branche de la tâche est automatiquement testée avant d'être fusionnée dans la branche principale.

Si la suite de tests réussit la fusion, elle sera confirmée et soumise au système CI pour être construite et testée. Ce processus permet d'éviter de casser la construction. En cas d'échec, le processus sera redémarré et vous devrez refaire une base à partir de main pour résoudre les éventuels conflits.

Si les tests sont concluants, la fusion est validée et la branche est prête à être livrée. Remarquez que le statut est maintenant "fusionné".

Si la nouvelle version est prête à être déployée, le nouveau jeu de modifications sur main est étiqueté comme tel et le logiciel est déployé en production.

Vous pouvez obtenir une nouvelle version après chaque nouvelle tâche qui passe par ce cycle, ou vous pouvez décider d'en regrouper quelques-unes. Lorsque l'on pratique le déploiement continu, le déploiement de chaque tâche vers la production est le flux de travail le plus logique.

Avec Unity Version Control, l'étape de test et de fusion automatisée peut être configurée en utilisant le plug-in pour l'outil de CI choisi, tel que Jenkins, Bamboo ou Unity Cloud Build.

Cette étape peut également être orchestrée à l'aide de la fonction mergebot de Unity Version Control. Le mergebot peut fusionner les branches et déclencher une compilation pour s'assurer que tout fonctionne. Les fusions ne sont confirmées que si la version est bonne, ce qui permet d'éviter les versions cassées.

Nous aimons respecter la convention de dénomination suivante : préfixe + numéro de la tâche. Par exemple, les branches peuvent être nommées task1213, task1209 et task1221. Le préfixe est "tâche" et le numéro représente le numéro de la tâche dans l'outil de suivi des problèmes associé.

La capture d'écran montre également une description de chaque branche ainsi que son numéro, puisque l'explorateur de branches récupère le numéro à partir de l'outil de suivi des problèmes. Vous pouvez également consulter la description de la branche en sélectionnant "afficher les informations sur la tâche de la branche".

Les règles de Scrum stipulent que les tâches ne doivent pas durer plus de 16 heures. Cette pratique permet de maîtriser les délais des projets.

Les branches d'activité doivent être fermées rapidement. L'idéal est d'avoir de nombreuses petites tâches que vous pouvez mener à bien en quelques heures. Cette structure permet de maintenir le rythme du projet et facilite le déploiement continu. Une tâche plus importante qui s'étend sur une semaine, par exemple, interrompt le cycle.

Un signal d'alarme à garder à l'esprit : Ne créez pas de tâches "coupées à la machette". Si vous devez découper une tâche en plusieurs parties, assurez-vous que la tâche a toujours un sens isolément et qu'elle peut être déployée indépendamment.

Les flux de travail des branches de tâches ne peuvent réussir que si l'ensemble de l'équipe y adhère.

Comme tout processus DevOps, ce flux de travail comporte une composante culturelle. Les groupes de travail permettent de communiquer ouvertement les progrès accomplis et d'éviter les cloisonnements. Avant d'imposer un flux de travail ou une façon particulière de travailler, il faut veiller à l'alignement. Aidez les membres de l'équipe à comprendre les avantages qu'il y a à terminer une petite partie d'une tâche plus importante aujourd'hui, plutôt que de s'acharner sur des tâches plus vastes pendant plus longtemps.

Posez-vous la question (ou posez-la à vos coéquipiers) : Avez-vous vraiment besoin du code que vous venez de terminer dans la tâche 1213 pour commencer la tâche 1209 ?

Les tâches ont tendance à être beaucoup plus indépendantes que vous ne le pensez. Oui, ils peuvent porter sur le même sujet, mais il n'est pas nécessaire de toucher exactement au même code. Vous pouvez simplement ajouter quelque chose de nouveau et faire confiance à la fusion pour faire son travail.

Supposons que les chiffres 1213 et 1209 de l'exemple ci-dessus soient des corrections de bogues et non des tâches. Il ne faut pas que l'un dépende de l'autre. Vous voulez qu'ils atteignent le niveau principal et qu'ils soient libérés le plus rapidement possible. Même s'ils touchent le même code, il s'agit de corrections différentes.

Chaque vérification doit aider l'examinateur à suivre votre cheminement de pensée et votre processus pour comprendre comment vous avez abordé la tâche.

Le fait de laisser des détails dans les commentaires de votre enregistrement aidera l'examinateur, car il n'aura pas besoin de parcourir l'ensemble de la branche. Au lieu de cela, ils différencieront les jeux de données (changeset) les uns des autres. Et ils suivront l'explication préenregistrée que vous avez faite pour clarifier chaque étape de la tâche. Ils ne se retrouveront pas devant une liste en gras de plus de 100 fichiers modifiés. Au lieu de cela, ils procéderont étape par étape.

Chaque branche de tâche doit être prête à être intégrée une fois terminée. Si un changement est fragile ou si le produit se comporte mal, la tâche ne doit pas être considérée comme terminée.

C'est un petit prix à payer pour les avantages de l'automatisation. L'équipe doit s'aligner sur la définition de "done", c'est-à-dire "prêt pour la production". En retour, vous pouvez avoir l'esprit tranquille en sachant que le passage de votre tâche à la production est facile, entièrement automatisé et qu'il n'entraînera pas d'exercice d'incendie à 2 heures du matin.

Qu'est-ce qu'un basculeur de fonctions ? Ces éléments sont essentiels pour le déploiement continu. Cette technique de développement logiciel permet de tester les fonctionnalités avant qu'elles ne soient terminées et prêtes à être diffusées.

Une bascule de fonctionnalité permet de masquer, d'activer ou de désactiver la fonctionnalité en cours d'exécution. Il vous permet d'activer une fonctionnalité uniquement pour l'équipe de développement, pour un petit nombre d'utilisateurs précoces ou pour tout le monde. Par exemple, un développeur peut activer une fonctionnalité pour les tests et la désactiver pour les autres utilisateurs pendant le développement.

Prenons un exemple. Vous avez une grande fonctionnalité divisée en sept parties qui seront converties en tâches et mises en œuvre à l'aide de branches de tâches. Comment est-il possible de déployer la partie 4 si rien d'autre n'est prêt ?

La partie 4 peut être fusionnée avec la branche principale et même déployée alors qu'elle est encore cachée à l'aide d'une bascule de fonctionnalité.

Le fait d'être caché ne signifie pas que le nouveau code n'est pas testé avant d'être publié. Lorsque l'ensemble du dispositif est prêt à être activé, les différentes parties ont déjà été testées à plusieurs reprises. L'intégration de la dernière pièce ne déclenchera pas une fusion de grande ampleur ; il s'agit simplement d'une petite partie qui passe dans la partie principale.