Aperçu du processus et des procédures de développement

Ce document donnera un aperçu des processus et procédures de développement de Leading2Lean. Ce processus décrit les responsabilités, les politiques et les procédures à suivre par Leading2Lean lors de modifications apportées au service et à l’infrastructure de production. Tous les employés sont tenus de respecter cette politique.

L’équipe technologique de Leading2Lean est chargée de fournir une infrastructure informatique stable et fiable à nos clients. L’objectif du processus de développement est de minimiser les interruptions de service dans notre environnement de centre de données et de promouvoir la disponibilité et l’intégrité des systèmes. Le directeur technique (CTO) est responsable de la maintenance et de la mise à jour du processus et des procédures de développement selon les besoins. Ce processus est en outre régi par des contrôles organisationnels définis dans le cadre de notre programme de conformité AICPA SOC 2 Type 2. Ces contrôles sont audités chaque année par notre auditeur externe.

Le processus de développement commence par l’examen du ticket par un développeur, la coordination avec ses collègues concernant l’architecture et la conception, l’écriture du code, la réception des commentaires de l’équipe d’assurance qualité, pour enfin aboutir à la mise à disposition du logiciel pour les clients. 

Portée

Ce document définit le cycle de vie des demandes de fonctionnalités et des bugs. Il décrit également les processus et procédures utilisés pour garantir que des tests et une validation appropriés sont effectués pour chaque version. Ce document ne décrit pas le processus de gestion des changements défini dans notre Aperçu de la politique de contrôle des changements.

Définitions

Backlog : Une collection de bugs et de fonctionnalités dont le développement n’a pas commencé. Le Backlog est l’endroit où résident tous les tickets de faible priorité. 

Bug : Une fonctionnalité qui ne fonctionne pas comme prévu. Les bugs peuvent être de gravité faible à extrêmement élevée. La liste des bugs contient tous les bugs de faible priorité. Les tickets sont placés dans la liste des bugs lors de la réunion de triage. Les tickets sont attribués aux membres de l’équipe de développement depuis la liste des bugs.

Fonctionnalité ou amélioration : Un comportement qui n’a pas été développé pour le logiciel. Il peut s’agir d’une modification d’une fonctionnalité existante ou de la création d’une nouvelle fonctionnalité.

Projet ou Epic : Une collection de bugs et de fonctionnalités. Les projets sont gérés dans la feuille de route. 

Feuille de route : Une collection de projets. La feuille de route est le tableau de planification des projets de grande envergure. La feuille de route guide le développement de nouvelles fonctionnalités, grandes et petites. 

Triage : Collecte de nouveaux tickets. La liste Triage est l’endroit où tous les nouveaux tickets sont créés. L’équipe de triage placera ensuite les tickets dans la liste Bugs, la feuille de route ou le backlog.

Vue d’ensemble

Chaque ticket de développement comporte 3 phases principales : 1. Planification, 2. Développement et 3. Tests d’assurance qualité. Chaque phase sera décrite ci-dessous.

Planification

Nous utilisons une approche de triage multidisciplinaire pour le processus de planification. Nos équipes Support, Développement et Qualité se réunissent régulièrement lors d’une réunion de triage afin d’évaluer les nouveaux problèmes, les demandes de fonctionnalités et les améliorations. Selon leur gravité, ces problèmes peuvent déclencher un cycle d’intervention escaladée de type interruption/réparation afin de rétablir le service en cas d’éléments hautement prioritaires ou représenter une dégradation du service. Sinon, une priorité initiale leur est attribuée et ils sont transmis à notre équipe Produit pour une planification, une priorisation et une programmation supplémentaires.

Les fonctionnalités sont généralement planifiées avec la contribution d’un petit nombre de personnes.  Cela peut inclure des membres de l’équipe Produit, des experts du domaine, des clients, etc. Ce processus est dirigé par notre équipe de gestion des produits.

La majorité des demandes de fonctionnalités seront discutées lors de la réunion de planification de la feuille de route. Au cours de cette réunion, les projets et les demandes de fonctionnalités escaladées seront discutés. Les projets seront priorisés par rapport aux autres projets, et les demandes de fonctionnalités seront examinées puis déplacées vers le backlog. Les demandes de fonctionnalités peuvent être liées à un projet de la feuille de route.

Développement

