Tous les éléments pour réussir un projet d'application

Développement d'applications : les 4 éléments pour réussir

28 Janvier 2021

Les mêmes questions se posent toujours au lancement d’un nouveau projet d’applications web ou mobile !

  • Comment aller plus vite dans le développement d’applications ?
  • Comment déployer plus de projets sans accroître les ressources ?
  • Comment automatiser plutôt que répéter les mêmes tâches ?
  • Comment garantir des standards élevés : fiabilité, robustesse, qualité, évolutivité ?

Voyons quels sont les éléments de réussite à mettre en place pour délivrer rapidement les bonnes applications au bon moment. Dans un souci de clarté, nous nous attacherons aux quatre éléments suivants :

  1. Production de l’architecture et du code
  2. Gestion agile
  3. Démarche DevOps
  4. Déploiement des environnements

1 – Production de l’architecture et du code

Avec la transformation numérique, les entreprises ont un besoin toujours plus important d’applications métier pour faciliter et améliorer leur fonctionnement. Mais avant d’entamer la réalisation des objectifs fonctionnels, il faut produire à moindre coût l’architecture logicielle et le code purement technique nécessaires à toute nouvelle application.

Tout à la main

Le développement d’applications reste encore très artisanal. On développe tout à la main. C’est beaucoup trop long et beaucoup trop cher !

Les demandes pour de nouvelles applications sont pourtant en très forte hausse alors que les ressources disponibles sont en baisse.

Selon la Commission Européenne, 800000 postes n’ont pas été pourvus en Europe en 2020.

Le développement traditionnel d’application ne peut plus suivre le rythme ! Même avec des frameworks modernes comme .NET 5.

Génération low-code

Selon la définition de Forrester, une plateforme low-code permet une livraison rapide des applications métier complexes avec un minimum de développement manuel et une configuration et un déploiement rapides.

Le principal avantage d’une génération low-code est bien sûr la vitesse et l’augmentation de la productivité qui en découle. On ne perd pas de temps à tout coder manuellement ! Avec ce type d’outils, les développeurs peuvent produire plus d’applications et cela, sans augmenter la taille de l’équipe informatique.

Aujourd’hui, la demande croissante pour de nouvelles applications oblige votre organisation à repenser son approche du développement d’applications d’entreprise. Les plateformes low-code contribuent à résoudre ce défi en permettant aux développeurs de créer rapidement et facilement des applications pertinentes qui auront un effet important sur vos résultats.

Et le no-code ?

Depuis quelques années, on entend beaucoup parler de no-code. Ce serait l’étape ultime puisqu’il s’agirait de créer une application entière en se passant complètement du code. Et donc, des développeurs…

C’est déjà le cas… pour des choses relativement simples : une application mobile de consultation des données, des formulaires, des sites web particulièrement en Single Page Application.

Mais soyons clairs : pas d’ERP professionnel complet en no-code. Les applications d’entreprise, domaine d’intervention de Artza Technologies, nécessitent souvent des traitements complexes sur les données avec des règles de gestion fonctionnelle évoluées. Pour ce type d’application métier, le low-code est intéressant puisque permettant d’obtenir plus rapidement et avec moins d’effort une première version opérationnelle de l’application.

Le no-code semble prématuré. A moins que l’Intelligence Artificielle un jour…

2 – Gestion agile

La bonne gestion d’un programme d’application est l’art de rassembler des profils, de définir des responsabilités et des rôles, au sein d’une organisation commune. La méthode choisie doit vous fournir un cadre fort avec des règles, des instructions, des outils pour gérer efficacement l’ensemble de l’équipe projet.

Chaque année, VersionOne publie son rapport sur l’état de l’agilité dans le monde. On peut facilement en déduire les 5 principaux bénéfices.

Faire agile ou être agile

La méthode à retenir pour un projet particulier doit être travaillée, raffinée et adaptée au contexte unique de votre projet.

Choisir de gérer votre projet en s’inspirant de Scrum est probablement une bonne décision…

