SCRUM

SCRUM

 
Pour rappel Scrum est une méthode agile dédiée à la « gestion de projet ». Cette méthode de gestion, ou plutôt ce Framework de management de projet, utilisé à Rintio dans l’intégration des applications mises en place et à pour objectif d’améliorer la productivité de son équipe. Le framework s’appuie sur le découpage d’un projet en boîtes de temps, nommées « sprints ». Les sprints peuvent durer entre quelques heures et un mois (avec une préférence pour deux semaines). Chaque sprint commence par une estimation suivie d’une planification opérationnelle. Le sprint se termine par une démonstration de ce qui a été achevé. Avant de démarrer un nouveau sprint, l’équipe réalise une rétrospective. Cette technique analyse le déroulement du sprint achevé, afin d’améliorer ses pratiques. Le flot de travail de l’équipe de développement est facilité par son auto-organisation, il n’y aura donc pas de gestionnaire de projet.

La création de frameworks de développement logiciel hybrides couplant Scrum et d’autres frameworks est commune puisque Scrum ne couvre pas le cycle de développement de produit. Par exemple, on pourra utiliser des pratiques issues de l’extreme programming, de la phase de construction structurée de la méthode RAD, ou un ensemble de pratiques de qualité du logiciel émergeant du vécu de l’équipe projet.

Caractéristiques

Le cadre de travail Scrum est fondé sur la conviction que le développement logiciel est une activité par nature non-déterministe et que l’ensemble des activités de réalisation d’un projet complexe ne peut être anticipé et planifié7. C’est en cela que Scrum s’oppose aux démarches prédictives telles que le cycle en V. Pour répondre à cette imprédictibilité, la méthode Scrum propose un modèle de contrôle de processus fondé sur l’empirisme, via l’adaptation continue aux conditions réelles de l’activité et une réaction rapide aux changements. L’analyse des conditions réelles d’activité lors des retrospectives de fin de sprint et le plan d’amélioration continue qui en découle sont réalisés à intervalles de temps réguliers, donnant lieu à un cycle de développement incrémental (Sprint).

Le cadre de travail Scrum a été conçu lors de projets de développement de logiciels. Il peut aussi être utilisé par des équipes de maintenance. Dans le cas de très grands projets, les équipes se multiplient et on parle alors de scrum à grande échelle (ex. : le scrum de scrums ou LESS). Le cadre de travail Scrum peut théoriquement s’appliquer à n’importe quel contexte ou à un groupe de personnes qui travaillent ensemble pour atteindre un but commun comme planifier un mariage, gérer des projets de recherche scientifique, des écoles et même des églises comme le précise le site de l’un des co-créateurs Jeff Sutherland.

Un principe fort des méthodes agiles est la participation active du client. Cela permet de choisir plus finement les fonctionnalités réalisées à chaque incrément. Avant le démarrage du sprint 1, les objectifs sont définis lors d’un sprint 0. La mêlée (scrum meeting) a lieu quotidiennement et des réunions spécifiques permettent de lever les obstacles bloquants. Le sprint a une durée variable (idéalement deux semaines). Après chaque sprint, une démonstration suivie d’une rétrospective ont lieu. Le propriétaire du produit peut à tout moment compléter ou modifier la liste des fonctionnalités à produire pour les prochains sprints. Sans modifier le but du sprint en cours, celui-ci peut être affiné et faire l’objet d’une renégociation entre le propriétaire du produit et l’équipe de développement à la suite de nouvelles connaissances. Si le but du sprint devient obsolète, le propriétaire du produit a la capacité d’annuler un sprint en cours.

Chaque sprint constitue donc un incrément, facilitant le pilotage du projet. La notion d’itération couvre l’adaptabilité au quotidien. Cette adaptabilité est limitée par le but immuable d’un sprint.

Les trois piliers de scrum

Scrum est un processus empirique : il se base sur l’expérience du terrain. Il s’appuie sur trois piliers.

