Guide : Gestion des versions logicielles pour les petites équipes

Formaliser le processus de gestion des versions (le cas échéant)

Dans certaines configurations d'équipe, en particulier celles que l'on trouve dans les startups, il n'y a pas de DevOps, ni d'ingénieurs en infrastructure, pour fournir un support lors de la sortie d'une nouvelle version du produit.

De plus, contrairement aux grandes entreprises bureaucratiques avec des processus formels définis, le CTO ou le responsable de l'équipe de développement logiciel d'une startup n'est souvent pas conscient de la complexité du processus de gestion des versions logicielles ; quelques développeurs de l'entreprise peuvent être conscients des détails complexes du processus, mais pas tout le monde. Si cette connaissance n'est pas documentée de manière approfondie , je pense que cela pourrait entraîner une confusion.

Dans cet article, je vais essayer de fournir quelques conseils sur la façon de formaliser le processus de publication, en particulier du point de vue du développeur.

Entrez la liste de contrôle de la version du logiciel

Vous connaissez peut-être l'idée d'une liste de contrôle pour certaines opérations, selon le Manifeste de la liste de contrôle , un livre d'Atul Gawande. Je pense qu'un processus de publication formel (comme de nombreuses autres tâches dans le monde du développement de logiciels) offre aux développeurs la possibilité d'implémenter ce protocole. Une liste de contrôle du processus de publication doit être conservée dans un document partagé, de préférence sous la forme d'un wiki collaboratif ou d'une feuille de calcul sur Google Drive.

En partageant ce document vital avec l'équipe et en accordant des autorisations de modification, chaque membre a accès au processus de publication formellement défini. Cela leur permet de comprendre le fonctionnement du processus. De plus, après des discussions avec d'autres membres de l'équipe, cela permet à l'équipe de l'améliorer de temps en temps. Cela devrait apporter de la transparence et permettre à toute l'équipe d'avoir un accès en temps réel à ce qui se passe pendant la publication, quelles étapes ont été complétées et par qui.

En consultant cette feuille de calcul, les parties prenantes peuvent décider d'un « GO » ou d'un « NO GO », en fonction du résultat des étapes. Par exemple, si un test de résistance se passe mal dans un environnement de test, en fonction de l'événement, le chef de projet peut décider d'annuler la version de production.

Étapes suggérées à utiliser comme base

Dans cette section, je proposerai quelques étapes que vous pouvez utiliser pour créer votre propre liste de contrôle pour votre processus de publication. Certaines de ces étapes ne sont en aucun cas obligatoires . Chaque application est différente et chaque organisation fonctionne d'une manière différente, alors n'hésitez pas à vous adapter et à apporter des modifications qui s'intégreront mieux à votre flux de travail.

1. Créer une branche de publication

Il est probable que vous soyez familier avec le concept de Git Workflow, ou avec l'idée des branches de publication, un sujet qui a été expliqué dans un article de blog précédent.

Idéalement, vous devriez avoir au moins trois branches :

• master : cela devrait refléter l'état actuel de ce qui se trouve dans l'environnement de production. Chaque nouveau commit sur master ne doit comprendre qu'une nouvelle version.
• develop : cette branche devrait contenir les fonctionnalités à venir terminées (et testées). Il est courant de créer une branche distincte pour chaque fonctionnalité, puis de la fusionner pour la développer lorsque la fonctionnalité est prête.
• release : les branches de release sont une collection de commits prêts à être envoyés en production, ainsi que quelques corrections de bugs mineurs supplémentaires liés à la release.

Notez que les branches de release doivent être supprimées une fois la release terminée, donc ces branches sont créées et détruites tout le temps, contrairement à master ou develop , qui sont toujours les mêmes.

Afin de créer une nouvelle branche de version , depuis la branche develop de votre terminal git, tapez :

$ git checkout -b release/xyz

Il est pratique d'utiliser une convention de nommage, telle que celle définie ci-dessus, en remplaçant xyz par le numéro de version major.minor.patch selon vos besoins (c'est une politique que vous devez définir au sein de votre équipe et vous y tenir).

Il est également important de dire que si vous codez des corrections de bogues dans la branche release, vous ne devez pas oublier de les fusionner pour développer . L'objectif principal de la branche de publication est d'avoir un aperçu de la façon dont l'application doit se comporter après sa mise en production.

2. Version bosse

La prochaine étape consisterait à augmenter (modifier ou augmenter) le numéro de version sur la branche de publication .

Vous devez ouvrir AndroidManifest.xml / package.json / pom.xml / ou partout où la version de l'application est stockée dans votre projet (YMMV), mettre à jour le numéro de version, puis valider les modifications dans la branche de version actuelle.

Il est important de mettre à jour le numéro de version pour deux raisons.

