À propos de notre produit et de notre modèle de livraison
Présentation du produit/projet
freya fusion une plateforme technologique de pointe dédiée à la réglementation qui s'appuie sur l'intelligence artificielle et cloud-based pour rationaliser les processus de conformité. Ses principales fonctionnalités comprennent un« Regulatory Cloud » axé sur l'IApour une supervision intelligente,une modularitéentre les données, les contenus, les applications et les interfaces utilisateur pour plus de flexibilité, ainsi quedes processus réglementaires harmonisésgrâce à une planification interfonctionnelle. La plateforme propose égalementdes solutions d'automatisation intégrées, ungraphe de connaissancespour des analyses structurées et uneinterface utilisateur conversationnellepour améliorer l'interaction avec l'utilisateur. Conçue pour l'efficacité, Freya Fusion une technologie de pointe et une expertise réglementaire afin de simplifier les flux de travail complexes liés à la conformité.
Processus actuel et écosystème de livraison
Méthodologie agile et outils
Chez freya fusion, nous mettons à profit la méthodologie Agile, associée aux pratiques DevSecOps,pour garantirla sécurité, la conformité et l'efficacité,du code jusqu'au déploiement. Dans notre cadre Agile,les fonctionnalités constituent les principaux éléments de travail pour les versions. Plusieurs fonctionnalités sont regroupées et validées ensemble pour former uneversion candidate (RC), ce qui garantit une livraison incrémentale et maîtrisée de la valeur ajoutée.
Azure DevOps (ADO) et intégrations de plugins
Présentation du pipeline CI/CD
Les pipelines d'intégration continue et de déploiement continu (CI/CD) automatisent le processus de mise en production des logiciels, depuis le développement jusqu'à la mise en production, garantissant ainsides mises à jour plus rapides,une qualité constante etune réduction des erreurs manuelles.
Intégration continue (CI) – La phase de compilation et de test utilisée par l'équipe de sprint
- Validation du code: les développeurs publient leurs modifications dans un référentiel partagé (par exemple, Azure Repos, GitHub).
- Construction automatisée: le pipeline compile le code, résout les dépendances et regroupe les artefacts.
- Tests automatisés: des tests unitaires, des tests d'intégration et des analyses de sécurité (SAST/DAST) sont effectués afin de détecter les problèmes à un stade précoce.
- Stockage des artefacts: les versions validées sont stockées dans des référentiels
Déploiement continu (CD) – La phase de mise en production utilisée par l'équipe de déploiement
- Environnements de déploiement: le code passe par les étapesDevSecOps → SQA → Préproduction → Production, avec des points de contrôle.
- Déploiements automatisés: les déploiements s'effectuent via des pipelines de mise en production avec un temps d'indisponibilité minimal
- Contrôles post-déploiement: tests de fonctionnement automatisés, surveillance des performances et mécanismes de restauration mis en place et régis par SOP.
Types de versions : majeure, mineure, correctif, mise à jour d'urgence
Les versions sont classées en versions majeures, mineures, correctives ou correctifs ponctuels, en fonction de leur objectif et des fonctionnalités introduites dans chaque version.
- Majeure – Désigne une version initiale ou une version dont les nouvelles fonctionnalités ont un impact sur le fonctionnement et qui n'est pas rétrocompatible
- Mise à jour mineure – Désigne la publication de nouvelles fonctionnalités avec rétrocompatibilité, ainsi que des améliorations apportées aux fonctionnalités existantes
- Correctif – Désigne la publication d'un ensemble de corrections de bogues, de mises à jour de sécurité et de petites améliorations, tout en garantissant la rétrocompatibilité
- Correctif – Désigne une mise à jour d'urgence destinée à résoudre des problèmes critiques signalés en production dans la version déployée.
Les indicateurs clés qui comptent
Les quatre indicateurs DORA expliqués :
Conformément aux normes du secteur, il existe quatre indicateurs clés qu'il convient de suivre et d'optimiser pour assurer la réussite des organisations.
- Délai de mise en production (la rapidité avec laquelle nous déployons les logiciels en production)
- Fréquence de déploiement(à quelle fréquence vous effectuez des mises à jour).
- Modifier le taux d'échec(fréquence à laquelle les déploiements échouent).
- Temps moyen de rétablissement (MTTR)(la rapidité avec laquelle vous résolvez les pannes).
Le délai d'exécution estl'un des quatre indicateurs clés du DevOps Research and Assessment (DORA). Il mesure le temps nécessaire pour qu'une modification du code passe de la validation à son déploiementen production, reflétant ainsi l'efficacité de votre processus de livraison logicielle. Cet indicateur indique la durée moyenne entre le moment où une modification du code est validée et celui où elle est déployée avec succès en production.
Le délai de livraison indique :
- rapidité de livraisonetefficacité des processus.
- Des délais de production plus courts vont de pair avecdes boucles de rétroaction plus rapidesetune plus grande agilité.
La fréquence de déploiement permet de suivre la fréquence à laquelle les modifications du code sont déployées avec succès en production. Elle reflète larapidité etla cohérencede votre processus de livraison logicielle
La fréquence de déploiement indique :
- Agilité des équipesetmaturité des processus.
- Les déploiements fréquents réduisent les risques en permettant d'apporterdes modifications plus modestes et progressives(par opposition à des mises à jour importantes et peu fréquentes).
- Cela se traduit pardes boucles de rétroaction plus rapidesetune plus grande satisfaction des clients.
Le temps moyen de rétablissement (MTTR)mesure letemps moyen nécessaire pour rétablir le service après une défaillance(par exemple, une panne, une baisse de performances ou un bug). Il reflètela résilience de votre équipeet l'efficacité de sa réponse aux incidents.
Le MTTR indique :
- Réduit au minimum les temps d'arrêtet l'impact sur les utilisateurs.
- Un MTTR élevé peut être le signed'un débogage lent, d'une surveillance insuffisante ou de processus de restauration inefficaces.
- Cela a une incidence surla confiance des clients, les coûts d'exploitation et le stress de l'équipe.
Le taux d'échec des modifications (CFR)mesure lepourcentage de déploiements qui entraînent des défaillances en production et nécessitent des mesures correctives (par exemple, des retours en arrière, des correctifs ou des mises à jour). Il reflète lastabilité et la fiabilitéde votre processus de mise en production.
Le CFR indique :
- Indiquela fréquence à laquelle les déploiements entraînent des défauts(bogues, pannes, problèmes de performances).
- Un taux de mortalité élevé peut être le signed'un dépistage insuffisant, d'une surveillance inadéquate ou de pratiques de mise en circulation risquées.
- Ceci est en corrélation avecl'épuisement professionnel de l'équipe, la confiance des clients et les coûts opérationnels.
| Système métrique | Définition | Formule |
| Délai de livraison | Durée moyenne nécessaire pour réaliser une fonctionnalité | Somme du délai de production et du nombre de fonctionnalités |
| Fréquence de déploiement | À quelle fréquence le code est-il déployé en production ? | Nombre total de déploiements / Nombre de mois |
| Taux d'échec des changements (CFR) | Pourcentage de déploiements entraînant une défaillance. | Nombre de modifications ayant échoué ÷ Nombre total de modifications × 100. |
| Temps moyen de réparation (MTTR) | Délai moyen de rétablissement du service après une panne. | Somme des durées de restauration ÷ Nombre de pannes (problème de fonctionnement/bug/problème lié aux données) |
Autres indicateurs à l'appui :
- Travaux en cours (WIP) : mesure le nombre de tâches inachevées (par exemple, modifications du code, fonctionnalités, bogues) actuellement en cours de traitement. Cet indicateur permet d'identifier les goulots d'étranglement et de déterminer s'il est nécessaire de diviser la fonctionnalité ou l'histoire utilisateur
- Durée du cycle : temps écoulé entrele début de la tâche(par exemple, la création d'un ticket) etson achèvement
- Nombre de Pull requests : indicateur qui recense lenombre de PR créées, fusionnées ou rejetées surune période donnée (par exemple, quotidienne, hebdomadaire ou mensuelle). Il aide les équipes à évaluerla productivité des développeurs, l'efficacité de la collaboration et les goulots d'étranglement dans le flux de travail.
- Incidentssignalés par les clients : nombre d'incidents en productionsignalés par les clients, reflétant la qualité des tests internes
- Bugs ouverts : cet indicateur permet de suivre le nombre de défauts non résolus (bugs) présents dans votre système à un moment donné. Il permet d'évaluer la qualité du logiciel, la dette technique et l'efficacité de l'équipedans la gestion des problèmes.
- Bugs ouverts depuis longtemps : les bugs ouverts depuis longtemps sontdes défauts qui restent non résolus pendant une période prolongée (généralement plus de 30 jours). Leur suivi permet d'identifierles inefficacités des processus, les lacunes dans la hiérarchisation des priorités et la dette technique
- Bugs reportés : il s'agit de défauts qui ont étéidentifiés mais dont la résolution a été intentionnellement reportéeà plus tard. Si le report peut constituer une stratégie légitime, un recours excessif à cette pratique peut être le signed'une accumulation de dette technique, de problèmes de hiérarchisation des priorités ou d'inefficacités dans les processus.
- État des builds CI : cet indicateur permet de surveiller lastabilité et la fiabilité de votre pipeline d'intégration continue (CI)en suivant le taux de réussite ou d'échec des builds et des tests automatisés. Un système CI performant est essentiel pourobtenir un retour rapide, garantir des versions de haute qualité et assurer la productivité des développeurs
- État du cycle de développement et de mise en production (CD) : cet indicateur permet de surveiller lastabilité, la rapidité et le taux de réussite de votre déploiement automatisé. Un système CD performant garantit des mises en productionfiables, fréquentes et à faible risque.
- Tests d'intégration: les tests d'intégration permettent de vérifier queles modules, services ou systèmes développés séparément fonctionnent correctement lorsqu'ils sont combinés. Il s'agit d'une étape cruciale dans le cadre du DevOps pour détecter les problèmesavant qu'ils reach .
- Suite de surveillance de la production: ensemble d'outils et de pratiques permettant de surveiller l'état du système, de détecter les anomalies et de résoudre les problèmes en temps réel pour les applications en production. Elle est essentielle pour les équipes SRE, DevOps et d'exploitation afin de garantir la disponibilité, les performances et la satisfaction des utilisateurs.
Pourquoi les indicateurs de performance sont essentiels au succès d'une organisation
Le suivi des indicateurs DevOps et opérationnels (tels queDORA, le délai de traitement, la fréquence de déploiement, le MTTR, le CFR, les alertes de surveillance, etc.) fournitdes informations exploitablesqui favorisentla réussite commerciale, l'excellence technique et l'avantage concurrentiel.
- Accélérer la mise sur le marché
- Indicateurs :délai de traitement, fréquence de déploiement, durée du cycle
- Conséquences :
- Des mises à jour plus rapides →Répondre plus rapidement aux demandes du marché.
- Des boucles de rétroaction plus courtes →Innover plus rapidement que la concurrence.
- Améliorer la qualité et la fiabilité des logiciels
- Indicateurs :taux d'échec des modifications (CFR), temps moyen de rétablissement (MTTR), bogues en cours
- Conséquences :
- Moins de défaillances de production →Une plus grande satisfaction des clients.
- Résolution plus rapide des incidents →Réduction des pertes de chiffre d'affaires
- Réduire les coûts et le gaspillage
- Indicateurs :état de la chaîne de construction, échecs des tests d'intégration, tests instables
- Conséquences :
- Détection précoce des bogues →Les corrections sont moins coûteuses en phase de développement qu'en production
- Des pipelines efficaces →Réduction des coûts liés au cloud et à la puissance de calcul
- Améliorer la productivité et le moral de l'équipe
- Indicateurs :durée du cycle de PR, limites du WIP, taux de réussite des déploiements
- Conséquences :
- Moins de goulots d'étranglement →Les développeurs passent plus de temps à coder et moins de temps à attendre.
- Contrôles automatisés →Réduire l'épuisement professionnel lié au travail manuel.
- Aligner le DevOps sur les objectifs de l'entreprise
- Indicateurs :livraisons d'unités commercialisables, taux d'incidents clients, engagements en matière de disponibilité
- Conséquences :
- Relie les efforts d'ingénierie auxrevenus, àla croissance de la base d'utilisateurs et à la fidélisation.
- Prise de décision fondée sur les données
- Indicateurs :tendances en matière de MTTR, de durée de vie des bogues et de fréquence de déploiement
- Conséquences :
- Donner la prioritéaux améliorations ayant un fort impact
- Justifiez les investissements dansl'automatisation, la formation ou l'outillageen fournissant ROI .
Résumé :
Enautomatisant le suivi et l'optimisationde ces indicateurs clés, les entreprises peuvent tirer parti d'avantages considérables, notamment :
- Décisions fondées sur les données– Exploitez des informations exploitables pour orienter votre stratégie et vos investissements.
- Excellence technique– Favoriser l'amélioration continue des pratiques de développement et d'exploitation.
- Compétitivité du secteur– Atteindre (ou dépasser) les meilleurs résultats du secteur.
- Réussite client– Proposer des solutions fiables et de haute qualité qui répondent aux attentes des utilisateurs.
- Gouvernance et leadership– Garantir la transparence et la responsabilité à tous les niveaux.
Cette approche structurée garantitdes processus plus efficaces, de meilleures performances et une croissance durable de l'entreprise.
Références
- Accelerate, par Forsgren, Humble et Kim
- Documentation Azure DevOps
- Rapports DORA (DevOps Research and Assessment)