Mais il ne suffit pas de le décider et il ne s’agit pas de l’imposer. La préparation agile de votre projet sera fort différente si la plupart des personnes ont déjà travaillé sur un projet géré en Scrum ou si, au contraire, quasiment personne n’est capable d’identifier le rôle de Product Owner.

Bien sûr, il est important de « faire agile » en organisant le projet autour des rituels, des cérémonies et des outils. Néanmoins, l’objectif est d’être agile, ce qui implique une prise de conscience individuelle et collective et permet d’atteindre en permanence les piliers de l’agilité que sont l’information et la transparence, l’inspection régulière et l’adaptation continue.

Etre agile est un état d’esprit

Rédiger des User Stories efficaces

Le développement agile cherche à produire de la Valeur Métier décrite au moyen de Récits Utilisateur (US : User Story) :

  • Livraison rapide et continue d’un logiciel toujours opérationnel
  • Accueil favorable au changement tout au long du cycle de développement
  • Livraison constante sur de courtes périodes
  • Communication sur la documentation formelle
  • Attention continue aux détails techniques et de conception via les tests
  • Démonstrations régulières de l’avancement
  • Réflexion régulière sur la progression et les processus pour augmenter l’efficacité

Récit utilisateur complet

Un écueil classique à éviter ici est le raccourci : l’agilité, c’est Scrum ; Scrum, c’est les Sprints ; les Sprints, c’est la phase de réalisation.

Scrum est une petite partie de l’agile ; les Sprints sont une petite partie de Scrum ; etc

L’écueil que nous mentionnons ci-dessus conduit souvent à une focalisation excessive de la phase de réalisation. Or, enfonçons une porte ouverte, la phase de réalisation se passera d’autant mieux que la phase de mûrissement aura été aboutie, fonctionnellement et techniquement.

Réussir la phase de mûrissement implique de rédiger des User Stories efficaces en insistant sur l’importance des critères d’acceptation qui sont un composant absolument essentiel dans la rédaction d’une User Story ou Récit Utilisateur.

Rédaction des critères d’acceptation avec le langage Gherkin

Une itération est une période durant laquelle des fonctionnalités et des récits sont implémentés techniquement. La durée des itérations est généralement comprise entre deux et quatre semaines : la durée doit être suffisante pour que l’équipe puisse produire un travail significatif et, en même temps, assez courte pour laisser place au changement.

Pilotage dans Azure DevOps

Avoir défini une méthode sur son projet partagée et acceptée par toute l’équipe, c’est bien !

Avoir choisi une méthode de type agile en mêlant « faire agile » et « être agile », c’est encore mieux !

Néanmoins, la meilleure méthode du monde ne saurait être appliquée de façon optimale sans un outillage précis et rigoureux. Dans l’environnement Microsoft, il existe depuis une quinzaine d’années une gamme d’outils : TFS (Team Foundation Server), VSTS (Visual Studio Team System), Azure DevOps.

Azure DevOps se décline en version Services ou Server. Comment choisir entre ces deux versions (cloud ou sur site) ? Voyez 5 éléments pour vous guider !

  • Planification
    • Les modèles fournis réduisent le besoin de configuration
    • L’interface web offre un accès aux équipes distribuées
  • Développement et tests
    • Intégration des principaux plateformes et langages de développement
    • Gestionnaire de code-source, qualité du code
    • Builds et déploiement
    • Tests techniques automatisés, tests fonctionnels et manuels
  • Livraison continue
    • Evénements d’archivage
    • Déclenchement des builds
    • Déploiement
  • Analyse
    • Suivi du travail grâce aux différents types d’éléments de travail
    • Tableaux de bord personnalisables facilement

Les services de Azure Devops : Boards, Repos, Pipelines, Artifacts, Test Plans

Les grands services ci-dessus définissent la navigation dans Azure DevOps

Un projet créé dans Azure DevOps s’appuie sur un modèle de gestion de processus qui, par défaut, sont au nombre de quatre :

Les modèles de processus de Azure Devops