Une fois le processus de planification terminé, ce travail est confié à l’équipe de développement. L’équipe de développement dispose de son propre ensemble d’environnements de développement qui sont une réplique de notre environnement de production. Il s’agit d’un élément essentiel de notre programme qualité. À chaque étape de notre cycle de vie du développement (Développement, Assurance qualité, Préproduction, & Production), nous maintenons une infrastructure distincte afin de garantir que tout travail réalisé sera correctement testé et vérifié avant d’être intégré à notre environnement de production.

Nous employons un ensemble complet d'outils de développement conformes aux normes de l'industrie, conçus pour le contrôle des versions, les tests automatisés, l'analyse statique du code et la propreté du code. Ces outils fournissent au développeur des retours précoces et fréquents afin de garantir la meilleure qualité de code possible. Ils contribuent également à maintenir une séparation adéquate des branches de développement afin d'éviter toute contamination croisée entre les développeurs travaillant sur différents projets, tâches et éléments de la base de code. Ces outils fournissent une méthode standardisée pour les revues de code par les pairs et les processus d'approbation afin de garantir que tout code prêt pour les tests d'assurance qualité a réussi tous les contrôles de test et de validation automatisés.

Nos développeurs communiquent directement avec l'équipe d'assistance, l'équipe produit ou d'autres développeurs lorsque des questions se posent sur la manière d'implémenter un ticket. Toutes les modifications de l'interface utilisateur nécessitent l'approbation de l'équipe produit. Étant donné que les modifications de l'interface utilisateur ont un impact sur les clients et peuvent nécessiter une formation, nous travaillons avec les clients, l'assistance et l'équipe produit afin de garantir que les précautions nécessaires sont prises lors de la conception de toute modification de l'interface utilisateur, pour minimiser son impact sur les clients. Toutes les modifications de l'interface utilisateur sont également examinées par notre équipe d'assistance pendant la phase de tests d'assurance qualité afin de valider le bon fonctionnement et de garantir que les clients reçoivent les notifications et la formation appropriées.

Les développeurs sont tenus d'exécuter avec succès notre suite de tests automatisés pour toute modification dans le cadre de leurs procédures opérationnelles habituelles. Une fois que le ticket a réussi ces tests automatisés, il est prêt à être examiné par une personne autre que le développeur. Cet événement permet aux membres clés de l'équipe de savoir qu'il est temps de fournir des commentaires et indique également que le ticket se rapproche de sa mise en production.

Tout le code est examiné par un autre développeur avant d'être transmis à l'équipe d'assurance qualité. Cela permet de garantir que plus d'une personne connaît et comprend ce qui est modifié et pourquoi. L'objectif d'une revue de code doit être de réfléchir à l'objectif global des modifications, de vérifier le code pour détecter les erreurs simples, d'analyser le code pour repérer les inefficacités, de demander des éclaircissements lorsque quelque chose ne semble pas correct et d'essayer de maintenir la cohérence avec les normes de codage et les meilleures pratiques. Il arrive que le développeur d'origine refactorise le code à la suite de commentaires reçus pendant la phase de test. Si cela entraîne une quantité importante de modifications du code, une revue supplémentaire est effectuée. Lorsque le consensus de la revue de code est enregistré et documenté, le code peut être transmis à l'équipe d'assurance qualité

Tests d'assurance qualité

Une fois que la suite de tests automatisés s'est terminée avec succès et sans erreurs, et que la revue de code est terminée avec succès, l'équipe d'assurance qualité peut commencer le processus de tests d'assurance qualité.

Les deux principales activités liées au processus de test sont l’exécution de scripts de test automatisés et les tests manuels. L2L dispose d’une suite de cas de test d’interface utilisateur et de tests unitaires qui sont exécutés depuis la ligne de commande. Un processus d’analyse statique est également exécuté sur le code afin de vérifier la présence d’erreurs de codage élémentaires. Tous les développeurs doivent exécuter à la fois la suite de tests et le processus d’analyse statique avant de soumettre leur code à la révision. L’équipe Qualité effectue sa propre analyse des résultats de la suite de tests automatisés après avoir déployé le code dans l’environnement de test de l’équipe Qualité. Cela garantit que nous disposons d’un environnement de test propre pour évaluer la capacité de la mise à jour du code à fonctionner comme prévu et conformément à nos normes de qualité.

