Qu'est-ce que la gestion des versions?
La gestion des versions couvre toutes les phases de la publication du logiciel, du développement et des tests au déploiement. La gestion des versions est requise chaque fois qu'un nouveau produit est demandé, ou même des modifications apportées à un produit existant. Il existe cinq étapes de base de gestion des versions que nous prenons dans cette situation:
- Planification des versions
- Version de version
- Test utilisateur d'acceptation
- Préparation à la sortie
- Déployez la version.
Planification des versions
La phase de planification est dans la plupart des cas intensive, car c'est à ce stade que l'ensemble de notre version est organisée du début à la fin. Un plan de sortie solide vous aide à rester sur la bonne voie et à vous assurer que les normes et exigences sont correctement respectées.
Lors de la planification des versions, nous pensons que les applications développées par plusieurs équipes ont besoin d'une approche cohérente qui doit être publiée à l'avance. C'est là qu'entre en jeu le concept de «train release». En suivant une approche de lancement de train, les équipes peuvent planifier des modifications en fonction des versions et les soumettre au Play Store.
La toute première étape, avant même de commencer à mettre en œuvre la version du train, consiste à définir les intervalles de temps pour chaque étape. Dans notre cas, la phase de développement est de deux semaines. Ensuite, vous devez déterminer le temps que vous souhaitez consacrer aux tests d'intégration et aux étapes de déploiement. Voici notre exemple d'espacement:
- Coupure: commence le jour 1.
- Test interne des versions alpha / UAT: trois jours.
- Déploiement progressif [1%] Soumission pour examen.
- Durée de l'examen: 3 jours.
- Un jour à 20% des utilisateurs.
- Un jour avec 50% des utilisateurs, le même jour, croissance à 100% des utilisateurs.
Sur la base de l'exemple ci-dessus, il faudra un total de 10 jours pour qu'une nouvelle version de l'application soit généralement disponible.
La prochaine étape vers les versions est la création d'un flux de travail auquel nos équipes et nos principales parties prenantes peuvent se référer tout au long de la version.
Le flux de travail explique immédiatement comment fonctionne la version entière et quel rôle joue chaque membre de l'équipe. Nous utilisons l'outil Asana pour afficher ces détails comme indiqué ci-dessous:
- Horaire
- Temps de livraison estimé
- Exigences
- Échelle globale du projet
Après avoir élaboré le plan, nous le soumettons à toutes les parties prenantes (groupe de lancement, chef de produit et dirigeants de haut niveau) pour examen. Ensuite, nous obtenons leurs commentaires sur les lacunes ou les problèmes qu'ils voient dans les exigences ou l'application.
Une fois le plan approuvé et finalisé, le plaisir commence!
Aspects importants de la planification des versions
Créer et utiliser une version de train semble bien, mais garder le processus opérationnel tout en planifiant une libération de train peut être délicat. Voici quelques détails de ce processus:
- Le responsable de la publication gère et coordonne la publication.
- Nous n'acceptons que le code révisé et testé.
- Il y a une étape de mise en œuvre dans le processus.
- Nous surveillons la version publiée de l'application.
Bâtiment de libération
Une fois le plan de version prêt, vous pouvez commencer à tester le produit en vue de sa sortie. Il s'agira du véritable «test au niveau utilisateur» du produit en fonction des exigences décrites dans le plan de version.
À un certain jour et à une certaine heure (par exemple, lundi, à 15 h 00), le code est figé / tronqué. Jusqu'à présent, les équipes ont le temps de rechercher, tester et fusionner les fonctionnalités dans la branche de développement, qui devrait faire partie de la version du train. À 15h00, le gestionnaire de publication créera une branche de publication à partir de la branche de développement. Cette étape est automatisée avec Jenkins.
En automatisant la transition de succursale, nous vérifions que tous les seuils de performance, les repères et l'automatisation des versions précédentes sur le marché sont définis sur l'actuel comme base de comparaison, et la version du train est bloquée contre d'autres modifications.
Une fois le code gelé, un nouveau cycle de développement commence et toutes les équipes participantes commencent un nouveau sprint et poursuivent le développement. L'avantage d'une version de train est que tout le monde connaît la prochaine version planifiée et qu'elle aide les gens à planifier leur travail en conséquence.
Version de branche et contrôle de version
Le développement de produit ne s'arrête généralement pas lorsque le développement d'une version est terminé, donc la première chose à laquelle nous pensons est de savoir comment geler la version testée et en même temps travailler sur de nouvelles fonctionnalités pour la prochaine version. Que se passe-t-il si une erreur apparaît dans la version de version? Comment corriger l'erreur si vous avez déjà ajouté un tas de nouvelles choses avant que l'erreur ne soit détectée?
C'est là qu'intervient la stratégie de branchement intelligente, qui a le concept de branchement. Comme son nom l'indique, le code de branchement signifie que, tout comme les branches d'un arbre, le code des branches correspond jusqu'à un certain point, puis se divise en deux copies.
Chaque branche peut se développer indépendamment de l'autre. Dans ce cas, une copie - la branche Release - reste figée là où vous vous étiez arrêté. C'est ce que nous appelons une branche coupée. Une autre branche (branche de développement) peut être modifiée avec un nouveau code et des corrections de bogues sans affecter du tout la branche de publication. Si un bogue est détecté dans une version candidate, un correctif peut être développé et ajouté à la branche de publication. Ainsi, la prochaine version que vous construisez à partir de la branche de publication peut être identique à la première, à l'exception d'un correctif de bogue. De cette façon, vous pouvez minimiser le risque de nouveaux bogues dans une version et isoler les bogues du nouveau code. Un correctif est également appliqué à la branche de développement pour s'assurer que le même bogue ne se retrouve pas dans la prochaine version.Un autre avantage du branchement de version est qu'une fois que vous publiez réellement votre code, vous avez une branche «gelée», qui est une copie exacte de la base de code publiée. Vous pouvez revenir à ce code à tout moment pour référence.
Test d'acceptation des utilisateurs
Les tests d'acceptation par les utilisateurs sont l'étape la plus critique pour la gestion des versions en raison de la quantité de données collectées et des correctifs nécessaires pour que la construction soit exactement ce qu'elle devrait être pour le lancement officiel.
Comme son nom l'indique, lorsqu'il s'agit de ce type de test, le chiffre clé est l'utilisateur. Les utilisateurs sont exactement les personnes qui utiliseront l'application. Par conséquent, il est impératif d'intégrer les utilisateurs à la stratégie globale d'assurance qualité dans le processus de développement logiciel. C'est là que UAT est utile. Ce type de test place les besoins des utilisateurs au centre du développement de produits comme aucun autre. Voici quelques-unes des questions auxquelles ces tests tentent de répondre:
- Les utilisateurs peuvent-ils travailler avec l'application?
- L'application se comporte-t-elle comme prévu?
- L'application résout-elle le problème de l'utilisateur?
Sans UAT (User Acceptance Testing) efficace, les chances de succès du projet en cours de développement sont considérablement réduites. C'est pourquoi la coutume est une partie si importante du processus de livraison. Comme indiqué précédemment, l'UAT fait partie d'un processus itératif. Au fur et à mesure que les erreurs sont identifiées, l'équipe revient pour les corriger. Le bogue est corrigé dans la branche de publication, puis fusionné avec la branche de développement. La construction doit passer par l'étape UAT afin qu'elle puisse être examinée pour l'implémentation et la publication finales.
Conseil de pro: incluez toujours les tests internes dans la planification UAT!
Une façon pour nous d'accélérer la sortie de l'UAT était d'utiliser les pistes de test internes fournies par Google. Cela nous aide à distribuer rapidement des tickets à nos collègues et à capturer leurs commentaires en générant automatiquement des tickets JIRA. L'équipe s'assure également que les retours sont pris en compte avant de soumettre le test final.
Préparation et libération
Cette étape consiste à mettre la touche finale au produit, en tenant compte de tout ce qui a été compris dans l'UAT. La préparation de la version comprend également un contrôle de qualité final par l'équipe de contrôle qualité. Au cours de l'inspection, l'équipe d'assurance qualité effectue des vérifications finales pour s'assurer que l'ensemble répond aux normes d'acceptation minimales et aux exigences commerciales du plan de version.
Une fois la révision terminée, le groupe de versions terminera la version pour commencer le déploiement. Avant qu'un assemblage puisse être déployé dans un environnement réel, il doit être approuvé par les équipes responsables concernées, telles que l'équipe de conception. UAT s'assure que le résultat est validé avant d'être passé à l'étape suivante.
Déployer une version
Enfin, le grand jour est venu où tout le travail acharné de notre équipe a porté ses fruits. Il est temps de lancer notre produit dans la nature pour la production. En plus de simplement envoyer l'assemblage à l'environnement de production, la phase de mise en œuvre comprend également une formation sur la façon de travailler avec le produit pour l'utilisateur final et l'entreprise dans son ensemble. Par exemple, les utilisateurs doivent être informés des modifications apportées à une version, et c'est là que «Quoi de neuf» n'apparaît pas dans le champ de vision. Nous avons un processus Jenkins automatisé qui contient les étapes suivantes:
- Création de l'assemblage final [en précisant la branche et le nom de la version].
- "Quoi de neuf" ajouté dans la version.
- Ajout d'un pourcentage de déploiement.
- Chaque étage dispose d'une entrée manuelle des signaux (rouge / vert) de chacune des commandes [UAT, benchmark, performance, automation].
Dès que les signaux permettent la construction, la construction est automatiquement téléchargée sur le Play Store avec un pourcentage de déploiement défini. Les étapes internes de validation et de balisage de la version, d'enregistrement des builds dans Dropbox, de publication et de mise à jour vers le canal Slack approprié sont également effectuées via le même pipeline.
Dans ce cas, nous commençons par déployer à 1%. A chaque étape, il est nécessaire de suivre la revue, ainsi que les outils de suivi des chutes de rejets afin d'identifier d'éventuels problèmes.
Si l'erreur devient perceptible dans 1%, l'équipe a une chance de réagir au problème et de décider de le résoudre rapidement. Si tel est le cas, la libération du train ne doit pas atteindre la prochaine étape de déploiement de 5%. Au lieu de cela, le problème est résolu pour 1% des utilisateurs. Une fois le problème résolu et la solution vérifiée, la libération du train peut passer à l'étape 5%.
Comme dans la version simple de la version de train, seul l'ingénieur de publication ou l'équipe de publication prend en charge le processus de publication une fois le code gelé. Toutes les autres équipes poursuivent leur développement «normal».
Analyse après la mise en liberté
Le travail de gestion des versions ne se termine pas lorsque le code est publié et continue jusqu'à ce que vous soyez prêt à publier à nouveau la version. Si vous voulez que votre application réussisse, elle a besoin d'un bon examen, vous devez également suivre la version en production pour corriger les bogues, implémenter les fonctionnalités dont les gens ont besoin et résoudre les problèmes des utilisateurs. Pour ce faire, nous utilisons Firebase Crashlytics, où nous suivons les plantages nécessitant une correction immédiate.
De plus, les avis sur les applications fournissent un aperçu de votre produit qui est beaucoup plus difficile à obtenir avec d'autres approches. Google Play et l'App Store permettent aux développeurs d'applications de répondre aux avis, ce qui peut être un outil incroyablement utile pour en savoir plus sur les problèmes liés aux applications des utilisateurs. Les témoignages peuvent identifier les problèmes que les utilisateurs rencontrent avec votre application et informer sur les changements futurs.
Résumons
La gestion des versions supervise un processus extrêmement dynamique. Chaque version est l'occasion de tout affiner, de notre flux de travail à notre liste de contrôle, au fur et à mesure que nous découvrons des domaines à améliorer. Voici quelques-uns des avantages que nous avons obtenus:
- Nous avons amélioré notre productivité en améliorant la communication et la coordination.
- Nos versions sont livrées plus rapidement, ce qui réduit également les risques. Ces changements impliquent une équipe qui peut fournir des versions de qualité à grande vitesse sur une base régulière.
- La gestion des versions prend également en charge la systématisation et l'optimisation de la méthode de développement et d'exploitation.
Nous avons également constaté que notre processus de gestion des versions permettait aux personnes à tous les niveaux - des développeurs et propriétaires de produits aux dirigeants - d'examiner le plan de haut niveau et d'obtenir un aperçu de leurs progrès, de travailler en synchronisation.
- Cours DevOps
- Formation aux métiers de la Data Science
- Formation d'analyste de données
- Cours Python pour le développement Web
Plus de cours