Parmi les ressources proposées par le projet Azure DevOps, on trouvera pour la gestion agile des éléments de travail (workitems) de différents types, des backlogs sur plusieurs niveaux (Epic/Epopée, Feature/Fonctionnalité, User Story / Récit Utilisateur), des tableaux Kanban et tout ce qui permet de configurer l’organisation agile du projet : les itérations, les zones et les équipes.

Chaque modèle de gestion de processus apporte ses types d’élément de travail.

Les types d’éléments de travail Azure Devops

Lorsqu’on a des modifications de masse à faire sur des éléments de travail, quel que soit le type, Excel prend en charge l’intégration des projets Azure DevOps. On peut ainsi très facilement gérer des listes d’éléments de travail.

Azure DevOps fournit des tableaux de bord pour chaque projet sur la base de catalogue de widgets prêts à l’emploi. C’est une fonctionnalité très utilisée qui permet la gestion de projet « en un clin d’œil » !

Les tableaux de bord Azure Devops

Le Wiki est une fonctionnalité apparue avec Team Foundation Server 2018 qui remplace avantageusement le site Sharepoint associé au projet des anciennes versions de TFS. Il n’est pas créé par défaut à la création du projet.

Création d’un wiki avec Azure Devops

Grâce à une bibliothèque très riche d’extensions, il est facile d’ajouter dans Azure DevOps des fonctionnalités utiles. Par exemple, une extension pour gérer les rétrospectives agiles

3 – Démarche DevOps

Le principe de méthode DevOps est de rapprocher les équipes de développement (Dev) des équipes d’infrastructure et de production (Ops) en intégrant, dès la conception du projet, toute la chaîne : la conception de l’architecture logicielle et les développements, les tests, les contraintes d’infrastructure et les méthodes de production.

Une démarche DevOps, appelée aussi CI/CD (Continuous Integration / Continuous Deployment), inclut les étapes suivantes :

  • Archivage des modifications du code-source
  • Builds automatisées pour assurer l’Intégration Continue
  • Exécution automatique des tests techniques et fonctionnels
  • Déploiement des packages vers un environnement dédié pour le Déploiement Continu
  • Mise à disposition d’une nouvelle version du logiciel

Azure DevOps, comme son nom l’indique d’ailleurs, propose toutes les fonctionnalités nécessaires pour la mise en place d’un démarche DevOps complète. Cela se passe dans la rubrique Pipelines (Builds & Déploiements) et Test Plans (gestion des tests fonctionnels).

Builds

On doit s’assurer régulièrement que l’ensemble du code-source archivé sur le référentiel central, par exemple les Repos Git, compile correctement et sans erreurs. La meilleure façon est de paramétrer des pipelines de Builds qui se déclencheront automatiquement, à un moment précisé par une date et une heure ou selon un événement. Tous les projets devraient posséder un type de build spécifique qui se déclenche lors d’un archivage dans le Repos de code : c’est la Build d’intégration continue ! En abrégé CI pour « Continuous Intégration ».

Suivi de l’exécution d’une build dans Azure Devops

Bien sûr, on peut définir tout un tas de builds à vocation différente :

  • Une Build sur une branche de développement précise
  • Une Build par environnement (Dev, Recette, Pré-prod, Prod, …)
  • Une Build exécutée la nuit qui se chargera de l’exécution des tests unitaires
  • Une Build d’intégration complète avec exécution de tous les tests fonctionnels automatisés
  • ….

De manière générale, les tests constituent un élément de réussite absolument indispensable ! Tout simplement pour s’assurer qu’un livrable correspond au besoin selon plusieurs niveaux : fonctionnel, performance, sécurité, …

La pyramide des tests agiles

Tests unitaires

Les tests unitaires font partie des tests techniques et sont considérés comme une bonne pratique de l’agile eXtreme Programming. Ils sont écrits par les développeurs eux-mêmes et cherchent à couvrir une partie importante du code en vérifiant que chaque « unité » du code fonctionne correctement. La notion d’unité diffère selon le langage de programmation utilisé :

  • Langage orienté objet : une unité est généralement une classe.
  • SQL : une unité est généralement une procédure stockée.
  • JavaScript : une unité est généralement un fichier.
  • Langage structuré : une unité est généralement un module.

