En matière d’ingénierie logicielle, qu’est-ce qu’une version ?
En ingénierie logicielle, une publication désigne un logiciel nouveau ou modifié ainsi que le processus de création du logiciel en question. Une publication constitue une version entièrement fonctionnelle du logiciel, et elle représente l’apogée des processus de développement et d’ingénierie de logiciels. Des versions alpha et bêta du logiciel précèdent généralement sa sortie.
Bien que les lancements de versions alpha et bêta puissent également être appelés « versions alpha ou bêta », le terme « version » fait généralement référence, au singulier, à la version finale du logiciel. On rencontre également les termes « lancements » ou « incréments » pour désigner les versions.
La plupart des organisations identifient les versions à l’aide d’un ensemble unique de chiffres ou de lettres qui sont mis à jour dans un ordre précis. Ce processus de dénomination est appelé « gestion des versions logicielles ». Il n’existe pas de règles à l’échelle du secteur concernant la manière dont ces identifiants uniques doivent changer d’une version à l’autre, mais chaque entreprise suit systématiquement ses propres normes internes.
Qu’est-ce que le processus de gestion des versions ?
Les organisations améliorent la qualité, la rapidité et l’efficacité de la création ou de la mise à jour de logiciels en se concentrant sur la gestion des versions. Il s’agit du processus de planification, de programmation et de gestion d’un logiciel créé, à travers les étapes de développement, de test, de déploiement et de prise en charge de la version. Des techniques comme le développement agile, la livraison continue, le DevOps et l’automatisation des versions ont contribué à optimiser la gestion des versions.Dernièrement, ce processus s’est accéléré, au point qu’Amazon a passé il y a quelques années la barre des 50 millions de déploiements de codes par an, ce qui correspond à plus d’un code par seconde.
La gestion des versions est une discipline relativement nouvelle dans l’ingénierie logicielle, mais elle se développe rapidement à la faveur aux innovations technologiques rapides. En tant que discipline, elle s’appuie à la fois sur la gestion de projets traditionnelle et axée sur l’entreprise et les connaissances techniques du cycle de vie du développement des systèmes (CVDS) et sur la bibliothèque d’infrastructures informatiques, un ensemble de pratiques de la gestion des services informatiques.
Les objectifs et avantages de la gestion des versions
Mise en place efficacement, la gestion des versions augmente le nombre de publications réussies par une organisation et réduit les problèmes de qualité. La productivité, la communication et la coordination sont améliorées, et l’organisation peut fournir des logiciels plus rapidement tout en réduisant les risques.
Ces améliorations signifient que l’équipe peut produire de manière répétée des logiciels de qualité moyennant des délais de mise sur le marché plus courts, ce qui permet à l’entreprise de réagir plus rapidement à l’environnement opérationnel.
La gestion des versions permet également de standardiser et de rationaliser le processus de développement et d’exploitation. L’équipe met en œuvre des contrôles des versions vérifiables, créant ainsi un référentiel pour toutes les versions tout au long du cycle de vie. Le fait de disposer d’un processus unique et bien documenté qui est appliqué pour toutes les versions augmente la maturité organisationnelle. Une standardisation accrue et la focalisation sur les produits permettent aux équipes de tirer des enseignements plus utiles de leur expérience passée et de les appliquer aux futures versions.
Les services opérationnels apprécient la coordination accrue avec les développeurs, car elle génère moins de surprises. Ils n’ont plus le sentiment qu’une version leur a simplement été « livrée à la sauvette » par le service Développement, les laissant dans l’obligation « recoller les morceaux » à la dernière minute. Cela permet également de résoudre les problèmes de configuration entre les environnements de développement et d’exploitation.
En bref, la gestion des versions brise les barrières entre les différentes équipes et fonctions au sein d’une organisation informatique. Elle permet, par conséquent, d’améliorer la livraison des produits de manière globale.
Gabriel Gutierrez, a Solutions Architect at Boeing and former Release Manager at Costco, says that when executing a release, it’s important to give adequate consideration to the impacts on other areas of the organization. “Companies must provide a common forum where changes are fully vetted and put through thorough architectural and design reviews that eventually lead to integrated testing. Cross-functional and technical reviews are essential to minimizing the inevitable pain after go-live. A smooth post-go-live operation is a critical success factor of any release,” he explains.
Un bref historique de la gestion des versions
L’essor de la gestion des versions provient du passage de l’ingénierie logicielle des offres basées sur des projets aux offres basées sur des produits. Le paradigme de développement basé sur des projets suppose que les développeurs de logiciels considèrent chaque version comme un projet, et non comme un produit ; les logiciels entièrement développés ont joué un rôle très important dans la disparition du rôle de développeur.
Au fil du temps, cependant, le processus de développement de logiciels s’est rapproché du cycle du produit dans lequel les produits sont pris en charge, améliorés et relancés à plusieurs reprises sur une longue durée de vie. Dans ce cadre, la version n’était pas l’objectif final du développement, mais plutôt un point de transition pour l’assistance et la révision.
Cette complexité accrue a entraîné un besoin impérieux de coordonner les différentes phases. C’est pourquoi les pratiques actuelles de gestion des versions s’inspirent, en partie, des principes de la gestion de projet axée sur l’entreprise, qui s’étend à l’assistance après-vente et au développement ultérieur.
La gestion des versions fait partie de la discipline informatique plus large de la gestion des changements, qui traite des vicissitudes inhérentes au développement de logiciels, où les exigences des parties prenantes évoluent en permanence et où le paysage de la conformité et de la réglementation change en continu. Pour naviguer dans cet environnement, les processus d’ingénierie logicielle doivent être bien synchronisés, ce dont se charge la gestion des versions. (Remarque : la gestion du changement ne doit pas être confondue avec le changement organisationnel, qui s’entend du remodelage de la culture, des rotations de personnel et de la restructuration interne des organisations).
A “common pitfall is disregarding the importance of a well-thought-out change management process,” says Jen Dunbeck, a release manager at automated IT services provider BitTitan. “A change control board's or change advisory board's significance cannot be underestimated in a release. A key function of their job is to help the organization assess risk and impact with impartiality. They also help root out technical dependencies that may not have been evident as individual contributions to the deployment,” she adds.
Pour développer votre processus de gestion des changements, vous avez intérêt à vous doter de moyens standard de proposition de changements à apporter au projet et d’enregistrer ces changements au fur et à mesure qu’ils sont approuvés et réalisés. Démarrez le processus en téléchargeant ci-dessous les modèles gratuits de journal de gestion des changements et de proposition de changement.
Modèle de proposition de changement
Une proposition de changement décrit le type et l’échelle du changement, et constitue souvent la première étape d’un processus de gestion des changements. Décrivez pourquoi le changement est nécessaire, les résultats et impacts attendus, le temps et les ressources requis et tout autre facteur à examiner. Ce modèle comprend également des espaces pour ajouter des informations descriptives ainsi que des sections pour calculer les coûts et avantages.
Journal de gestion des changements
Un journal de gestion des changements est un document qui permet de suivre les personnes ayant demandé quel changement et quand, le statut de la demande de changement, son niveau de priorité et les informations de résolution. Si vous avez besoin d’un registre plus détaillé, incluez des détails supplémentaires tels que le type et l’impact du changement. Ce modèle de journal est conçu pour suivre les informations essentielles afin d’assurer la hiérarchisation, le traitement et le référencement ultérieur des demandes de changement.
Fonctionnement de la gestion des versions : vue d’ensemble
Tous les logiciels ne sont pas égaux au départ. Selon les fonctionnalités et modes d’utilisation du programme, le processus d’ingénierie logicielle varie en rigueur et en intensité.
Par exemple, les logiciels conçus pour être utilisés dans les avions subissent des tests rigoureux. Vous devrez créer une documentation complète et mettre en œuvre plusieurs correctifs si vous ne respectez pas des critères de performances stricts. Les exigences fonctionnelles et indicateurs de qualité sont rigoureux, et le logiciel doit passer par de nombreuses étapes d’approbation avant même que l’on ne songe à l’utiliser dans un avion.
Un processus de gestion des versions organisé permet de s’assurer que les logiciels sont conçus, testés et livrés conformément aux stipulations des principales parties prenantes. L’équipe vérifie le logiciel pour confirmer qu’il se comporte conformément aux attentes et qu’il sera prêt dans les délais.
La gestion des versions combine les éléments suivants en un seul référentiel central :
- Les impératifs commerciaux (donner aux clients ce dont ils ont besoin quand ils en ont besoin)
- Les tâches techniques d’assurance qualité et de conformité
- La gestion des artefacts logiciels
À partir du référentiel, les artefacts sont diffusés dans un environnement de production client pour le déploiement d’applications. Ainsi, on peut considérer la gestion des versions comme le ciment qui agrège des tâches interconnectées mais distinctes, notamment l’ingénierie logicielle et la conception, le développement, les tests, le déploiement, la maintenance et les exigences de l’entreprise et des clients.
Une version recouvre davantage que les fonctions principales d’ingénierie logicielle. Même si les développeurs considèrent évidemment une version comme la livraison aboutie d’un produit fini, ce concept englobe également différentes activités commerciales de soutien, par exemple la formation des vendeurs et du personnel d’assistance à la clientèle ainsi que la publicité et la commercialisation de la nouvelle version. Ces activités doivent se dérouler simultanément à la publication de la version, ce qui ajoute de la complexité au processus de gestion des versions.
En outre, la gestion des versions ne concerne pas seulement les logiciels nouvellement conçus. Les logiciels modifiés passent par le même processus pour s’assurer que les parties prenantes obtiennent ce dont elles ont besoin.
La publication réelle peut être effectuée manuellement, ou, de plus en plus, par des moyens automatiques, en fonction de la maturité du processus de gestion des versions. (Amazon utilise un processus de publication automatisé pour obtenir une nouvelle version à chaque seconde. Historiquement, les mises à jour hebdomadaires, mensuelles et trimestrielles sont plus courantes pour les équipes de développement de logiciels).
Les versions peuvent prendre différentes formes : en tant que produits physiques livrés dans un carton, sous forme de téléchargement depuis un site Web ou un serveur, sous forme de notifications vers un appareil, depuis une boutique d’applications mobiles, ou sous forme de mises à jour transparentes d’une application en ligne.
Tous les groupes d’ingénierie logicielle, qu’ils soient grands ou petits, et quel que soit leur secteur, utilisent la gestion des versions pour faciliter le processus. Ils peuvent l’appliquer aux logiciels utilisés en interne ou vendus en tant que produits. Les groupes d’ingénierie logicielle, grands et petits, utilisent la gestion des versions dans tous les secteurs, et ils peuvent utiliser le logiciel qui en résulte pour exécuter leurs propres produits ou systèmes, ou pour vendre des versions en tant que produits aux clients.
L’une des approches de développement les plus propices à la gestion des versions est dénommée DevOps, un terme qui combine les concepts de développement et d’opérations. Comme son nom l’indique, le DevOps cherche à accroître la coordination entre les développeurs et les opérations d’ingénierie logicielle en s’appuyant à la fois sur l’automatisation et le suivi à toutes les étapes du développement de logiciels afin de réduire les délais de mise sur le marché et d’améliorer la satisfaction des clients.
Termes clés de la gestion des versions
Pour maîtriser la gestion des versions, vous devez comprendre les termes couramment utilisés.
Bon de commande de développement : Il s’agit d’un bon de commande de développement ou de modification d’une application ou d’un système logiciel.
Équipe DevOps : L’objectif du DevOps étant d’accroître la coordination entre les fonctions de développement et opérationnelles, la mise en place d’une équipe distincte rend le terme impropre. Quel que soit sa désignation, le terme fait généralement référence aux membres clés des équipes de développement et opérationnelles, qui cherchent à coordonner les deux fonctions.
Bon de commande d’installation : Similaire à un bon de commande de développement, un bon de commande d’installation porte sur l’installation d’une application logicielle, d’un système ou d’un composant d’infrastructure.
Responsable de produit : Le responsable de produit d’un projet de développement est la principale partie prenante. Il représente généralement l’entreprise ou les utilisateurs (éventuels) du produit, et il définit la vision du produit.
Chef de projet : Un chef de projet prend en charge la direction d’un seul produit. Il est chargé de définir la feuille de route et la vision du produit ainsi que d’en négocier les livrables. Généralement, les principales responsabilités d’un chef de projet ne vont pas au-delà d’un seul produit ou d’une famille de produits étroitement liés entre eux.
Version : Une version se compose d’une ou plusieurs unités de publication.
Gestionnaire des versions : Le rôle du gestionnaire des versions consiste à planifier, coordonner, gérer et programmer tous les éléments qui composent une version. Tous ces éléments ne doivent pas nécessairement provenir du même produit. Par exemple, le gestionnaire doit également coordonner les tâches réalisées sur d’autres produits conçus pour s’intégrer à la nouvelle version.
Politique relative aux versions : Ensemble de règles concernant le déploiement des versions dans l’environnement opérationnel de production. Différentes politiques relatives aux versions s’appliquent à différentes versions, en fonction de facteurs tels que l’impact et l’urgence.
Registre des versions : Un registre des versions documente l’historique d’une version, de la planification à la clôture du processus de développement.
Unité de publication : Ce terme fait référence à un ensemble d’éléments de configuration qu’une équipe teste et publie simultanément dans l’environnement de production pour mettre en œuvre des modifications approuvées. Inversement, un élément de configuration est un composant d’une infrastructure qui fait l’objet d’une gestion de la configuration et qui consiste à s’assurer que les attributs et les performances d’un produit sont cohérents avec sa conception, ses exigences et ses informations opérationnelles.
Responsable du service : un responsable du service assume la responsabilité globale d’un service informatique spécifique. Il s’occupe moins des opérations quotidiennes nécessaires à la fourniture du service ; c’est le rôle d’un chef de service.
Gestionnaire de la qualité : un gestionnaire de la qualité garantit qu’une version répond aux normes stipulées. Des responsables des versions peuvent être placés sous sa responsabilité.
Principaux concepts de gestion des versions
La gestion des versions est parfois décrite comme une superdiscipline, car elle implique de superviser plusieurs disciplines interconnectées mais distinctes, note l’expert en gestion des configurations Salman Khwaja.
L’une des pratiques centrales de la gestion des versions est la gestion du code, qui représente le processus de gestion des modifications du code informatique. S’appuyant sur des modules de code ou des collections de lignes de code, la gestion du code simplifie et accélère les tâches de modification du code ainsi que d’autres activités liées au code, comme la maintenance et le débogage. Le contrôle des versions est un type de gestion du code qui constitue un aspect important de la gestion des versions. Il recouvre la gestion du code pour différentes versions d’un même logiciel à des fins de comparaison et de référence. La gestion du code suit de nombreux principes empruntés à la gestion des dossiers.
Pour remplir efficacement son rôle, un responsable des versions doit favoriser la facilitation et la collaboration, principalement entre les équipes, mais également au sein des équipes. Les responsables des versions sont généralement des professionnels expérimentés eux-mêmes, de sorte qu’ils peuvent être appelés à proposer des présentations.
Les processus et politiques sont essentiels à une gestion efficace des versions. Les problèmes sont inévitables et des protocoles doivent être élaborés pour les résoudre en cas de besoin. Le responsable des versions fait également figure de gardien ou de dépositaire du code de production. Il est mis au courant à chaque fois qu’un artefact de code quitte l’organisation.
Sur un certain nombre de versions, il est désormais possible de générer des métriques de productivité et de débit pour mettre en évidence l’efficacité de la gestion des versions. Les indicateurs courants comprennent des éléments tels que la vitesse et le taux de burn-down.
Le cycle de la gestion des versions
La gestion des versions suit généralement un chemin clairement défini. Elle commence par la création d’un calendrier de publication à l’échelle de l’organisation. Si certaines entreprises publient des mises à jour logicielles en continu, d’autres préfèrent appliquer un calendrier défini. Vient ensuite la planification de la sortie du produit ou de la solution.
La gestion des versions commence généralement à la première étape du cycle de développement, lorsque le responsable des versions reçoit des demandes de modification ou de nouvelles fonctionnalités. Une fois la demande approuvée, l’équipe élabore la nouvelle version et la planification commence. Les développeurs créent le nouveau logiciel. Après le développement, la version est testée et l’équipe peut lui apporter des modifications avant que la version ne soit acceptée. Par la suite, la version passe au déploiement, où elle est mise à disposition pour une utilisation pleine et entière. Après le déploiement, la version passe à l’étape de l’assistance, au cours de laquelle les bugs ou récits d’utilisateurs que l’équipe documente à ce stade réalimentent le cycle de développement afin de bâtir une nouvelle version.
Modèle simple de plan de versions
Utilisez le modèle de plan simple ci-dessous. Pour les projets particulièrement complexes et à budget élevé, le cadre de plan de versions développé par le Center for Medicaid Services, qui peut être téléchargé ici, constitue un bon point de départ.
Télécharger le modèle de plan simple — Word
Défis que la gestion des versions peut aider à résoudre
Par le passé, de nombreuses entreprises n’avaient pas de processus de gestion du cycle de publication. Cependant, la gestion des versions a vu le jour en tant que discipline permettant de résoudre certains défis courants car les problèmes peuvent avoir des répercussions sur les bénéfices, avec des bugs et des plantages qui coûtent beaucoup de temps et d’argent (ainsi que des atteintes à la fiabilité et à la réputation).
Certaines organisations ont du mal à déployer le code et à passer du développement aux environnements de test et de production. Ce problème reste préoccupant pour le personnel opérationnel, même s’il a parfois mois d’impact sur les bénéfices.
Dans d’autres situations, la structure interne d’une organisation peut donner lieu à des conflits entre les équipes, et la gestion des versions peut réduire les frictions. De même, lorsque de nombreuses équipes de livraison travaillent de concert, il est plus probable que le travail d’une équipe perturbe celui d’une autre. Un processus efficace de gestion des versions peut aider les organisations à éviter un certain nombre de problèmes.
Gestion des versions et DevOps dans un monde Agile
Les organisations qui basent leur développement de logiciels sur les fameux principes Agile produisent généralement des versions plus fréquentes. L’approche Agile de la publication de logiciels est dénommée livraison continue, une méthode qui vise à créer du code prêt pour le déploiement à tout moment. Elle élimine presque intégralement les étapes conventionnelles de l’intégration et des tests et automatise le processus de publication sur des cycles très courts.
Software product development expert and author Jon Quigley of Value Transformation notes that studies have shown an inverse relationship between project size and success. He also says research suggests that customers do not use 45 percent of developed features. These statistics argue for small, focused releases that prioritize features highly valued by customers. “The upshot of all of this has driven deliveries of software or development of increments of software that are small, the smaller the better,” he says.
Dans le cadre de la livraison continue, la gestion des versions reste le point de connexion essentiel entre le développement et la production. La gestion des versions consiste à vérifier l’intégrité du code et à s’assurer qu’il fonctionne comme prévu. Les méthodes Agile abattent les cloisonnements souvent présents dans les méthodologies en cascade, mais exigent une documentation fournie pour faire en sorte que les processus soient clairs.
M. Gutierrez de chez Boeing affirme qu’il existe beaucoup de confusion autour de la livraison continue et d’une autre pratique répandue, le déploiement continu. « Le concept de déploiement continu consiste à déployer presque immédiatement en production chaque changement apporté à la base de code si les résultats du pipeline sont concluants. Le concept de livraison continue consiste à faire passer toute modification de la base de code par le pipeline jusqu’au point de déploiement dans des environnements hors production. L’équipe détecte et résout les problèmes immédiatement au lieu d’attendre le moment de la publication de la base de code. La qualité de la base de code est toujours suffisante pour assurer une publication. C’est l’entreprise qui décide du moment où il convient de publier la base de code en production », explique-t-il.
Pour publier efficacement la base de code en production, les responsables des versions comptent sur trois éléments : l’automatisation, l’état d’esprit DevOps et l’intégration continue. L’automatisation concerne principalement les fonctions de test, tandis que l’état d’esprit DevOps améliore considérablement la coordination entre le développement et les opérations (les personnes chargées de la livraison et des infrastructures peuvent être les mêmes) afin de faciliter la transition potentiellement abrupte du développement aux opérations.
L’intégration continue, quant à elle, désigne la pratique qui consiste, pour les développeurs à mettre fréquemment à jour des copies de travail du code sur une ligne principale, généralement environ une fois par jour. L’intégration continue, qui repose sur un système strict de tests automatisés, vise à corriger rapidement les erreurs et à accélérer le processus de changement.
Modèle de plan de publication Agile
La planification agile des versions a lieu avant le premier sprint, pour vous permettre de vous concentrer sur les objectifs de la version, ses fonctionnalités et l’affectation des ressources. Ce modèle de version Agile vous permet de répertorier toutes vos tâches, d’affecter chaque tâche à un sprint et de calculer la durée en fonction des dates de début et de fin. Vous pouvez également indiquer l’avancement de chaque tâche dans le menu déroulant et définir chaque objectif correspondant.
Modèle de plan de test Agile
Dans le cadre des projets Agile, la phase de test est un processus dynamique et itératif destiné à générer les informations les plus à jour pour définir les tests et éviter tout malentendu sur la portée. Ce modèle de plan de test vous permet de suivre les actions, les résultats attendus et les résultats réels ainsi que les réussites et les échecs des tests.
Télécharger le modèle de plan de test Agile — Excel
Gestion des versions avec la bibliothèque d’infrastructures informatique/gestion des services informatiques
La gestion des services informatiques est un sur-ensemble d’activités que les organisations utilisent pour concevoir, planifier, livrer, exploiter et contrôler les services informatiques qu’elles proposent. Elle recouvre également un ensemble détaillé de pratiques connu sous le nom de « bibliothèque d’infrastructures des technologies de l’information ». Dans les organisations qui gèrent leurs opérations informatiques à l’aide de la ITSM, et plus particulièrement d’ITIL, la gestion des versions s’appuie sur les principes ITIL.
Sous sa forme actuelle, connue sous le nom d’ITIL 2011, ITIL se compose de cinq volumes. Le troisième volume sur la transition des services, qui concerne la fourniture de services à usage opérationnel, aborde la gestion des versions. Comme on le devine, le processus de gestion des versions et du déploiement vise à « planifier, programmer et contrôler la transition des versions vers les environnements de test et de production ». Le troisième volume aborde également la gestion du changement.
Dans les organisations ITIL, les versions sont beaucoup moins fréquentes que dans les organisations Agile. Les processus de publication ITIL sont gérés à l’aide de tickets ITSM, avec un moindre recours aux processus de publication automatisés. Cela ne veut pas dire qu’ils soient moins efficaces. Les organisations qui mettent en œuvre des pratiques ITIL ne se contentent pas de rechercher l’efficacité accrue des processus de publication ; elles peuvent également dégager des bénéfices financiers et augmenter la valeur commerciale des services qu’elles proposent.
Gestion des versions d’entreprise
La gestion des versions d’entreprise (GVE) permet aux entités dotées de logiciels importants ou complexes, par exemple les systèmes de santé, les grandes entreprises, les universités, etc. de gérer les versions globalement, au niveau organisationnel La GVE concerne la coordination entre les différentes versions de logiciels et la manière dont elles s’inscrivent dans les plans, stratégies et calendriers plus larges de l’organisation.
Pourquoi est-ce important ? Imaginez une organisation qui développe des systèmes logiciels complexes. Plusieurs groupes de développement travaillent sur différents éléments de ces grands systèmes. En interne, cette structure a du sens car elle permet aux développeurs de se spécialiser, de se concentrer et de créer des composants pièce par pièce. Mais, en fin de compte, les éléments doivent converger au sein d’un système unique et parfaitement intégré. Sans une gestion globale des versions au niveau de l’entreprise, le portefeuille informatique de l’organisation manquerait de cohérence.
La GVE permet aux organisations de déployer de grands produits logiciels qui fonctionnent efficacement comme un ensemble intégré. Les efforts de GVE obligent généralement de nombreux responsables des versions à travailler en tandem en vue d’une synchronisation de leurs versions respectives.
Gestion des versions et domaines clés de connaissance du PMI
Dans un article l’an 2000 présenté lors des séminaires et symposium annuels du Project Management Institute, Franck Aguilh évoquait la prise de conscience émergente, parmi les entreprises de développement de logiciels, qu’une discipline spécialisée axée exclusivement sur la gestion des versions était nécessaire. C’est le responsable des versions plutôt que le chef de projet qui jouerait ce rôle, car le chef de projet a des priorités beaucoup plus larges.
M. Aguilh définissait une gestion des versions réussie comme un processus qui atteignait quatre objectifs principaux : le déploiement dans les délais, le déploiement conforme au budget, l’impact négligeable sur les clients existants et la réponse aux exigences des nouveaux clients, tout en gardant à l’esprit les pressions concurrentielles et les avancées technologiques. Il y décrivait également la gestion des versions comme un processus impliquant plusieurs « tâches majeures » devant être effectuées par des « organisations » distinctes.
La gestion des versions exige la coordination entre de nombreux services au sein d’une organisation, chacun d’entre eux exécutant des fonctions spécialisées. Les « organisations » décrites par M. Aguilh s’étendent des ventes et du marketing à la RD, aux opérations et à l’ingénierie des systèmes, en passant par l’assistance clientèle et les services juridiques.
« Une publication réussie exige une synchronicité entre les services », explique Mme Dunbeck de chez BitTitan. « Les développeurs doivent vérifier le code aux bons endroits. L’AQ doit effectuer des vérifications. Les services opérationnels doivent gérer les différents sites et préparer la version pour le déploiement. Mais ce sont uniquement des éléments techniques. Si vous n’avez aucun moyen de communiquer sur le changement en interne, vos commerciaux auront des surprises lorsqu’ils s’apercevront que certaines fonctionnalités ou boutons ont changé alors qu’ils sont en train de présenter le système aux clients. Si vous ne signalez pas les changements via des notes de publication, des articles du centre d’aide ou autre, votre équipe d’assistance ne sera pas en mesure de répondre aux questions posées et vos clients n’obtiendront pas les réponses dont ils ont besoin », souligne-t-elle.
« Le moyen le plus simple de résoudre ces problèmes est d’identifier clairement vos parties prenantes pour la version et de solliciter leur participation fréquemment tout au long du cycle du projet. Chaque organisation a des préférences de communication différentes. Les réunions, la messagerie instantanée, une page Wiki ou simplement un e-mail constituent tous de bons moyens de tenir les gens au courant. L’important est d’identifier une fréquence, puis de s’y tenir », conclut Mme Dunbeck.
Selon la vision de M. Aguilh, la gestion des versions repose en partie sur l’application des principes de gestion de projet aux publications de logiciels. Il s’agit des principaux domaines des processus de gestion de projet : lancement, planification, exécution, contrôle et clôture.
Cependant, M. Aguilh a également décrit neuf processus spécifiques à la gestion des versions. Voici une description de ces neuf processus ainsi que de leur ordre d’exécution :
- Demande de produit fonctionnelle (DPF) : Il s’agit du mécanisme qui permet à un « groupe fonctionnel » de déposer une demande formelle de nouvelles fonctionnalités ou fonctions à ajouter au logiciel.
- Processus de documentation : L’équipe met en place des protocoles de partage d’informations pour la prochaine version.
- Processus d’emballage des versions : Au cours de ce processus, l’équipe prend une décision sur ce qui entre dans la version finale, en fonction de facteurs tels que la pression du marché, le coût, les recettes, le temps de développement et l’intégration.
- Processus de développement/processus de contrôle des changements : ces deux étapes s’exécutent en tandem, et elles se passent d’explication. Pendant le développement, les portails de qualité peuvent être utilisés pour indiquer les jalons du cycle de développement. Le contrôle des modifications se poursuit dans les tests en laboratoire et sur le terrain, qui permettent de vérifier à la fois si les nouvelles fonctionnalités fonctionnent comme prévu et si elles ont impacté les fonctionnalités existantes.
- Processus de formation : Il s’agit de former le personnel de soutien technique, le personnel des ventes directes et du marketing, et le personnel de télémarketing.
- Tests clients : Cette étape se produit via des versions bêta destinées aux clients.
- Processus de notification des clients : La dernière étape avant le déploiement consiste à informer les clients qu’une nouvelle version va être publiée.
- Déploiement : Le déploiement lui-même est un processus en plusieurs étapes qui comprend le pré-déploiement, le déploiement réel et le post-déploiement.
M. Aguilh suggère que les processus de gestion des versions correspondent assez étroitement à ceux de gestion de projet. Par exemple, la DPF et l’emballage des versions consistent essentiellement à définir la portée et à planifier, tandis que la qualité correspond à la documentation, au développement, au contrôle des changements et à la formation. L’exécution et le contrôle, quant à eux, correspondent à la formation, aux tests clients, à la notification des clients et au déploiement. La clôture, bien entendu, correspond au déploiement. Il est donc évident que des parallèles utiles peuvent être établis entre la gestion de projet et la gestion des versions et qu’un responsable des versions efficace doit posséder les mêmes compétences qu’un chef de projet.
Processus de gestion des versions par étapes du cycle de vie du développement de logiciels
Comme nous l’avons déjà expliqué, les processus de gestion des versions s’alignent sur les processus fondamentaux de gestion de projet. Examinons désormais comment les processus de gestion des versions s’alignent sur les étapes du cycle de vie du développement de logiciels (CVDS). Le CVDS comprend généralement six phases :
- Collecte et analyse des exigences
- Conception
- Mise en œuvre ou codage
- Tests
- Déploiement
- Maintenance
Au cours du développement, les responsables élaborent une politique de publication, c’est-à-dire un document qui définit la portée, les principes et les objectifs finaux du processus de gestion des versions. Le document s’appuie sur les objectifs stratégiques de l’organisation pour informer et guider le processus de gestion des versions. Pour exemple, consultez les politiques de publication de l’Apache Software Foundation, qui promeut les projets de logiciels open source dans l’intérêt collectif.
Les responsables des versions élaborent des plans de publication basés sur la politique de publication. Ces plans constituent des lignes directrices générales pour le déploiement de plusieurs versions.
Au cours de la phase de conception, le responsable des versions s’assure que les ressources matérielles et logicielles destinées à prendre en charge la version sont conçues et configurées. Ensuite, le codage commence.
Pendant la mise en œuvre, les développeurs créent et configurent le code. Pendant les tests, les testeurs essaient le code dans un environnement opérationnel. Pendant le déploiement, le personnel lance une version de production du logiciel, et l’équipe d’assurance qualité effectue un examen de la qualité pour vérifier que la version répond aux exigences stipulées. Si la version réussit l’examen de qualité, elle est validée et passe en production ; ce sceau d’approbation est dénommé version acceptée. Si des bugs subsistent, l’équipe rejette la version. Une version acceptée comporte un plan de déploiement qui couvre les détails du déploiement, et l’entreprise informe les clients et les utilisateurs finaux de la publication à venir. Une formation peut s’avérer nécessaire.
Les unités de publication sont déployées en production pour un lancement complet. À ce stade, certaines organisations choisissent de vérifier la mise en œuvre afin de confirmer que la version fonctionnera correctement lorsqu’elle sera mise en production.
Au cours de la phase de maintenance, les développeurs examinent les problèmes de la version et du journal à résoudre pour la prochaine version.
Modèle de calendrier de gestion des versions
Pour clarifier le calendrier de toutes vos activités de publication, créez un calendrier de gestion des versions. Utilisez ce modèle pour suivre les principaux livrables et échéances et faire en sorte que tout le monde reste sur la même longueur d’onde.
Télécharger le modèle de calendrier de gestion des versions
Que recouvrent les concepts de déploiement, de publication et d’expédition ?
Même si le terme déployer est souvent utilisé de manière interchangeable avec les termes publier et expédier, il ne signifie pas exactement la même chose. Le déploiement représente l’installation ou l’exécution d’une nouvelle version de code sur un serveur, c’est-à-dire l’activation du logiciel. Ce déploiement peut se produire sur un serveur de test plutôt que sur un serveur de production. La publication est la forme logicielle de cette nouvelle version. Elle se destine à un public allant au-delà des développeurs, que ce soit d’autres membres de l’organisation ou des clients. Une version porte généralement un numéro de version. Lorsqu’un client déploie une version, cela est généralement décrit comme une installation du logiciel. L’expédition s’entend du processus d’obtention du code tout au long de la boucle de création, de test et de déploiement.
Le déploiement est un moment crucial du cycle de vie du développement de logiciels et du cycle de gestion des versions. Le déploiement marque le moment où la nouvelle version du logiciel est mise à disposition et où la nouvelle version est mise en ligne. Selon Paul Jackson, de la faculté d’Informatique de l’Université d’Edimbourg, le déploiement consiste à « faire passer les logiciels des mains des développeurs aux mains des utilisateurs ». Pour cette étape, les utilisateurs finaux peuvent avoir besoin d’une formation.
M. Jackson fait remarquer que le déploiement est souvent problématique : plus de 50 % des logiciels commandés ne sont pas utilisés, principalement parce qu’ils échouent au moment du déploiement. Si un logiciel rencontre des problèmes lors du déploiement, les développeurs « reviennent » à la version précédente jusqu’à ce que les problèmes soient résolus.
M. Jackson rapporte également que 80 % des dépenses en logiciels mis en service s’effectuent lors du déploiement et après. Bien entendu, cela ne signifie pas nécessairement que le déploiement lui-même est un échec ; il se peut simplement que les problèmes de développement ne se posent qu’au moment du déploiement.
Mais parfois, c’est bien le déploiement qui pose problème. Il est possible que le client ne soit tout simplement pas préparé au changement d’expérience produit que les publications systèmes de grande envergure exigent souvent. La non-acceptation des logiciels peut également résulter d’un certain nombre d’autres facteurs : le matériel du client est incapable de prendre en charge la nouvelle version ; le client a du mal à installer le logiciel ; le manque de formation constitue un obstacle ; ou la nouvelle installation « brise » les autres logiciels du client.
L’automatisation et la formation permettent de résoudre de nombreux problèmes directement associés au déploiement, de sorte que l’utilisateur final n’a pas à réfléchir à des paramètres tels que la compatibilité du système. Le fait de s’appuyer sur les bonnes pratiques en matière de gestion des versions fait de ces solutions une procédure opérationnelle normalisée.
Qu’est-ce qu’un processus de déploiement de version ?
Le processus de déploiement des versions est axé sur la mise en œuvre du logiciel dans un environnement de production. Pour que cela se produise, le logiciel doit être testé et officiellement accepté par le responsable du produit ou une autre partie prenante de l’entreprise. Au cours du processus de déploiement, les utilisateurs reçoivent une formation sur la mise à jour logicielle, et les membres de l’équipe effectuent une évaluation ou un examen des performances et du déroulement du déploiement.
Bonnes pratiques en matière de gestion des versions
Dans le domaine de la gestion des versions, les bonnes pratiques s’entendent des lignes directrices créées et affinées par les entreprises qui ont déjà mis en œuvre ITIL avec succès. Le Cabinet Office britannique est responsable des lignes directrices et de leur publication. Les processus de gestion des versions d’ITIL ont été utilisés avec succès par des programmes spatiaux, des services de santé, des banques et des entreprises de divertissement. Les organisations doivent modifier les lignes directrices pour les adapter à leurs propres exigences et capacités. N’oubliez pas, cependant qu’elles ne sont pas parole d’évangile, mais qu’il s’agit simplement d’un cadre de départ.
C’est pendant la transition du développement à la production que la gestion des versions acquiert le plus d’importance, même si elle commence par la planification des versions pendant le développement. Par exemple, il est utile de mettre en place un conseil consultatif sur le changement qui supervise le changement dans l’ensemble de l’organisation. Il est également judicieux de concevoir un système de gestion des versions unique qui peut être utilisé dans tout le CVDS.
De même, l’élaboration d’une liste de vérification du processus de publication favorise la transparence et l’interprétation uniforme du processus de gestion des versions et de la valeur commerciale qu’il génère. En complétant avec le livre Checklist Manifesto d’Atul Gawande, l’utilisation d’une liste de vérification permet d’exercer plus facilement un contrôle sur le processus de publication, en particulier s’il existe des indicateurs à surveiller. En outre, un sponsor principal actif est utile.
“The most common pitfall with release management is not following a release checklist,” says Chris Harding, a Release Manager at Microsoft. “The details in a release checklist are key. You may be having an off day, or something may distract you while you’re configuring a product, but the checklist never lies,” he points out.
M. Harding estime qu’une simple erreur a provoqué le lancement par Walmart Canada de plusieurs jeux vidéo sur son site Web en mai 2018 avant leur déploiement officiel lors d’une conférence du secteur, et qu’une liste de vérification aurait permis d’éviter cette erreur. « Le calendrier a probablement été mal défini pour les pages de produits, et personne ne l’a compris avant le déploiement au public. Dans le milieu médical, les listes de vérification sauvent des vies. Si la gestion des versions n’a pas de résultats aussi spectaculaires, elle peut probablement sauver votre travail ».
Modèle de liste de vérification des versions logicielles
Afin de suivre toutes vos activités de lancement, envisagez de recourir à une liste de vérification. Ce modèle est disponible aux formats Microsoft Word et Excel, et propose des espaces pour les notes et le statut marketing, le développement de produits, l’assurance qualité, l’ingénierie/DevOps, l’expérience utilisateur, le support technique, les services et les tâches juridiques. Modifiez le formulaire en fonction des besoins de votre projet.
Télécharger le modèle de liste de vérification des versions logicielles
Certaines bonnes pratiques relèvent simplement du bon sens. L’intégration continue, par exemple, améliore la qualité de la version finale en permettant de détecter les erreurs rapidement. Et il n’est pas judicieux de lancer une version un vendredi, car cela ne laisse aucun délai, pendant la semaine de travail, pour le dépannage si quelque chose ne fonctionne pas. Il est également utile de programmer les publications pendant les périodes de faible trafic (il faut donc connaître les fenêtres d’activité des clients) afin de pouvoir intervenir si les choses tournent mal. L’autre option consiste à procéder au déploiement étape par étape, avec une mise à disposition des fonctionnalités à un petit nombre d’utilisateurs à la fois. Et bien entendu, les bases de données doivent être sauvegardées avant les publications.
Enfin, n’oubliez pas que la mise en œuvre d’un processus de gestion des versions est un processus en soi. La gestion des versions peut être réalisée par itérations et l’automatisation par étapes. N’essayez pas de forcer le processus.
Outils logiciels de gestion des versions
Les outils logiciels peuvent accélérer et faciliter le processus de gestion des versions.
Par exemple, les logiciels d’aujourd’hui sont conçus pour prendre en charge plusieurs plateformes, des navigateurs Internet aux serveurs d’applications et aux systèmes d’exploitation. Ils doivent donc être testés dans ces environnements avant leur sortie. La création et la maintenance de tous les environnements nécessaires aux tests posent problème. Mais il existe une solution facile : utiliser des services virtualisés et cloud, tels que Selenium et SmartBear, qui simplifient le processus de déploiement des configurations pour les plateformes cibles en créant un environnement simulé de chaque plateforme pour les tests.
“A common challenge is automating the release but not having good automated testing in place,” notes Brian White, Senior Solutions Architect at custom software developer Small Footprint. “If you don’t have confidence in the quality of your release, it doesn’t matter how fast it can be deployed if it’s always going to break when someone starts using it,” he says.
Pour faciliter l’ensemble du processus de gestion des versions, les plateformes de développement de logiciels et les systèmes de gestion des versions, tels que GitHub, Jira et bien d’autres, offrent une intégration étroite des éléments nécessaires à une publication réussie. Ils peuvent être utilisés dans l’ensemble du CVDS, de la planification des versions à la production.
Ces outils, généralement évolutifs et basés sur les besoins de l’organisation, centralisent les fonctionnalités de mise à jour et d’administration, ce qui est particulièrement utile lorsqu’ils sont accessibles sur Internet en tant qu’outils SaaS (logiciels en tant que services). Les meilleurs outils prennent également en charge les tests et le déploiement des composantes de gestion ainsi que la gestion des changements et les intégrations avec des composantes de gestion des services tiers, qui permettent un système de livraison de bout en bout. Recherchez des outils conformes aux directives du forum ITIL V3 sur la gestion des services informatiques.
Les outils qui permettent une automatisation au moins partielle du processus de publication sont extrêmement utiles. Il est parfois possible d’automatiser la livraison de logiciels jusqu’à la production ou de mettre en place une série semi-automatisée de processus avec approbations et déploiements à la demande.
Parmi les fonctionnalités utiles, il est possible de suivre les changements entre les versions pour aller aisément à la racine des problèmes et disposer d’une structure qui permet de revenir facilement à la dernière version qui fonctionne. La journalisation des commentaires sur les applications, une fonctionnalité qui peut être transférée vers un backlog pour les versions à venir, est également utile.
En outre, envisagez des outils capables de prendre en charge l’intégration et le déploiement continus. Le déploiement continu va au-delà de la livraison continue pour déployer immédiatement les changements au fur et à mesure qu’ils passent par le pipeline de production. Cette approche accélère le processus de commentaires et améliore considérablement l’efficacité.
Métriques et ICP de gestion des versions
Une fois qu’un processus de gestion des versions arrive à maturité, un responsable des versions peut se tourner vers les métriques de performance dans le but d’améliorer le processus. Examinons-en quelques-uns :
- Temps d’interruption des versions : Il s’agit de la première métrique importante. Toute version de logiciel court un risque d’interruption dont la durée peut varier de quelques minutes à plusieurs heures, voire plusieurs jours. Les interruptions ne sont pas mauvaises en soi ; elles sont souvent nécessaires. Cela dit, il est important de pouvoir faire la différence entre les différents types d’interruption. Les interruptions estimées, par exemple, sont des interruptions nécessaires et intégrées au calendrier de publication; il est utile de les comparer aux durées réelles, qui sont mesurées après la publication. Il existe également des interruptions imprévues qui, sur certaines versions, peuvent signaler une non-résolution de problèmes de fond.
- Type et le niveau de priorité des versions : chaque version est classée comme majeure, mineure ou entre les deux et se voit attribuer une priorité : élevée, moyenne ou faible. Examinez la répartition par type et par priorité sur un certain nombre de versions. Il doit y avoir une bonne sélection de versions en termes de taille et de priorité. Un trop grand nombre de versions majeures pour un même produit peut indiquer de graves problèmes d’assurance qualité, tandis que le fait d’avoir trop de versions prioritaires suggère que votre équipe est en permanence en train de gérer des urgences, ce qui a tendance à épuiser tout le monde.
- Nombre de publications dans les délais : Étant donné que la sortie dans les délais n’est pas assurée, cela concerne tout autant les retards de lancement. Cette métrique fournir de nombreuses informations intéressantes. Par exemple, certaines équipes de développement ont-elles plus de publications tardives ou dans les délais que d’autres ? Existe-t-il une tendance à la livraison tardive ou dans les délais en fonction de la hiérarchisation des versions ? Quelles sont les causes profondes des publications tardives répétées ?
Certaines métriques intéressantes peuvent être suivies au niveau de l’entreprise. Il s’agit notamment de la taille des versions d’entreprise sous trois perspectives différentes : les projets, les déploiements de systèmes et les fonctionnalités. Un autre ensemble utile de métriques permet de suivre le nombre de projets, de systèmes et de fonctionnalités qui ne relèvent plus de la portée (« de-scoped »). (Le de-scoping désigne les situations dans lesquelles un élément qui devait sortir n’est finalement pas publié et est donc retiré de la version d’entreprise afin de ne pas la retarder).
Études de cas concernant la gestion des versions
Nous avons beaucoup évoqué la théorie jusqu’à présent, et vous vous demandez peut-être comment fonctionne la gestion des versions dans le monde réel. Microsoft est un exemple idéal à cet égard.
L’ingénierie des services de base (CSE, Core Services Engineering) de Microsoft s’appuie sur une combinaison d’intégration continue, de livraison continue et d’une plateforme hébergée dans le cloud dénommée Visual Studio Team Services (VSTS). L’approche du développement, dénommée « ingénierie moderne », est basée sur les principes du développement Agile et du DevOps.
Il suffit d’observer comment Microsoft structure son développement autour de la livraison continue pour comprendre l’avantage que lui procure une meilleure gestion des versions. Les ingénieurs logiciels de Microsoft cherchent à créer un produit de viabilité minimale, qui attire les premiers utilisateurs tout en permettant aux développeurs de recueillir des commentaires sur les versions ultérieures.
Les développeurs de Microsoft peuvent tester du code dans n’importe quel environnement de déploiement à tout moment, et ils utilisent la « composantisation » (division en composants) pour faciliter la création du code. Dans le cadre du processus de gestion des versions de Microsoft, ils peuvent démarrer des versions et un déploiement sans surveillance en seulement quelques minutes, sans se disputer les ressources disponibles. De plus, leur processus de validation des déploiements est automatisé.
La CSE adopte également les principes Agile de la conception itérative et du prototypage rapide tout en utilisant l’automatisation pour réduire les temps de test. Cela signifie que la CSE peut accélérer ses cycles de publication, corriger rapidement les problèmes et fournir des mises à jour et des améliorations continues en fragments plus petits, ce qui permet de réduire les risques en diminuant le temps passé à développer chaque fonctionnalité.
Et les entreprises technologiques ne sont pas les seules à tirer parti de la gestion des versions. Entre 2008 et 2010, la division informatique du Dépositaire central de Turquie a entrepris une automatisation étendue de la gestion de la configuration, de la gestion des dépendances, de la gestion de l’infrastructure, de la gestion des changements, de la gestion des bases de données et de la gestion de la configuration des applications afin d’« éliminer complètement » les problèmes liés aux versions, de raccourcir le temps de publication et de réduire considérablement les erreurs liées au déploiement.
Chez United Airlines, un modèle de publication en quatre étapes s’appuyant sur des données abondantes et couvrant la planification, la coordination, l’exécution et l’automatisation, a aidé l’entreprise à passer d’une gestion des versions centrée sur les feuilles de calcul à un système centralisé de suivi et de gestion des versions sur tableau de bord.
Comment améliorer la gestion des versions ?
La compréhension de l’état actuel de votre processus de gestion des versions est nécessaire pour améliorer les capacités de gestion des versions de votre organisation. Vous devez obtenir une compréhension à la fois quantitative et qualitative.
Quantitativement, vous devez recueillir quelques métriques de base, y compris les délais moyens de publication, le type et la priorité des versions, le nombre d’erreurs et le nombre de versions en retard. Ces métriques servent à la fois à identifier l’état actuel de la gestion des versions et à déterminer les bases de performance.
Qualitativement, nous vous conseillons de parler aux personnes qui participent au processus de gestion des versions, en particulier dans les domaines où le développement et les opérations se chevauchent, afin de recueillir leurs opinions. Ces personnes seront en mesure de décrire des réalités qui n’apparaissent pas dans les chiffres.
Vous pouvez maîtriser la gestion des versions en établissant un cycle de publication régulier afin de renforcer la cohérence. (Ce ne sera pas possible pour toutes les versions, bien sûr, mais vous pouvez le faire pour les publications importantes planifiées à l’avance). Mettez en place des processus de lancement légers au lieu d’essayer de développer une culture dès le début. Cela vous permettra d’établir dès le départ une infrastructure de gestion des versions, avant de la tester et de la réviser si nécessaire.
Au fil du temps, les processus qui fonctionnent bien deviendront une pratique standard. Selon votre enquête initiale sur la gestion des versions, vous pouvez commencer à imposer des exigences de qualité plus strictes et à améliorer les critères d’efficacité. Vous pouvez réduire l’impact des publications sur vos utilisateurs en éliminant les temps d’interruption et en effectuant des tests de régression. À ce stade, vous pouvez également commencer à réfléchir à la régularisation et à l’automatisation des processus, par exemple les tests et les vérifications.
Une culture de publication véritablement collaborative prend du temps à se mettre en place, et elle doit s’appuyer sur une infrastructure de lancement pour se développer. Vous pouvez entretenir cette culture en investissant dans votre personnel et dans des outils et techniques de gestion des versions qui encouragent les gens à adopter une approche globale du processus de gestion des versions.
L’amélioration de la communication et de l’accès à l’information favorise la coordination. Faites savoir aux gens que des améliorations des versions sont à prévoir, car il est important de définir des attentes positives. « Les équipes sont confrontées à des défis lorsqu’elles considèrent les publications comme un obstacle purement technique et omettent de soigner les communications avec les parties prenantes au sein de l’entreprise. Pour surmonter ce défi, assurez-vous que tous les membres de l’équipe comprennent les objectifs et les risques et communiquez les changements aux utilisateurs finaux afin d’éviter les surprises », explique M. White de chez Small Footprint.
Le travail du responsable des versions
Si l’accompagnement des développeurs et des opérations vers un objectif final et une date limite de production vous intéresse, envisagez de devenir un responsable des versions.
Un responsable des versions doit s’orienter dans un paysage complexe de projets, de méthodes de développement, d’infrastructures et de parties prenantes, tout en coordonnant les efforts entre toutes les parties qui contribuent à une version d’entreprise. Les responsables des versions doivent également rendre compte aux hauts responsables de l’organisation, jusqu’au PDG (bien que la gestion des versions soit parfois une fonction plus autonome dans les organisations plus matures), et c’est souvent eux qui sont pointés du doigt lorsqu'une publication tourne mal.
Selon M. Harding de chez Microsoft, il est important que les responsables des versions disposent de larges compétences en gestion de projet. « Il est essentiel de fournir aux autres parties prenantes du projet une formation et un accès afin de réduire la dépendance à l’égard d’une seule personne. Les responsables des versions disposent généralement d’un ensemble assez spécifique de compétences en résolution de problèmes, mais ils peuvent s’appuyer sur d’autres chefs de projet pour couvrir des éléments de configuration et de processus produit », explique-t-il.
Alors, quelles sont les qualités d’un bon responsable des versions ? Il connaît parfaitement le fonctionnement du développement et des opérations, c’est-à-dire à la fois le fonctionnement technique et la manière dont les gens collaborent. Il possède d’excellentes compétences de gestion du travail, du temps et surtout des personnes. Il s’engage en faveur de la qualité, de l’efficacité et des processus. Il défend l’automatisation et, sur le plan technique, doit être un opérateur compétent des référentiels de code source. En outre, il maîtrise la myriade d’interdépendances entre les projets, fonctions et services qui définissent une version d’entreprise.
Il sait également quoi croire (et ne pas croire) au sujet de la gestion des versions.
Mythes de la publication et de la gestion des versions logicielles
Il y a beaucoup d’idées reçues sur la gestion des versions, mais comment démêler le vrai du faux ? Heureusement pour nous, Slinger Jansen et Sjaak Brinkkemper, deux chercheurs à l’université d’Utrecht aux Pays-Bas, ont déjà essayé de répondre à cette question en comparant le coût et la valeur. Ils ont constaté que de nombreux mythes et idées fausses circulaient.
Mythe 1 : Les clients souhaitent se tenir à jour. En réalité, les clients ne se soucient des mises à jour que lorsqu’elles fournissent des fonctionnalités utiles. Si une version n’améliore pas leur expérience, ils la laissent de côté.
Mythe 2 : Les clients doivent (du point de vue du fournisseur) se tenir à jour. Dans ce cas, les fournisseurs se soucient davantage que les clients de l’utilisation de la version définitive du logiciel. Comme nous l’avons déjà souligné, les clients ne procèdent aux mises à jour que lorsqu’ils le souhaitent vraiment. Ils continuent volontiers à utiliser les versions plus anciennes le reste du temps.
Mythe 3 : La dernière version est toujours la meilleure. Selon le cas d’utilisation des clients, une ancienne (ou très ancienne) version peut bien fonctionner, alors qu’une nouvelle version nécessite un certain temps pour apprendre à utiliser une nouvelle interface ou de nouvelles fonctionnalités.
Mythe 4 : Les correctifs peuvent attendre la prochaine version majeure. Malheureusement, « la prochaine version majeure » sort rarement dans les temps. Et, jusqu’à ce qu’elle sorte enfin, les problèmes persistent, ce qui représente un fléau pour les clients.
Mythe 5 : Les solutions de contournement doivent être évitées à tout prix. Lorsque l’alternative est une mise à niveau coûteuse et chronophage vers une nouvelle version, les gens n’hésitent pas à trouver des solutions de contournement simples.
Mythe 6 : Les clients veulent toujours de nouvelles fonctionnalités. Si les nouvelles fonctionnalités entravent les flux de travail établis et qu’ils connaissent bien, ils n’en veulent pas.
Mythe 7 : Les versions fréquentes ne sont pas souhaitables. Tant que vous ne les proposez pas à vos clients externes à chaque fois, les versions fréquentes ne sont pas problématiques. Si les versions fréquentes peuvent raccourcir le cycle de commentaires, elles les réservent généralement aux utilisateurs internes et aux clients pilotes.
Mythe 8 : Un client qui ne se plaint pas est un client satisfait. Ce sont les clients qui contactent l’assistance le plus souvent au début du déploiement qui se révèlent le plus satisfaits du produit. Contactez vos clients.
Mythe 9 : Les clients lisent les notes de publication. Ce n’est pas le cas, bien sûr. Ils le font s’ils sont obligés de le faire, c’est-à-dire s’ils sont limités dans le choix de fournisseurs et s’ils choisissent des logiciels professionnels, mais ils préfèrent de loin les informations ciblées qui résument ce qu’ils doivent retenir en tant que catégorie particulière de clients.
Mythe 10 : Il n’est pas souhaitable que de nombreuses versions différentes soient déployées. Cela peut poser problème si le fournisseur propose une assistance continue aux clients utilisant des versions antérieures. Mais même dans ce cas, ce n’est pas une catastrophe. Le fait qu’un petit nombre de clients travaille sur l’ancienne version n’est pas un problème ingérable.
Grandes tendances en matière de gestion des versions
Les pratiques Agile et l’automatisation sont en train de devenir des principes fondamentaux de la gestion des versions, et ce à juste titre. L’automatisation raccourcit les délais de publication et peut réduire considérablement le risque d’erreur. Les pratiques Agile favorisent l’adoption de l’automatisation de la construction, de l’automatisation des tests, de l’automatisation du déploiement et de l’automatisation des commentaires, ce qui réduit la charge de travail de l’équipe de développement.
« L’automatisation et l’utilisation de plateformes virtualisées/sur le cloud permettent et alimentent une autre grande tendance en matière de gestion des versions : la livraison continue », explique Gabriel Gutierrez, responsable des versions chez Boeing. « Grâce à la livraison continue, chaque nouvelle révision logicielle est automatiquement créée, testée et préparée pour le déploiement, ce qui permet de transformer rapidement les idées en réalité. La livraison continue permet des déploiements plus fréquents, ce qui se traduit par des commentaires plus fréquents de la part du client. Cela permet de gagner du temps en tirant des enseignements plus rapidement et en apportant les changements dont les clients ont besoin et qui les importent », ajoute-t-il.
La tendance consistant à utiliser des systèmes de contrôle des versions distribués (SCVD) tels que GIT, Mercurial et Perforce, qui changent complètement la donne en matière de collaboration, a pris de l’ampleur. Les SCVD permettent aux utilisateurs de conserver des référentiels autonomes sur des ordinateurs locaux, avec des historiques des versions complètes. Cette fonctionnalité permet de travailler hors ligne et de valider des modifications qui resteront sur le système local. Les développeurs peuvent apporter des modifications sans effet sur le code central, ce qui est idéal pour l’expérimentation.
Les observateurs estiment que la culture et les pratiques DevOps vont se généraliser dans les grandes entreprises et qu’il est réaliste de viser l’automatisation de toutes les étapes. Les startups, quant à elles, commenceront probablement à adopter la méthodologie DevOps dès le départ. En effet, le DevOps, s’il est mis en œuvre correctement, se traduit par des temps de défaillance plus courts, des délais de récupération plus rapides et un plus grand nombre de déploiements, ce qui, à son tour, entraîne une diminution des temps d’interruption (très coûteux). Au fur et à mesure que l’adoption du DevOps gagne du terrain, le processus de déplacement vers la gauche fait de même. Ainsi, les tests automatisés et la surveillance des performances se produisent plus tôt dans le cycle de vie et les vérifications de sécurité font partie du pipeline de livraison.
« Bien que cette tendance ne soit pas nouvelle, les déploiements plus fréquents et plus rapides, qui représentaient autrefois un défi technique, représentent désormais une véritable attente de la part des parties prenantes », ajoute M. White de chez Small Footprint. « Comme elles sont mieux informées des possibilités et avantages des déploiements plus fréquents, les parties prenantes ne souhaitent plus attendre des semaines entre les versions et poussent les équipes de développement à publier plus souvent. Si elles ne disposent pas d’une solide infrastructure d’intégration continue/de livraison continue, ces équipes peuvent subir un stress considérable », conclut-il.
M. Quigley explique que l’exécution réussie de ces incréments rapides et bien définis de contenus logiciels exige « un certain niveau de diligence concernant la gestion de la configuration et le suivi de la croissance d’un produit au fil du temps, car des itérations plus fréquentes sont livrées au client ».
Ressources supplémentaires sur la gestion des versions
Pour une présentation plus technique de la gestion des versions, consultez ce livre blanc publié par Jez Humble de chez ThoughtWorks Studios. Après l’avoir lu, cous pourrez consulter le vaste éventail de ressources d’Electric Cloud qui abordent la gestion des versions en détail.
Si vous envisagez une carrière dans la gestion des versions et que vous travaillez déjà sur Agile, consultez cette brève formation de Jan-Erik Sandberg sur Pluralsight. Et si vous pensez que l’obtention d’une certification ITIL peut vous être utile, Pink Elephant propose des formations officielles de certification ITIL dès le niveau Débutant.
Enfin, si vous cherchez simplement à vous plonger directement dans la gestion des versions, jetez un œil à l’approche de Harvard Information Technology.
Améliorez la gestion des versions grâce à Smartsheet pour le développement de logiciels
Donnez à vos employés les moyens de se dépasser grâce à une plateforme flexible conçue pour répondre aux besoins de votre équipe, et capable de s'adapter quand ces besoins changent. La plateforme Smartsheet facilite la planification, la capture, la gestion et la création de rapports sur le travail depuis n'importe où, ce qui permet à votre équipe d'être plus efficace et d'accomplir plus. Créez des rapports sur les métriques clés et obtenez de la visibilité en temps réel quant au travail grâce aux rapports de synthèse, aux tableaux de bord et aux flux de travail automatisés conçus afin d'aider votre équipe à rester connectée et informée. Quand les équipes bénéficient de clarté quant au travail en cours, elles peuvent accomplir bien plus dans le même temps. Essayez Smartsheet gratuitement, dès aujourd'hui.