Il suit également les principes de la culture agile.

Transparence

Scrum met l’accent sur le fait d’avoir un langage commun entre l’équipe et le management. Ce langage commun doit permettre à tout observateur d’obtenir rapidement une bonne compréhension du projet.

Inspection

À intervalle régulier, Scrum propose de faire le point sur les différents artéfacts produits, afin de détecter toute variation indésirable.

Ces inspections ne doivent pas être faites trop fréquemment, ou par un inspecteur mal formé : cela nuirait à l’avancement du projet.

Adaptation

Si une dérive est constatée pendant l’inspection, le processus doit alors être adapté. Scrum fournit des évènements, durant lesquels cette adaptation est possible. Il s’agit de la réunion de planification de sprint, de la mêlée quotidienne, de la revue de sprint ainsi que de la rétrospective de sprint.

 

Le « package » Scrum

Processus de la méthode Scrum

                                                    Processus Scrum

Scrum est considéré comme un cadre ou « framework » de gestion de projet. Ce cadre est constitué d’une définition des rôles, de réunions et d’artefacts.

Scrum définit 3 rôles :​

  • – Le « Product Owner » qui porte la vision du produit à réaliser (représentant généralement le client).
  • – Le « Scrum Master » garant de l’application de la méthodologie Scrum.
  • – L’équipe de développement qui réalise le produit.

La vie d’un projet Scrum est rythmée par un ensemble de réunions clairement définies et strictement limitées dans le temps (timeboxing):

  • Planification du Sprint (Sprint = itération) : au cours de cette réunion, l’équipe de développement sélectionne les éléments prioritaires du « Product Backlog » (liste ordonnancée des exigences fonctionnelles et non fonctionnelles du projet) qu’elle pense pouvoir réaliser au cours du sprint (en accord avec le « Product Owner »).
  • Revue de Sprint : au cours de cette réunion qui a lieu à la fin du sprint, l’équipe de développement présente les fonctionnalités terminées au cours du sprint et recueille les feedbacks du Product Owner et des utilisateurs finaux. C’est également le moment d’anticiper le périmètre des prochains sprints et d’ajuster au besoin la planification de release (nombre de sprints restants).
  • Rétrospective de Sprint : la rétrospective qui a généralement lieu après la revue de sprint est l’occasion de s’améliorer (productivité, qualité, efficacité, conditions de travail, etc) à la lueur du « vécu » sur le sprint écoulé (principe d’amélioration continue).
  • Mêlée quotidienne : il s’agit d’une réunion de synchronisation de l’équipe de développement qui se fait debout (elle est aussi appelée « stand up meeting ») en 15 minutes maximum au cours de laquelle chacun répond principalement à 3 questions : « Qu’est ce que j’ai terminé depuis la dernière mêlée ? Qu’est ce que j’aurai terminé d’ici la prochaine mêlée ? Quels obstacles me retardent ? »

Fonctionnement des méthodes agiles

Les méthodes agiles partent du principe que spécifier et planifier dans les détails l’intégralité d’un produit avant de le développer (approche prédictive) est contre productif. Cela revient à planifier dans les détails un trajet « Paris – Narbonne » en voiture par les petites routes. Spécifiant chaque villes et villages traversés, l’heure de passage associée, chaque rue empruntée dans les agglomérations, litres d’essence consommés, kilomètres parcourus, etc. Les imprévus ne manqueront pas d’arriver : embouteillages, déviations, travaux, sens de circulation inversés, voire la panne, etc.

L’idée consiste à se fixer un premier objectif à courts termes (une grande ville par exemple) et se lancer sur la route sans tarder. Une fois ce premier objectif atteint, on marque une courte pause et on adapte son itinéraire en fonction de la situation du moment. Et ainsi de suite jusqu’à atteindre la destination finale. On parle donc d’une approche empirique. Dans le cadre d’un projet de développement logiciel, le client élabore sa vision du produit à réaliser et liste les fonctionnalités ou exigences de ce dernier. Il soumet cette liste à l’équipe de développement, communique directement avec elle (plutôt que par papier) qui estime le coût de chaque élément de la liste. On peut ainsi se faire une idée approximative du budget global.

L’équipe sélectionne ensuite une portion des exigences à réaliser dans une portion de temps courte appelée itération. Chaque itération inclut des travaux de conception, de spécification fonctionnelle et technique quand c’est nécessaire, de développement et de test. A la fin de chacune de ces itérations, le produit partiel mais utilisable est montré au client. Ce dernier peut alors se rendre compte par lui même très tôt du travail réalisé, de l’alignement sur le besoin. L’utilisateur final quant à lui peut se projeter dans l’usage du produit et émettre des feedbacks précieux pour les futures itérations. La visibilité ainsi offerte est clef. Cette transparence peut également apporter davantage de confiance et de collaboration dans la relation client/fournisseur. Les risques quant à eux sont levés très tôt.

Si le client a priorisé avec soin son besoin, il peut saisir l’opportunité d’accélérer le « time to market » si il estime que le produit en l’état (partiel) peut aller en production. Économisant ainsi son budget et récoltant un premier retour sur investissement. Il a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n’ont pas encore été développées (prévues pour les itérations futures). Afin de retarder une fonctionnalité dont le besoin n’est pas mûr, ajouter une nouvelle fonctionnalité cruciale en échange du retrait d’une autre (respectant ainsi budget et délais), etc.

Cette souplesse ainsi offerte est donc un véritable atout pour le client.

La contractualisation agile

La contractualisation d’un projet agile n’est pas la partie la plus facile étant donné que le périmètre est par définition variable. La régie ferait bien l’affaire mais difficile de rassurer le client avec un tel contrat. En France et ailleurs, le contrat au forfait domine; surtout sur les gros projets. Malheureusement pour le fournisseur – dans le cadre d’un forfait classique – tous les risques sont pour lui (aussi bien sur un projet agile que sur un projet traditionnel). On peut limiter ces risques en prenant quelques précautions, mais on limite également la souplesse offerte par une approche Agile.

Cela ne veut pas dire qu’il n’existe pas de solutions. La forfaitisation de chaque itération avec la possibilité pour le client d’arrêter le contrat à la fin de chaque itération est assez intéressante. Ainsi que le principe de troc d’exigence : réalisation d’une exigence imprévue en échange du retrait d’une autre moins importante, de priorité faible et de même coût.

DevOps

DevOps

 

DevOps est un ensemble de pratiques qui automatisent les processus entre les équipes de développement et IT afin de leur permettre de développer, tester et livrer des logiciels plus rapidement et avec plus de fiabilité. Le concept de DevOps repose sur la mise en place d’une culture de la collaboration entre les équipes qui étaient, historiquement, cloisonnées. Parmi les avantages assurés, le gain de confiance, l’accélération des livraisons, la capacité à résoudre les tickets plus rapidement ou encore la gestion plus efficace des tâches non planifiées.

 

À la base, DevOps est une culture, un courant de pensée, une philosophie.

C’est une poignée de main ferme entre les équipes de développement et opérationnelles. L’accent est mis sur le changement de mentalité, la collaboration accrue et l’intégration plus poussée. DevOps associe la méthodologie Agile, l’automatisation, la livraison continue et bien plus encore pour aider les équipes de développement et opérationnelles à gagner en efficacité, à innover plus rapidement et à offrir plus de valeur ajoutée aux business et aux clients. Rintio utilise cette technologie pour le développement et l’intégration de ses applications, ce qui permet à ses développeurs de gagner en temps et en gestion efficace des tâches a exécutées.

L’histoire de DevOps

Le mouvement DevOps a commencé à s’unifier entre 2007 et 2008, lorsque les équipes opérationnelles et de développement ont clairement exprimé ce qu’elles qualifiaient de dysfonctionnement majeur dans le secteur.

Elles ont pesté contre le modèle de développement traditionnel, qui appelait un cloisonnement organisationnel et fonctionnel entre les programmeurs, les équipes de déploiement et le support.

Les développeurs et les experts de l’IT/des opérations avaient des objectifs distincts (et souvent opposés), leur propre leadership, des indicateurs clés de performance différents au moyen desquels ils étaient évalués et, bien souvent, ils travaillaient à des étages voire dans des bâtiments séparés. Résultat : les équipes étaient cloisonnées, elles ne se préoccupaient que de leur propre fief, faisaient des heures supplémentaires, bâclaient les livraisons, et les clients étaient mécontents.

Il devait y avoir une méthode plus efficace. Les deux communautés se sont donc réunies et ont commencé à échanger. Des experts tels que Patrick Dubois, Gene Kim ou encore John Willis étaient aux commandes.

Ce qui a commencé par des forums en ligne et des réunions locales s’est désormais popularisé dans l’univers du développement. C’est d’ailleurs probablement ce qui vous a amené ici ! Votre équipe et vous-même éprouvez des difficultés en raison de silos et d’un manque de communication au sein de votre entreprise.

Vous utilisez les méthodologies Agile pour la planification et le développement, mais vous cherchez encore à livrer du code sans catastrophe. Vous avez entendu parler de DevOps et de son effet apparemment magique sur les équipes, et vous pensez que vous aimeriez profiter, vous aussi, de cette magie.

La mauvaise nouvelle ? DevOps n’est pas la panacée, et les transformations ne s’opèrent pas en une nuit. La bonne nouvelle ? Inutile d’attendre que les cadres supérieurs mettent en place une initiative à grande échelle. Si elle comprend la valeur ajoutée de DevOps et qu’elle apporte de petits changements incrémentiels, votre équipe peut débuter son parcours DevOps dès maintenant. Voyons maintenant chacun de ces avantages plus en détail

Avantages…

« DevOps nous a aidés à Rintio d’ accélérer les livraisons et nous a donné un avantage en termes de délai de commercialisation. Nous sommes maintenant capables de livrer chaque jour, contre une fois tous les 6 mois, et de pusher les correctifs vers nos clients en l’espace de quelques heures. »

Collaboration et confiance

La culture est le principal facteur de réussite d’une initiative DevOps. Instaurer une culture de la responsabilité partagée, de la transparence et du feedback accéléré est incontournable pour chaque équipe DevOps ultra performante.

Les équipes cloisonnées n’adhèrent souvent pas à la « pensée systémique » de DevOps. Penser de façon systémique signifie être sensible à l’impact de vos actions sur votre équipe, mais aussi sur toutes les autres équipes impliquées dans le processus de livraison. Le manque de visibilité et les objectifs partagés impliquent un manque de planification des dépendances, un mauvais alignement des priorités, une mentalité où les autres sont pointés du doigt et où l’on affirme que ce n’est pas notre problème. La vélocité et la qualité sont alors affectées. DevOps impose un changement d’état d’esprit, qui vise à observer le processus de développement de façon holistique et à éliminer les cloisons entre les équipes de développement et opérationnelles.

Livrez plus rapidement et travaillez plus intelligemment

Tout est question de vitesse. Les équipes qui adoptent DevOps livrent plus souvent, avec plus de qualité et de stabilité.

L’absence de tests automatisés et de cycles de revue bloque la mise en production, et les temps de réponse aux incidents médiocres sont l’ennemi de la vélocité et de la confiance. Les outils et processus disparates augmentent les OpEx, imposent un changement de contexte et cassent la dynamique. Grâce à l’automatisation ainsi qu’aux outils et processus standardisés, les équipes peuvent accroître la productivité et livrer plus souvent, avec moins d’à-coups.

Réduisez la durée de résolution

L’équipe dont la boucle de feedback est la plus rapide prospère. Grâce à la transparence totale et à la communication fluide, les équipes DevOps peuvent réduire les temps d’arrêt et résoudre les tickets plus rapidement que jamais.

Si les tickets critiques ne sont pas résolus rapidement, la satisfaction des clients chute. Les tickets importants passent au travers des mailles du filet en l’absence de communication ouverte. En conséquence, la tension et la frustration augmentent au sein des équipes. Les équipes de développement et opérationnelles « swarment » sur les tickets, résolvent les incidents et débloquent plus rapidement le pipeline de livraison grâce à la communication ouverte.

Gérez plus efficacement les tâches non planifiées

Chaque équipe est confrontée à des tâches non planifiées, une réalité qui se répercute bien souvent sur la productivité. Grâce aux processus établis et à la priorisation claire des tâches, les équipes de développement et opérationnelles peuvent mieux gérer les tâches non planifiées, tout en se concentrant sur celles qui le sont.

Le transfert et la priorisation des tâches non planifiées entre les différents systèmes et équipes s’avèrent inefficaces et détournent l’attention des employés du travail à faire. Cependant, les équipes peuvent mieux anticiper et partager les tâches non planifiées grâce à la visibilité accrue et à la rétrospection proactive.

Qui adopte DevOps

Des dizaines de milliers de développeurs utilisent Chef pour tester, automatiser et gérer les infrastructures. À l’avant-garde du mouvement DevOps, la société  livre des produits  et proposer de nouvelles méthodes de développement et de livraison de logiciels et d’applications.

Les équipes qui adoptent DevOps déploient 30 fois plus souvent, déplorent 60 fois moins de défaillances et constatent des délais de récupération 160 fois plus rapides: Nos développeurs  à Rintio l’ont essayés puis adoptés  et nous en sommes satisfait.

Api et micro-services

Api & Micro-services

 

 

 

API : l’ouverture des SI dans un monde de micro services

Parce qu’elles interconnectent les systèmes dans un monde de plus en plus ouvert et décloisonné, les APIs, ces interfaces de programmation, forment aujourd’hui l’un des principaux moteurs des vastes projets de modernisation des SI des entreprises. Les APIs deviennent le mot à la mode quand on aborde la problématique d’agrégation et d’intégration de données et de services. Les entreprises dans le monde s’adosseront aux APIs pour motoriser leur SI, et par extension leur modèle économique.

Rintio utilise cette nouvelle méthode et technologie pour l’intégration et le développement de ses applications et services. Il a également validé de puissants et nombreux algorithmes et processus lui permettant de répondre aux exigences de son métier.La plupart de ces fonctions est déjà disponible comme service et est particulièrement stable. Il suffit d’exposer ces fonctions au travers d’API pour qu’elles puissent interagir avec de nouveaux micro-services venant apporter la souplesse et l’évolutivité nécessaire à une transformation numérique réussie. A la racine du développement de ces nouvelles applications conçues autour de micro-services se trouvent les API. On peut regarder les API comme le contrat initial définissant l’information à fournir et la base syntaxique sur laquelle l’information est fournie. Dans le respect de ce contrat, un ou plusieurs nouveaux micro-services peuvent être créés, modifiés, supprimés sans impacter d’aucune manière les autres projets.

Au-delà de cette flexibilité qui permet, à peu de frais, la mise en place d’une démarche de type essai-erreur, le succès de ces micro-services repose sur les épaules de toutes petites équipes agiles. Le principe du micro-service injecte de la flexibilité à un Système d’Information encore trop souvent monolithique. Une méthode à laquelle devrait songer toute entreprise qui souhaite se réorganiser autour de sa transformation numérique. Rintio l’a adoptée et en est aujourd’hui satisfait…

Quelle place pour les APIs dans une architecture de microservices

Les microservices représentent une refonte complète du design applicatif ainsi que du déploiement d’applications. Une architecture de microservices peut impliquer de nombreux services, comme des VM, des conteneurs, des APIs, des services de load balancing, de monitoring ainsi que des outils d’automatisation, mais aussi d’autres éléments conçus pour renforcer la cohérence de l’application. Toutefois, en dépit de ce principe, chaque élément fonctionnel peut exister indépendamment des autres.Les fournisseurs de services Cloud, comme AWS par exemple,  se sont mis à développer une liste de services qui fonctionnent avec des projets de microservices, comme les conteneurs, la gestion d’événement ou encore la gestion d’APIs. Bien que les microservices montent aujourd’hui en puissance, cette approche n’est pourtant pas adaptée à toutes les applications. Les développeurs doivent ainsi bien comprendre le principe des microservices, démarrer petit et employer l’architecture microservices lorsque cela fait sens.Les APIs sont devenues un moyen clé pour que les services Cloud s’échangent des informations et fonctionnent de concert pour au final créer une fonctionnalité ou un groupe de fonctions. Avec les microservices, une application est conçue et implémentée comme un groupe de composants pouvant être dimensionnés, plutôt que comme une unique entité monolithique.

Une API peut par exemple permettre à des workloads dans plusieurs conteneurs de partager des données, de prendre en compte les entrées des utilisateurs et de gérer les sorties (pour être stockées ou pour être dirigées vers des services de reporting). Les APIs peuvent également permettre aux applets côté client de communiquer avec les applications côté serveurs, même lorsque ces composants applicatifs sont hébergés dans un Cloud public.

API : Comment automatiser la génération de code

Les APIs sont certes devenues un composante clé des architectures logicielles, les développeurs peinent encore à les façonner. En cause : l’écart entre la publication de la documentation et celle des spécifications. Brad Irby nous fait part d’un outil qui permet d’automatiser la génération de code.Les APIs sont devenues très à la mode chez les développeurs. Mais en dépit de cette notoriété, ceux-ci doivent encore livrer bataille lorsqu’il s’agit de générer le code de l’API à cause de décalage entre la documentation et les demandes des chefs de produits. Dans cet article, je vous explique comment Swagger peut aider à maintenir une cohérence entre la documentation et le code, tout le long du processus de création d’une application.Nous sommes d’accord sur le fait que les APIs sont un outil formidable, mais leur création reste encore une tâche qui n’est pas aisée. Il est nécessaire de prendre en compte nombre de détails. Mais il est également facile de perdre de vue certains de ces détails,  lorsque l’on traduit l’idée de départ d’un chef de produit dans une série de documents détaillant les specs, puis enfin en ligne de code. Grâce à Swagger, synchroniser les docs avec le code est devenu plus simple.

Swagger est un outil qui permet à quiconque disposant d’un minimum de compétences techniques de définir une API, de générer la documentation et même de générer le code. L’API est conçue au sien d’un éditeur en ligne via YALM, un langage XML très lisible. Celui-ci définit les endpoints, puis le format des paramètres d’entrée et de sortie des données, le niveau de sécurité que vous souhaitez implémenter. Et c’est prêt à être utilisé.

L’éditeur Swagger vous propose un exemple reposant sur l’API d’Instagram (Figure 1). Dans l’éditeur, sélectionnez « File », puis « Open Example ». D’autres exemples sont également disponibles.

Instagram API code

Figure 1 : L’API d’Instagram comme exemple

Parmi les données de l’illustration ci-dessus, 8 paths ont été définis. On clique sur le petit triangle pour dérouler les nœuds. Lorsque vous en ouvrez un (Figure 2), on constate que cela nécessite GET HTTP. Vous pouvez consulter la description et constater qu’il requiert 3 paramètres. Si cela marche, il retourne un array d’objets.

defined paths
Figure 2 : Un path complet

De même, vous pouvez ouvrir la définition Media, et consulter les détails des propriétés de cet objet, comme les objets imbriqués (je ne montre qu’une partie de la définition dans la Figure 3).

Media definition
Figure 3 : Une vue partielle de la définition Media

Définir une API avec l’éditeur Swagger est pratique, mais pas plus facile que d’utiliser d’autres outils. Toutefois, dans le panneau de droite de l’éditeur, la documentation HTML est générée automatiquement. (Figure 4).  Elle apparait complète, agréable à lire et vous propose de tester les appels. En cliquant sur le bouton « Try this operation », vous pouvez saisir des paramètres, effectuer l’appel et observer le résultat.

auto generated documentation
Figure 4 : La documentation est générée automatiquement

Mais ce n’est finalement pas cela qui rend cet outil le plus indispensable. En vous appuyant sur les options « Generate Server » et « Generate Client » (Figure 5), vous pouvez générer le code pour publier et consommer cette API en plusieurs langages. A lui seul, cet outil de génération de code peut vous faire économiser des heures de programmations fastidieuses, sans parler du temps nécessaire à effectuer des modifications  tout le long du cycle de vie de votre API.  Vous pouvez également exporter le code pour créer un fichier en local et ainsi mieux contrôler les sources. Ce fichier peut aussi être publié pour que d’autres développeurs puissent intégrer rapidement vos données.

generate server
Figure 5 : Utiliser les options « Generate Server » et « Generate Client »

Rédiger une API est certes très utile mais aussi très chronophage. La concevoir avec Swagger et publier le fichier YAML peut faciliter vos processus internes et votre collaboration avec d’autres.

Construire correctement une interface de programmation

Ne faites pas capoter tout votre projet d’API. Bien connaître les applications permet notamment de fixer la conception et d’encourager la fidélité des développeurs.

Dans un contexte de logiciels interactifs et fractionnés en de nombreux composants, rien n’est plus important que les interfaces de programmation d’applications(API) utilisées pour relier ces composants entre eux, ainsi qu’aux appareils mobiles et aux navigateurs . Bien conçue, une API permet de garantir l’intégration fonctionnelle et la fidélité des développeurs ; mal conçue, elle peut faire échouer tout un projet.

Trois facteurs permettent de rester du bon côté de la force en matière de création d’API :

– Connaitre les applications et leurs contraintes d’utilisation

–  S’intéresser à l’architecture de composants et à l’infrastructure de liaison

– Et enfin s’assurer d’une bonne gestion des changements

Les API présentent les fonctionnalités et les services aux développeurs. Le mode d’utilisation d’une API et la gamme des services représentés constituent les principaux moteurs de son développement. L’une des erreurs les plus importantes commises par les développeurs et les architectes lors de la création d’API consiste à ignorer un élément déterminant. Il est vital que la conception d’une API s’intègre parfaitement dans l’écosystème des développeurs, des langages et des autres API.

Problèmes courants de conception d’API

Le débat REST contre SOAP constitue un exemple de cadre contraignant pour les API. Lorsque des applications dépendent déjà des unes ou des autres, toute nouvelle API doit évidemment se fondre dans le moule. Ce qui est moins évident, c’est que la plupart des API font partie d’une tendance allant vers le fractionnement en composants et la divulgation des fonctionnalités. Ce mouvement peut, au fil du temps, orienter un ensemble d’API vers REST ou SOAP ; une migration qu’il faut donc absolument anticiper.

Les problèmes de constitution des API peuvent détruire une application plus vite et plus radicalement que tout autre type d’erreur d’architecture.

Les architectes risquent d’être facilement échaudés s’ils se conforment à l’architecture objet et à l’infrastructure de liaison. Il est important de choisir le bon modèle d’API car les développeurs ont du mal à utiliser une interface non conforme à l’architecture des applications qu’ils mettent au point. Remarquez que les API RESTful représentent généralement des ressources, tandis que les API SOAP représentent des processus ou procédures distant(e)s.

Un protocole peut servir à lier les API à leurs utilisateurs et aux applications Web ; il s’agit en principe du tandem HTTP (Hypertext Transfer Protocol)/HTTPS. L’utilisation du protocole HTTP avec un format de données HML (Hypertext Markup Language) ou XML (eXtensible Markup Language), ou encore JSON (JavaScript Object Notation) et JavaScript sur les appareils clients, facilite la création d’interfaces utilisateur graphiques à partir d’une API. En revanche, il peut ne pas convenir lorsque l’accès au navigateur n’est pas l’objectif de l’application. Certaines applications et API peuvent utiliser un port TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol) particulier au lieu du port Web 80. Ce dispositif contribue certes à séparer le trafic des API de l’activité Web, mais les conséquences au niveau du pare-feu ou de la sécurité risquent d’exiger une configuration système spéciale entraînant une exposition des API ou leur utilisation à distance

Règles générales en matière de conception d’API

On peut considérer que la plupart des API forment une syntaxe de verbes et de noms. Par exemple, on a une phrase avec un verbe représentant une action demandée (get, put, delete) et des noms désignant les arguments qui s’appliquent à l’action. Une bonne pratique consiste à toujours générer une variable d’état/de résultat qui indique les conditions d’erreur ou la réussite de l’exécution. Les conditions d’erreur doivent être suffisamment précises pour décrire les problèmes sans ambigüité.

La sémantique de l’API, c’est-à-dire la syntaxe des fonctions fournies, est importante car la capacité de l’API à transmettre clairement ses services et paramètres évite aux développeurs de commettre des erreurs. Si l’API représente un service avec état, il est essentiel que la sémantique de la fonction soit axée sur la session (find-record, update-record, delete-record) lorsque la nature « avec état » du service est clairement établie.

Il en résulte que si, comme dans cet exemple, les fonctions update et delete portent sur l’élément de données précédemment localisé, elles ne fournissent pas leurs propres clés d’élément de données ; en effet, celles-ci seraient redondantes et risqueraient de dérouter les développeurs. En revanche, un service sans état doit systématiquement indiquer toutes les données car la session ne fournit aucun contexte.

Questions et problèmes récurrents

Les problèmes de syntaxe créés par les mises à jour ou les modifications apportées à l’API sont souvent ignorés. Chaque API présente deux faces, que le processus de changement peut désynchroniser. Pour leur API, certains architectes prévoient une variable de version afin de s’assurer que les mêmes formats soient attendus sur les deux faces. Au minimum, les côtés serveur et client d’une API doivent procéder à une validation élémentaire pour se protéger des modifications susceptibles d’induire un conflit de syntaxe, et ce afin d’éviter qu’elles contaminent les informations ou bloquent les applications.

Une autre question récurrente concerne le format des données. Le langage XML est le plus répandu pour définir les paramètres et échanger des informations ; il s’applique aux interfaces REST et SOAP. Mais le traitement XML est lourd et s’avère surtout utile pour exprimer les données sans structure. Pour l’architecture REST, JSON rencontre un succès grandissant, car il est plus facile à mettre en oeuvre et assure un typage spécifique des variables, largement utilisé et attendu dans la création d’API. Dans les cas où les API échangent des éléments de données strictement définis, il est sans doute préférable d’utiliser JSON pour les échanges RESTful.Les tests d’API sont souvent intégrés aux processus de gestion du cycle de vie des applications. C’est justifié pour une partie d’entre eux, mais des tests unitaires spécifiques doivent également être conçus afin de valider les API et de garantir leur exécution correcte même lorsque les données contiennent des erreurs. Moins les liaisons de données et le typage d’une API sont contraignants, plus il est risqué de transmettre des informations qui entraîneront une erreur ou un blocage ultérieur. C’est pourquoi il est important d’adopter des contraintes strictes sur les variables et de tester chaque API avec un large éventail de données.

Les problèmes de constitution des API peuvent détruire une application plus vite et plus radicalement que tout autre type d’erreur d’architecture. Le temps supplémentaire passé à concevoir des API de façon à prévoir les conditions d’erreur présentes et futures sera du temps bien employé.