Premièrement, vous pouvez suivre et cartographier les fonctionnalités qui ont été introduites dans chaque version, et deuxièmement, vous serez au courant de la version qu'ils utilisent s'ils ont besoin de faire du dépannage ou de vous contacter pour obtenir de l'aide. Si vous créez une application mobile, le numéro de version que vous mettez à jour à cette étape est généralement affiché côté utilisateur, dans la section À propos ou dans Google Play ou Apple App Store . Cette étape est également une bonne occasion de mettre à jour l'environnement en fonction -fichiers de configuration (bien que je suggère de les conserver dans un référentiel séparé), comme faire pointer la branche vers la base de données de production, ou tout autre ajustement nécessaire au processus de construction.

Enfin, il est recommandé de pousser la branche release vers origin, afin qu'elle soit disponible pour vos autres développeurs :

$ git push -u origin release/xyz

3a. Fusionner la branche de version pour la maîtriser et la marquer

Seule la branche master doit être déployée pour la production, donc dans cette étape, nous devons fusionner la branche release dans master .

 $ git checkout master $ git merge --no-ff release/xyz $ git push

Le drapeau --no-ff est facultatif, cependant, son utilisation est recommandée afin de forcer la création d'un nouvel objet de validation, même si la fusion peut être effectuée en utilisant la technique d'avance rapide.

Ensuite, il est temps de taguer la release sur la branche master :

$ git tag -a xyz -m 'description of new version, features or fixes included'

Les balises sont utiles car vous conservez ce point spécifique de l'historique dans le référentiel git, et vous pouvez revenir plus tard pour recréer une branche distincte à partir d'une balise particulière.

3b. Utiliser une pull request pour fusionner la branche release

Une autre alternative souvent utilisée consiste à utiliser une pull request pour fusionner la branche release dans master .

Il y a de nombreux avantages à cette approche. Un nouvel espace est créé pour la collaboration, que l'équipe peut utiliser pour discuter de divers problèmes liés à la version. Ce point est le bon moment pour ajouter une porte supplémentaire pour incorporer un processus de révision du code, tout en ayant plus de globes oculaires pour surveiller le code qui sera introduit et pour discuter des modifications potentielles.

Certains outils qui vous permettent d'implémenter des pull requests dans vos workflows sont GitHub, Bitbucket et GitLab (merge request comme ils l'appellent sur ce dernier). Avec ces outils, vous ne tapez pas les commandes git manuellement, mais vous utilisez une interface Web pour définir la branche source ( release ) et la branche de destination ( master ), puis vous ajoutez un ou plusieurs relecteurs, qui tous pouvoir écrire des commentaires en ligne sur ces nouveaux changements, suggérer des améliorations, etc.

Une fois que tous les réviseurs ont approuvé la demande d'extraction, vous pouvez automatiquement fusionner les modifications dans le maître en appuyant sur un bouton de l'interface utilisateur.

4. Déployer le maître dans l'environnement de production

Il est recommandé, à ce stade, de demander à un testeur de votre équipe d'effectuer un test de fumée (cela pourrait être défini sur une liste de contrôle distincte) avant de déployer l'application. Une bonne suggestion consiste à déployer la branche principale dans un environnement de test distinct. Le testeur peut ensuite effectuer quelques actions de base pour s'assurer que rien ne s'est mal passé après la fusion sur la dernière version. Comment effectuer un test de fumée dépasse le cadre de cet article, mais vous pouvez trouver beaucoup de matériel sur le Web à ce sujet. Le résultat du test de fumée peut être intégré à la liste de contrôle/feuille de calcul de la version, documentant tout ce qui s'est mal passé.

À ce stade, vous êtes prêt à déployer les modifications et à les mettre en ligne. Allez-y et déployez la branche principale . Cette étape dépendra de la pile d'infrastructure que vous utilisez. Cela peut impliquer de se connecter à votre instance Amazon EC2 pour télécharger votre application, ou de pousser vers une télécommande Heroku, ou de se connecter via ssh à votre VPS pour copier la nouvelle version, ou tout autre processus.

Une fois l'application téléchargée, assurez-vous qu'elle a été déployée avec succès et qu'elle fonctionne comme prévu.

5. Fusionner dans la branche Développer et supprimer la version

Maintenant que la version est presque terminée, vous souhaiterez fusionner la branche release dans develop , mettre à jour le numéro de version de cette dernière et transférer toutes les corrections de bugs apportées à la branche principale de développement :

 $ git checkout develop $ git merge release/xyz

Il est maintenant temps de supprimer la branche release :

$ git branch -d release/xyz

6. Génération du journal des modifications

