Le 19 novembre 2024, les meilleures solutions logicielles de Suisse ont été récompensées au Kongresshaus de Zurich. Particulièrement rayonnante : la start-up Apriko, qui a doublement convaincu en remportant l’or dans la catégorie Business Solutions et l’argent dans la catégorie Cloud Native Solutions.
Vous êtes-vous déjà demandé en quoi consistait le payrolling ou la paie ? Connaissez-vous Try & Hire ? La réponse n’est pas simple, car le terme « payrolling » est utilisé pour 2 services différents.
Chez Apriko, nous visons un degré élevé d’automatisation des processus clients, une mise sur le marché rapide et une amélioration continue de nos logiciels. Pour y parvenir dans un domaine exigeant doté d’une architecture logicielle complexe, une planification précise et une mise en œuvre cohérente sont indispensables dès le début.
Dans le développement logiciel actuel, les équipes sont confrontées au défi de s’assurer que leurs systèmes fonctionnent de manière transparente avec des processus et des logiques différents et souvent complexes. Ces systèmes doivent également être compatibles avec un grand nombre de solutions logicielles qui sont régulièrement mises à jour. Cependant, ces mises à jour risquent de perturber les processus qui fonctionnaient normalement auparavant en raison de modifications du code source.
De telles régressions, connues sous le nom de régressions logicielles, peuvent se produire lorsque de nouvelles fonctionnalités sont ajoutées, que des mises à jour logicielles sont installées ou que des erreurs antérieures sont corrigées. Comme les logiciels et les interfaces évoluent en permanence, chaque changement risque de causer des problèmes inattendus. Plusieurs facteurs aggravent considérablement le problème des régressions logicielles : La perte de connaissances, l’évolution rapide des technologies et la croissance de la base de code rendent difficile pour les développeurs d’anticiper complètement tous les impacts d’un changement. Cela entraîne une certaine retenue lors des optimisations et du remplacement de composants logiciels obsolètes.
Il en résulte souvent un allongement de la durée des tests, ce qui peut entraîner que même des modifications mineures nécessitent plusieurs mois de test. Dans des cas extrêmes, il se peut que des modifications ou des nouvelles fonctionnalités ne soient plus développées, car les efforts de test et de validation sont disproportionnés. Cela limite considérablement la capacité d’innovation du développement logiciel.
Chez Apriko, nous misons sur l’approche Behavior Driven Development (BDD). L’objectif du développement logiciel comportemental est de simplifier la collaboration entre l’équipe de développement et l’entreprise à l’aide d’un langage commun. Cela permet d’obtenir une compréhension uniforme et d’automatiser le testing.
Le comportement de l’application contrôle méthodiquement le processus de conception. Le langage ubiquitaire traduit ce comportement en éléments qui permettent une analyse du code et des tests d’acceptation ultérieurs avant la finalisation du logiciel. L’automatisation du testing améliore l’assurance qualité et accélère la mise sur le marché.
L’approche BDD repose sur une syntaxe spécifique au domaine, souvent illustrée par le format Gherkin. Cette syntaxe suit le modèle « Given-When-Then » :
L’avantage de BDD réside dans le fait que le logiciel n’est pas décrit par des spécifications volumineuses et complexes, mais par des exemples clairs et compréhensibles. Ceux-ci sont formulés de sorte à être compréhensibles pour toutes les parties concernées et à éviter, en grande partie, tout malentendu. Les exemples sont structurés de manière à pouvoir être directement convertis en tests d’acceptation automatisés.
Dans l’environnement.NET, BDD est souvent pris en charge par SpecFlow. SpecFlow permet de convertir en code exécutable des critères logiciels rédigés en langage naturel et documentés dans des fichiers de fonctionnalités selon la syntaxe Gherkin. Cela simplifie l’exécution des tests automatisés et offre un aperçu transparent de l’état des tests, qu’ils aient réussi, échoués ou encore effectués. Les développeurs disposent ainsi d’une documentation précise et à jour de l’état du logiciel et des critères d’acceptation, ce qui élimine efficacement les incertitudes liées à un comportement erroné ou à une documentation obsolète.
Nous adoptons une approche API-first qui place l’API au centre. Avant de mettre en œuvre une User Story ou d’écrire une ligne de code, le comportement complet – y compris les cas positifs, les cas d’erreur, les validations, les opérations et les cas marginaux connus – est conçu et spécifié dans des fichiers de fonctionnalités au format Gherkin.
Afin de rendre le langage commun aussi efficace que possible, nous avons défini des étapes spécifiques et mis en œuvre le comportement de ces étapes de manière uniforme. Cela nous permet d’automatiser les tests en fonction des spécifications sans écrire une ligne de code de test.
Ces éléments standardisés permettent de définir et de vérifier tous les comportements API imaginables.
À partir des étapes d’opération (When) dans la spécification, nous générons des requêtes HTTP et utilisons la réponse HTTP pour la validation dans les étapes de vérification (Then). Les tableaux contenus dans la spécification sont transférés dans Payload pour les requêtes HTTP, tandis que les tableaux issus des étapes de vérification sont sérialisés en conséquence pour comparer le contenu de la réponse. Nous convertissons les tableaux dans les formats requis tels que JSON, XML, etc.
Nous utilisons également des étapes standardisées pour, par exemple, comparer nos contenus d’exportation CSV, PDF ou Word ou simuler des API externes.
Afin que les scénarios et les tests qui en découlent dans un service ne dépendent pas d’autres services, nous avons développé une étape qui nous permet de placer un Event-Message dans le bus d’événements.
Nous sommes ainsi en mesure de considérer le message comme une interface avec d’autres services lors des tests et de la conception, sans avoir à connaître les détails d’autres domaines ou services. Cela réduit la complexité, définit une interface claire et garantit davantage le découplage.
Pour chaque scénario, un environnement isolé est automatiquement fourni avec la base de données contenant la version actuelle du code du logiciel. Les requêtes HTTP sont générées à partir de la syntaxe écrite en Gherkin comme décrit ci-dessus et vérifiées par rapport à notre API dans le cadre d’un test boîte noire.
Les tests sont entièrement automatisés à chaque modification de code selon les tests unitaires classiques et nous recevons un retour d’information dans les 15 minutes quant à d’éventuelles régressions. Plusieurs milliers de scénarios sont ainsi exécutés en quelques minutes et le comportement de l’ensemble des fonctions est testé à cent pour cent. S’il n’y a pas de régression et qu’une fonctionnalité a satisfait à nos autres exigences de qualité, telles que la révision du code ou les tests exploratoires, elle peut être déployée en production en appuyant tout simplement sur un bouton. Dans notre architecture globale, axée sur des microservices et une architecture pilotée par des modèles avec des générateurs de code développés en interne, la spécification représente quatre-vingts pour cent de la base de code totale. Il s’agit d’un bilan remarquable qui souligne l’efficacité de nos approches de conception et de leur mise en œuvre.
Le Behavior Driven Development est un véritable gamechanger lorsqu’il est appliqué correctement et mis en œuvre de manière cohérente. L’effort associé ne doit cependant pas être sous-estimé et doit être soigneusement planifié, le soutien de la direction étant également essentiel. La création systématique de la spécification en tant qu’artefact d’exigence et de conception sert de moteur pour le développement en aval. La création sur ce niveau de détail est un travail abstrait et exigeant qui nécessite des développeurs expérimentés possédant les compétences appropriées. Il est important de suivre systématiquement la voie empruntée ; les lacunes dans les spécifications réduisent considérablement la pertinence des tests de régression. Cependant, l’investissement dans cette approche est rapidement rentabilisé sous la forme de produits durables et peut offrir un réel avantage concurrentiel.
Le développement de logiciels modernes nécessite des méthodes agiles afin de pouvoir réagir rapidement aux changements du marché tout en garantissant la qualité. DevOps offre ici la solution idéale grâce au lien étroit entre développement et exploitation.
Chez Apriko, nous visons un degré élevé d’automatisation des processus clients, une mise sur le marché rapide et une amélioration continue de nos logiciels.
Un principe central de conception de l’architecture logicielle d’Apriko est de générer automatiquement autant de code boilerplate que possible ou d’en déduire une logique.
Le niveau de complexité est élevé dans le développement logiciel moderne, notamment dans les architectures de microservices. Mais que faire pour éviter les erreurs dans de simples tâches répétitives ?
Apriko a été développé en tant qu’application de microservice pour répondre aux exigences croissantes des applications d’entreprise modernes.
Copy text, max 150 characters, omnitat volor recestiosam faccusa pidundisquam re sitati faccusa nullaboris aut. Ecest, omnitat pidundisquam re sitati.