Les tests unitaires amènent à écrire du code plus propre et plus maintenable en encourageant à adopter les bonnes pratiques de conception (SOLID) et à écrire un code moins couplé.

La métrique de qualité pour les tests unitaires est la couverture de code qui indique un pourcentage de lignes de code appelées pendant l’exécution des tests unitaires :

  • 50% de couverture de code signifie que la moitié du code a été appelée.
  • 100% de couverture de code ne signifie pas zéro bogue ! Mais simplement que toutes les lignes de code ont été appelées au moins une fois…

Couverture de code dans Visual Studio

En écrivant les tests après le code, nous aurons tendance à écrire des « happy path tests »

Le Test Driven Development (TDD) est une technique qui guide le développement en écrivant les tests (Martin Fowler). Il s’agit donc là d’écrire les tests unitaires avant le code selon les trois lois du TDD (Rober C. Martin) :

  1. Ne pas écrire de code tant qu’on n’a pas écrit un test qui échoue
  2. Ecrire le test suffisant pour échouer
  3. Ne pas écrire plus de code que nécessaire pour la réussite du test
Les étapes du Test Driven Development

Tests automatisés

Les tests d’acceptation ou tests fonctionnels prouvent que le logiciel fonctionne conformément aux attentes de l’utilisateur. Ces tests traitent le logiciel comme une boite noire et vérifient les réponses reçues par l’utilisateur en fonction de ses actions. Comme souvent avec les tests, quel que soit leur type, il s’agit de vérifier que la réponse obtenue est bien la réponse attendue.

Les tests fonctionnels sont automatisés avec des outils comme Ranorex ou Selenium. Une fois entièrement automatisés, les tests fonctionnels peuvent être exécutés très facilement et très fréquemment dans des pipelines de Builds !

Azure DevOps, quel que soit le modèle de processus de gestion de projet choisi, propose trois types d’éléments de travail pour gérer les scenarios ou scenarii de tests :

  1. Les plans de test (Test Plans) regroupent l’ensemble des tests d’une itération donnée. Par exemple, un Sprint ou une Release.
  2. Les suites de tests (Test Suite) abritent tous les tests fonctionnels d’une fonctionnalité précise.
  3. Les cas de test (Test Case) comprennent le test fonctionnel en lui-même, c’est-à-dire l’ensemble des étapes correspondant aux actions de l’utilisateur avec la description du résultat attendu.

Organiser les plans de test avec Azure DevOps
Décrire les cas de test avec Azure Devops

Le Behavior Driven Development (BDD) est l’équivalent pour les tests fonctionnels du Test Driven Development (TDD) pour les tests unitaires. Le BDD étend le TDD et met en valeur l’aspect métier sous forme de scénarios compréhensibles par tous les acteurs d’un projet. Ces scénarios sont donc écrits avant le code et sont transformés en tests exécutables.

Les étapes du Behavior Driven Development

Le langage Gherkin est fortement recommandé pour l’écriture des scénarios ! Il s‘appuie sur la syntaxe GIVEN WHEN THEN ou, en français :

ETANT DONNÉ que je suis abonné et que je suis sur la page de recherche d’un ouvrage

LORSQUE je saisis l’auteur, le titre ou la référence

ALORS je peux consulter la liste des ouvrages correspondants triés par auteur

Pour aller plus loin sur les techniques de tests à adopter en environnement agile, voici un article complet sur les avantages et caractéristiques du TDD et du BDD

Déploiements

Que se passe-t-il à chaque déploiement ?

  1. Approbation de pré-déploiement
  2. Mise en file d’attente de la tâche de déploiement
  3. Sélection de l’agent de déploiement
  4. Téléchargement de l’artéfact de Build
  5. Exécution des tâches de déploiement
  6. Génération des journaux de déploiement
  7. Approbation de post-déploiement