Il devrait y avoir un fichier à la racine de votre projet nommé CHANGELOG.md (ou un équivalent) où vous devriez ajouter une nouvelle entrée chaque fois qu'il y a une nouvelle version afin de documenter tout ce qui y est inclus, comme les corrections de bogues, les nouvelles fonctionnalités, les problèmes connus et toute autre information pertinente sous forme de notes de version. Ceci est vraiment utile pour les utilisateurs et les contributeurs pour voir quelles modifications ont été apportées entre chaque version (ou version) du projet.

L'entrée du journal des modifications inclut la date, le numéro de version et quelques notes sur la version. Les entrées doivent être conservées dans l'ordre chronologique inverse. Voici un modèle simple que j'utilise et que vous pouvez adapter à votre projet :

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

De plus, cette étape peut être entièrement automatisée soit en codant un script de base qui parcourt le journal git et génère automatiquement l'entrée du journal des modifications, soit en utilisant un outil qui fait de même, tel que :

• Github Changelog Generator, par skywinder,
• ReadmeGen par fojuth
• github-changes, par lalitkapoor

Gardez cependant à l'esprit que le degré d'automatisation que vous obtenez est directement proportionnel à la rigueur du format de votre message de validation. Je pense qu'il est toujours bon de convenir d'un format spécifique pour les messages de validation avec l'équipe. En suivant les directives sur le style des messages de validation, ils seront plus faciles à analyser et donc plus susceptibles de pouvoir automatiser la génération du journal des modifications.

7. Communiquer avec les parties prenantes

C'est là que vous effectueriez généralement certaines des opérations suivantes :

• Faites savoir à l'équipe via un outil de messagerie interne (ex : Slack) qu'une nouvelle version est terminée. Je recommande de créer un nouveau canal (c'est-à-dire : #releases ) dans le seul but de communiquer les événements liés aux versions. Il est facile d'ajouter des crochets dans un canal Slack pour publier un message après qu'une action a été entreprise.
• Vous pouvez également envoyer un e-mail aux parties prenantes avec un lien vers le journal des modifications ou le fichier journal des modifications en pièce jointe.
• Rédigez un article de blog (si vous avez un blog pour votre application ou votre produit) ou un tweet.

D'autres actions peuvent être entreprises en fonction de la nature de votre organisation. L'important est de ne pas oublier de communiquer qu'une nouvelle version de votre produit est disponible.

8. Entretien du suivi des problèmes

Après l'exécution d'une version, vous devrez probablement mettre à jour le statut de certains de vos tickets pour suivre les corrections de bogues ou les fonctionnalités actuellement en production. Généralement, cela implique de changer certaines balises (pour les petits projets, j'utilise une balise en attente de publication , que je supprime une fois la publication terminée).

Si vous utilisez des jalons pour chaque nouvelle version, vous devrez probablement mettre à jour leur statut ou les marquer comme terminés. Certains trackers de problèmes vous permettent même de planifier la version et de l'aligner sur les sprints, de suivre si un bogue bloque une version et d'autres informations utiles.

Tout dépend de la façon dont vous utilisez l'outil. Je tiens simplement à souligner que la tâche de mise à jour des informations dans le suivi des problèmes doit être incluse dans votre liste de contrôle des versions.

À propos de l'automatisation du processus de publication

Le lecteur a peut-être remarqué que, outre l'étape du journal des modifications décrite ci-dessus, bon nombre des étapes susmentionnées peuvent également être automatisées.

La possibilité d'automatiser certaines parties du processus de publication est une énorme victoire et permet de gagner beaucoup de temps. Je suggère de créer des scripts ou de déterminer comment automatiser des étapes individuelles, puis travailler vers un objectif de livraison continue. La livraison continue peut réduire les risques, réduire les coûts et réduire le temps que les développeurs doivent consacrer à la gestion de la version. Par conséquent, vous pourrez publier plus souvent et être plus productif en termes d'heures allouées au développement.

Le Saint Graal des entreprises DevOps est de pouvoir lancer une nouvelle version en appuyant sur un bouton (ou en exécutant une commande) qui déclencherait automatiquement le processus de publication, ou mieux encore, un système qui publierait une nouvelle version de votre logiciel à un moment donné. temps désigné. Bien sûr, cela est difficile à réaliser car vous devez également automatiser une grande partie du processus de test, mais ce n'est pas impossible.

Adopter les meilleures pratiques

Dans cette section, je décrirai quelques pratiques recommandées que j'ai trouvées pratiques, soit pour faciliter le processus de publication, soit pour prendre des mesures de sécurité en cas de problème.

Trouver le jour le plus approprié pour effectuer la libération

Je publie généralement les applications sur lesquelles je travaille le jeudi, entre midi et la fermeture des bureaux.

Si vous travaillez du lundi au vendredi, ce n'est pas une bonne idée de vous lancer un vendredi. Si quelque chose tombe en panne après la sortie, vous n'aurez pas le temps de le réparer avant lundi (sauf si vous voulez travailler le week-end). C'est pourquoi il est plus pratique de faire des versions le jeudi, car vous avez le vendredi pour surveiller la nouvelle version après son déploiement, résoudre les problèmes ou effectuer une restauration.

Une autre chose importante à mentionner si vous gérez une application Web est de connaître le fuseau horaire dans lequel se trouvent la majorité de vos utilisateurs. Vous devez programmer la libération pendant une période de faible trafic afin de minimiser les dommages potentiels en cas de défaillance. Parfois, cela peut être délicat lorsque votre base d'utilisateurs est répartie dans le monde entier, mais de toute façon, vous devriez faire des recherches et décider du meilleur moment.

Sauvegardez votre base de données avant une nouvelle version

Si vous n'avez pas planifié de sauvegardes périodiques de votre base de données, je vous suggère fortement d'ajouter une étape dans votre processus de publication pour effectuer une sauvegarde avant de commencer la publication.

Déploiements par étapes

Vous êtes-vous déjà demandé pourquoi, lorsqu'un éditeur annonce le lancement d'une nouvelle fonctionnalité, il faut des jours, voire des semaines, pour que cette fonctionnalité soit disponible sur votre téléphone ? En effet, de nombreuses entreprises utilisent des déploiements par étapes.

Facebook le fait depuis longtemps. Il teste une nouvelle fonctionnalité sur cinq ou 10 % de ses utilisateurs, en l'augmentant progressivement jusqu'à ce qu'ils atteignent 100 % de la base d'utilisateurs. Au cours de la phase de déploiement par étapes, vous devrez examiner attentivement les commentaires des utilisateurs et les rapports de plantage. Avec ces informations, vous pouvez ensuite reporter la publication ou corriger les erreurs avant qu'elles n'affectent tous les utilisateurs.

Il existe un bel outil sur la console développeur d'Android qui implémente des déploiements par étapes pour vos applications Android.

Intégration continue

L'intégration continue est une pratique qui mérite d'être adoptée pour de nombreuses raisons. Tout d'abord, cela vous permet de détecter les erreurs plus tôt, augmentant ainsi le taux de publications réussies. Deuxièmement, il s'agit de la première étape logique avant la mise en œuvre de la livraison continue et de l'automatisation complète comme décrit précédemment.

Martin Fowler est un grand défenseur de l'intégration continue. Il décrit une énorme quantité d'avantages qui peuvent être ajoutés à votre processus de publication lors de l'utilisation de cette pratique. C'est un vaste sujet et il existe de nombreux livres et articles de blog à ce sujet, et je le mentionne ici parce que je pense que cela vous donnera beaucoup plus de confiance dans vos opérations. Parmi les nombreux avantages de l'utilisation de CI, vous trouverez : une réduction des risques, une visibilité accrue pour savoir ce qui fonctionne et ce qui ne fonctionne pas, une détection plus précoce des bogues, une fréquence accrue des déploiements, et bien d'autres.

Le point de départ de la mise en œuvre de CI est de mettre en place un "serveur d'intégration continue" ; quelques bons outils à essayer sont : CruiseControl, Bamboo, Jenkins et Travis.

Exitlude : tout ira bien

Agressivement, nous défendons tous le rôle que nous jouons Malheureusement, les temps viennent pour vous envoyer sur votre chemin Nous avons tout vu, des feux de joie, des crues éclair de douleur Ça n'a pas vraiment d'importance, ne vous inquiétez pas, ça ira tout s'arrange

Exitlude, les tueurs

Pour conclure, je dirais qu'il est très important d'avoir un processus de publication bien défini pour votre application, quelle que soit sa complexité, sa base d'utilisateurs ou la taille de votre organisation.

Si ce n'est pas le cas, je vous suggère de commencer à réfléchir à certaines étapes de base, à utiliser ce guide et d'autres similaires, et à réfléchir avec votre équipe pour proposer une première ébauche. Essayez-le sur votre prochaine version, puis réitérez. Finalement, vous finirez par créer votre propre processus de publication.

Après cela, commencez à réfléchir à la manière d' automatiser certaines parties du processus . Pensez aux domaines qui peuvent être améliorés. Explorez les moyens de réduire le temps de publication en incorporant de petites optimisations. L'automatisation devrait être votre objectif ultime ; cependant, ne planifiez pas cela dès le départ, ou vous échouerez en tentant un si grand saut. Comme pour tout processus, il vaut mieux l'améliorer progressivement.

Avez-vous d'autres astuces ou directives que vous utilisez pour lancer de nouvelles versions de votre application ? Si oui, faites-le moi savoir. Je ne viens pas du monde DevOps, je suis juste un développeur qui se trouve être assez organisé et structuré, mais comparé à de nombreux vétérans, je suis encore novice en la matière, alors n'hésitez pas à commenter ou à me contacter si vous avez quelque chose à ajouter.