L’équipe Qualité coordonnera les tests manuels du code afin de garantir une qualité supplémentaire. Les commentaires de l’équipe Qualité seront ajoutés au ticket de développement. Souvent, le code devra être remanié et mis à jour avant que l’équipe Qualité ne donne son approbation. L’équipe Qualité indiquera que le code est prêt à être fusionné en approuvant la demande de fusion. L’équipe Qualité fusionnera le code dans la base de code principale une fois que tout aura été approuvé. Cela garantit que les développeurs ne peuvent pas fusionner de code dans notre base de code principale et contourner le processus d’assurance qualité.

Pendant la phase de tests d’assurance qualité, l’équipe Qualité fera également appel à des membres de l’équipe d’assistance et au client pour effectuer des tests d’acceptation utilisateur. Ces tests sont essentiels pour garantir que les modifications du code sont utilisables, répondent aux besoins des clients et sont conformes aux réglementations et exigences du secteur.

Processus de contrôle des changements et déploiement en Production

Pour garantir que toute modification apportée à notre environnement de Production suit un processus standard, nous avons mis en place un processus de gestion des changements, tel que défini dans notre Présentation de la politique de contrôle des changements. Cela garantit que nous disposons des contrôles et contrepoids appropriés au sein de l’organisation afin d’assurer la qualité, la Sécurité et la disponibilité de l’environnement de Production. Pour plus d’informations sur ce processus, consultez le lien ci-dessus.

Il est important de noter que, dans le cadre du processus de contrôle des changements, L2L utilise un script de déploiement automatisé pour publier les logiciels du référentiel de code vers les serveurs des clients. À aucun moment les employés ne mettent manuellement à jour l’environnement de Production. Ce système automatisé crée une piste d’audit pour chaque nouvelle version ou chaque nouveau déploiement et vérifie que les approbations appropriées sont en place. Une fois cette étape terminée, les scripts de publication sont autorisés à mettre à jour les serveurs de Production. Ce script automatisé fournit également une notification interne à l’entreprise concernant les déploiements. Une fois le déploiement terminé, ce système automatisé effectue également des « tests de fumée » afin de valider que le déploiement a réussi et que l’environnement de Production fonctionne correctement.

Réunion rétrospective

Si le code mis en production fait réapparaître un ancien problème ou entraîne une alerte du système, une réunion rétrospective, également appelée post-mortem, aura lieu. L’objectif de la réunion sera de rassembler les faits liés à la mise en production du mauvais code, de discuter des moyens d’éviter que des événements similaires ne se reproduisent à l’avenir, d’attribuer des tâches liées à la prévention d’événements futurs et de former l’équipe au sujet de l’incident. Ces réunions devraient avoir lieu dans les 36 heures suivant l’événement et réunir autant de développeurs et de membres de l’équipe d’assurance qualité que possible à des fins d’analyse des causes profondes et de formation. 

Notification des clients

Les notifications aux clients peuvent avoir lieu à plusieurs moments au cours de ce processus. Les clients sont souvent consultés pendant les phases de planification, de développement et d’assurance qualité, ainsi qu’une fois le code mis en production. Le client sera informé selon les méthodes suivantes :

• Contact personnel / Réunions planifiées. Les clients impliqués dans des projets de développement spécifiques peuvent être invités à participer à des réunions de mise à jour régulières afin d’examiner les plans, les conceptions et l’état du projet.
• E-mail personnel aux clients. Tous les tickets d’assistance d’origine seront mis à jour pour informer le client que la modification a été mise en production sur les serveurs, et le ticket sera fermé. Si aucun ticket d’assistance n’a été créé, un représentant de l’assistance peut contacter directement le client. Si un seul client a été impacté par une modification, les autres formes de notification peuvent ne pas être utilisées.
• Journal des modifications. Toutes les modifications qui impactent les clients contiendront un journal des modifications. Cela inclut les corrections de bugs, les mises à jour mineures et les demandes de fonctionnalités. Lorsqu’une modification n’a concerné qu’un seul client et que l’impact était mineur, et si un client a été contacté directement, un journal des modifications peut ne pas être ajouté. Les clients peuvent accéder au journal des modifications depuis le menu Assistance de l’application.
• E-mail groupé. Un e-mail sera envoyé à tous les administrateurs pour toutes les modifications importantes de l’application. Les e-mails groupés sont principalement utilisés pour les annonces de produits et les améliorations importantes de l’interface utilisateur, mais peuvent être utilisés dans d’autres scénarios.
• Notifications dans l’application peuvent être utilisées pour les modifications ayant un impact.