Déploiement sur les environnements avec Azure DevOps

On peut lister les bonnes pratiques suivantes :

  • Les Pipelines CI/CD sont l’unique façon de déployer sur les différents environnements
  • Minimiser le nombre de branches, archiver le code tous les jours et déployer souvent
  • Avoir des environnements de tests semblables aux environnements de production
  • Adopter un processus clair de gestion des Releases
  • Automatiser ! Automatiser !! Automatiser !!!

4 – Déploiement des environnements

Arrivé au stade du choix des environnements pour les déploiements, l’architecture logicielle et le code sont produits au moins une première fois, la gestion agile du projet est en place et gérée par Azure DevOps qui assure également la démarche CI/CD. Idéalement donc, toutes les étapes du projet sont automatisées, notamment les Builds, les tests techniques et fonctionnels et les déploiements.

Les environnements à prévoir pour réussir son projet d’application sont toujours classés en trois grandes catégories :

  • Développement qui assure la bonne construction du logiciel suite aux archivages quotidiens successifs. Cet environnement est mis à jour très fréquemment.
  • Recette qui permet aux profils fonctionnels voire aux utilisateurs finaux de tester très rapidement après développement les fonctionnalités tout juste implémentées. La possibilité d’avoir un retour très rapide tant que le sujet est « chaud » est clairement une garantie de succès.
  • Production qui héberge une version stable et validée du logiciel pour utilisation en conditions réelles par l’ensemble des utilisateurs. Le déploiement vers l’environnement de production peut être entièrement automatisé mais son déclenchement ne s’effectue généralement qu’après une approbation manuelle.

On peut toujours trouver plein d’autres appellations : intégration, QA, Validation, Homologation, Re7MOE, Re7MOA, Qualif, Pré-prod, … Mais, normalement, on doit pouvoir se référer aux trois grandes catégories citées ci-dessus.

Environnements de développement et de recette

Première chose à garder à l’esprit : les environnements de Développement et de Recette doivent être le plus proche possible de l’environnement de Production.

Prenons par exemple la réalisation d’une application web avec .NET 5 et une base de données SQL Server. Les environnements pourront prendre l’une des trois formes suivantes :

  • Serveurs internes : un serveur privé iis et un serveur privé SQL hébergés en interne dans les locaux de la société
  • Serveurs Cloud PaaS : on retrouve notre serveur iis et notre serveur SQL, même cette fois sous forme de Machines Virtuelles (VM) hébergées dans un cloud public ou privé
  • Cloud SaaS : une application web (app service) et une base de données SQL en tant que ressources Azure

L’environnement de développement d’une telle application en mode Cloud SaaS correspond à l’ensemble de ressources Azure suivant :

Gérer les environnements de développement et de recette sur Azure

Evidemment, des ressources Azure sont potentiellement accessibles à tout le monde. On veillera donc à sécuriser les environnements Azure.

Conclusion

Pour réussir vos projets d’applications, il vous faut :

  1. Développement des applications pour
    • Aller plus vite dans le développement d’applications
    • Déployer plus de projets sans accroître les ressources
    • Automatiser la production de code
    • Garantir des standards élevés : fiabilité, robustesse, qualité, évolutivité
  2. Gestion agile
    • Impliquer pleinement les utilisateurs finaux de la future application
    • Délivrer rapidement les fonctionnalités réellement importantes
    • Mieux prioriser le travail et les tâches du projet
    • Motiver les équipes de développement par une organisation autonome
  3. Démarche DevOps
    • Disposer en permanence d’un logiciel en état de fonctionnement
    • Déployer plus rapidement et plus facilement vos applications
    • Avoir des équipes plus productives et plus efficaces
    • Mettre en place une identification efficace des risques
  4. Déploiement des applications
    • Rendre vos applications métier accessibles de n’importe où et sur tout support
    • Déployer rapidement vos applications sur les différents environnements
    • Mise à l’échelle (scalabilité) de l’infrastructure applicative
    • Disposer d’environnements flexibles tout au long de la vie du projet

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *