Voxxed Days Microservices est un événement centré exclusivement sur les Microservices. Durant cette seconde édition, deux jours de conférences et un jour d’atelier (en option) auront lieu à Paris du 21 au 23 octobre 2019.
Les lecteurs d'InfoQ peuvent profiter d'une promo de 20% avec le code VXDMS19_COM_INFOQFR lors de l'inscription.
InfoQ s'est entretenu avec Phil Hardwick au sujet de sa session intitulée "Pact tests : how we split up the monolithic deploy".
Bonjour Graeme, dis-nous qui tu es et qu'est-ce qui t'a conduit vers les microservices ?
Je suis Phil, je suis ingénieur logiciel chez Mettle : une entreprise fournissant des comptes courants aux petites entreprises. Je travaille en génie logiciel depuis 7 ans dans divers projets, principalement dans le secteur public, mais certains dans le secteur privé, comme je le suis actuellement. Dans tous les projets ultérieurs, le passage aux microservices a été plus prononcé. La raison pour laquelle je continue à rechercher des possibilités de créer de meilleurs systèmes de microservices est que cela présente d'énormes défis avec des retours sans égal - aucune autre conception de système actuelle ne peut en donner l'équivalent, que ce soit en termes de scalabilité ou de fiabilité. Les défis de la complexité croissante et de la communication distribuée m'incitent, et de nombreuses autres, à rechercher de meilleures solutions et implémentations.
De quoi parles-tu à Voxxed Days Microservices ?
Je vais vous expliquer comment, chez Mettle, nous avons utilisé des contrats axés sur le consommateur pour nous permettre de livrer en continu dans les processus de production. Nous voulions déployer peu et souvent en production, mais pour cela, nous devions nous assurer que nos services étaient compatibles avec les versions des autres services dans tous les environnements. Nous verrons également comment l'implémenter dans vos services et votre CI - avec encore des astuces indiquant ce qu'il faut faire et ce qu'il faut éviter grâce à notre propre expérience de passage d'un déploiement monolithique à un déploiement micro indépendant.
Lors de la construction d'une API, le travail du fournisseur consiste généralement à tester ses API. Les tests Consumer-Driven Contract sont inversés. Peux-tu expliquer les interactions entre le consommateur d'API et le fournisseur d'API dans les tests CDD ?
La responsabilité de tester les fonctionnalités de l'API incombe toujours au fournisseur. La différence est que le consommateur définit le format des interactions (généralement les requêtes et les réponses). Le fournisseur vérifie ensuite, en plus de ses tests fonctionnels, qu'il est conforme au contrat (fournit les réponses dans le format requis). Cela favorise davantage d'interactions personnelles entre les fournisseurs et les consommateurs, qui décident du contrat et veillent à ce qu'il soit respecté. Ce faisant, nous avons divisé les tests en tests de fonctionnalité et en interactions d'interaction : une distinction clé dans le monde des microservices.
Bon, à bientôt alors
Au plaisir et à très bientot
Blog : https://blog.wick.technology
LinkedIn : http://linkedin.com/in/philiphardwick
GitHub : https://github.com/philhardwick