Dans mon article précédent et le premier de cette série, j'ai présenté une nouvelle forme et un nouveau modèle de DevOps et décrit ses composants essentiels et son flux de travail.
Dans cet article, je vais explorer l'importance du cycle de publication d'une application et le rôle important qu'il joue dans notre modèle DevOps.
Mais avant de commencer, il est nécessaire que je me rappelle brièvement quelques sections essentielles de mon article précédent, en particulier SDLC, et que je réexamine également un fait que beaucoup d'entre nous dans le milieu universitaire de l'informatique ont peut-être suivi par inadvertance pendant des décennies.
Je ne vais pas détailler à nouveau les étapes, l'article précédent ayant déjà été mis en lien ici. Mais je vais jeter un coup d'œil au diagramme SDLC une fois de plus dans un instant.
Importance du cycle de vie des versions logicielles dans DevOps
Le cycle de vie de la version du logiciel, ou SRLC en abrégé, est une procédure obligatoire effectuée lors du développement de toute application. C'est une nécessité cruciale car un logiciel de qualité garantit un DevOps de qualité. Cela ne peut être assuré efficacement que lorsque ses différentes phases sont avancées efficacement.
Le cycle de vie des versions logicielles
Un cycle de vie de version logicielle ou SRLC est la séquence de différentes étapes par lesquelles le développement d'un logiciel évolue d'une phase pré-alpha à une phase de production. Il s'agit d'un processus continu car tout logiciel aura toujours sa version mise à jour jusqu'à ce qu'il atteigne la fin de vie (EOL).
Les noms et les pratiques peuvent varier d'un développeur à l'autre. Mais en général, cinq phases essentielles sont impliquées :
- Pré-alpha :La première phase des versions logicielles qui n'inclut que les fonctionnalités principales et qui est la plus susceptible d'avoir le nombre maximum de bogues. Il n'est testé que par des développeurs et des testeurs.
- Alpha :La deuxième phase des versions logicielles est considérée comme complète et est toujours susceptible d'avoir des bogues, mais beaucoup moins que la pré-alpha. Il est testé par des développeurs et des testeurs. Mais en fonction des diverses NDA, il peut être mis à la disposition du public de manière sélective ou dans le monde entier.
- Bêta :La troisième phase est principalement axée sur la correction des bogues et des problèmes rencontrés lors des deux phases précédentes. Comme pour la version pré-alpha, la disponibilité des logiciels bêta est également basée sur les accords de non-divulgation.
- Libérer le candidat :Une version release candidate du logiciel est une version préliminaire qui a le potentiel d'être un produit final stable. En pratique générale, une version release candidate ne reçoit plus de nouveau code source pour le programme. Les modifications apportées au code source ne sont apportées que lorsque des erreurs persistent lorsqu'il est soumis à des tests de niveau de production.
- Version de production :Comme il est très évident, une version de production est le produit final qui est mis à la disposition du grand public en tant que produit stable.
Remarque :Le concept des NDA n'a pas beaucoup de valeur dans le domaine des logiciels Open Source en raison d'un modèle transparent.
Basé sur notre nouveau modèle, SRLC fonctionne en fait en deux étapes :
L'application devient sa toute première version à ce stade et progresse à travers une majorité de phases de publication (mentionnées ci-dessus) à mesure qu'elle devient plus mature et réalisable. Les bogues sont progressivement réduits et l'efficacité augmente au fil du temps.
Il s'agit de l'étape de production de SRLC où une version de développement devient sa première version stable disponible prête à être utilisée par les clients et les utilisateurs.
Pourquoi est-ce un "cycle de vie" ?
Pendant des décennies, dans le domaine académique du Génie Logiciel , le programme d'informatique de différentes universités a mentionné le modèle de processus de publication de logiciel comme un cycle. Mais le schéma qui est représenté est assez contradictoire. En règle générale, il est décrit de la manière suivante :
Sur la base d'une simple observation, il est très évident que le diagramme ci-dessus ne montre aucune propriété "de type cycle". Sur la base de ce modèle conventionnel, cela s'appelle un cycle même si le diagramme ne montre pas une telle caractéristique… cela ne peut pas s'appeler un cycle… c'est un organigramme.
Pour que cela ressemble à un cycle, la phase de production devrait revenir à la phase pré-alpha et cela n'aurait aucun sens, à moins que l'ensemble du scénario ne soit à nouveau revu de manière critique :
Vous pouvez clairement remarquer que la version stable est celle où le logiciel a atteint son plein potentiel et peut être déployé en production. Même s'il n'apparaît pas dans le diagramme, pourquoi est-il alors appelé "cycle de vie" ?
Voici la raison
Lorsque la version de production a été adoptée par les utilisateurs/clients, les développeurs du logiciel y apportent encore des améliorations en ajoutant plus de fonctionnalités, en ajustant celles existantes, en corrigeant les bogues et les problèmes de sécurité pendant la production et tout autre changement qui serait nécessaire au fil du temps. . Par conséquent, il y a toujours une version de développement constamment à l'œuvre dans les coulisses.
Aussi critique qu'un logiciel puisse être, il existe certains défauts qui ne se révéleraient que dans un scénario réel, et ces défauts sont corrigés dans la version mise à jour de toute version de production.
Réfléchissons-y un instant. Une version de production peut-elle vraiment être qualifiée de produit final si le logiciel est continuellement en cours de développement sous la forme de versions mises à jour ?
Comment revoir le diagramme et ses scénarios comme un vrai cycle ?
Pour pouvoir percevoir ce processus comme un cycle, nous devons revoir notre nouveau modèle SDLC décrit précédemment :
Si vous souhaitez l'examiner uniquement du point de vue de la version logicielle, le modèle SDLC peut être transformé en SRLC :
Une application logicielle concerne uniquement son développement, alors qu'un système logiciel concerne le développement à la fois de l'application et des processus systémiques dans lesquels elle est déployée et maintenue. Si nous simplifions davantage, nous pouvons le repenser comme suit :
Faisons un zoom sur les versions de développement zone pour voir ce qui se passe réellement et en déduire notre "Cycle de Vie":
Ici, vous pouvez observer que les quatre premières phases essentielles sont maintenant représentées dans le cadre d'un cycle réel. Chacune de ces phases fait également l'objet d'un développement d'application basé sur ADLC (étiqueté dans le diagramme comme ADLC) à mesure qu'ils passent à la phase suivante. Une fois que le développement du logiciel quitte l'étape de la version candidate, il subit le développement du système basé sur SDLC (étiqueté dans le diagramme comme SDLC) pour finalement devenir une version stable qui serait active via les déploiements de production tels que les environnements des utilisateurs finaux et des clients.
Pourquoi une version stable doit-elle maintenant revenir à un état pré-alpha ? Juste pour se représenter comme un cycle de vie ? Certainement pas.
Une version stable doit subir à nouveau un contrôle de niveau pré-alpha afin de maintenir constamment la meilleure qualité possible.
Étant donné que le produit est déjà sorti en version stable, le débogage et les tests sous les phases pré-alpha, alpha et bêta ne prennent pas très longtemps. Ainsi, vous devez garder à l'esprit qu'une fois qu'un nouveau produit est rendu public, il approche rapidement du niveau de sélection de la version candidate après son déploiement et son audit par tous les types d'utilisateurs.
Les bugs au niveau de la production en temps réel sont inévitables et quelle que soit leur nature, il est nécessaire de les réévaluer avec une approche pré-alpha. Ce n'est qu'alors que des logiciels de qualité peuvent être garantis de manière constante avec une vitesse et une efficacité optimales.
Par conséquent, ce modèle révisé peut enfin être qualifié de cycle réel et non d'organigramme conventionnel que beaucoup d'entre nous dans la communauté du développement auraient pu suivre par inadvertance pendant des décennies ! Il s'agit d'un processus continu, c'est pourquoi on l'appelle un "cycle de vie" de la version du logiciel
Si vous avez des suggestions, des commentaires ou des commentaires sur ce sujet, veuillez nous en informer dans la section ci-dessous. Nous serions ravis de vous voir vous impliquer dans des approches aussi intéressantes. Restez à l'écoute pour le prochain article de cette série :)