Le but d’un microservice étant d’être isolé, facilement testable et déployable, un critère important de cette mise en œuvre est l’utilisation d’un outil de build et de déploiement continu (continuous intégration / continuous déploiement).
Des solutions existent sur le marché comme TeamCity ou Jenkins. Ici nous parlerons bien sur de Microsoft Visual Studio Team Services 🙂
VSTS permet :
- D’avoir une forge logicielle avec un outils de gestion de version.
- De configurer des processus de build avec exécution de tests automatisés
- De configurer des processus de releases : déploiement sur des serveurs ou dans le Cloud.
Au-delà de l’aspect CI/CD VSTS permet également de gérer un projet en méthode agile avec la gestion des itérations de développement (sprints), les work items, backlog etc …
Une maturité DevOps est obligatoire pour la mise en œuvre de notre architecture. En effet, nos services seront nombreux et doivent pouvoir être déployé rapidement suite à une évolution. Sans une plateforme DevOps d’industrialisation logicielle pour nous aider, la tâche s’annonce plus que compliqué.
Intégration
La partie intégration est assurée par :
- Un outil de gestion de version : Git qui n’est plus à présenter ou TFVC, l’outils de gestion de version Microsoft, en fin de vie. La firme ne conseille plus son utilisation. A noter que VSTS peut également récupérer les sources d’un dépôt disant comme GitHub.
- Un outil de Builds, intégré à VSTS.
Les builds sont configurables, s’exécutent sur une branche du repository git et permettent de réaliser un certains nombre d’actions :
- Télécharger les dépendances Nuget du projet.
- Compiler la solution.
- Exécuter les tests automatisés.
- Exécuter des commandes Windows.
- Pousser l’artifact généré .
- Envoyer un rapport de build par mail.
- Lancer un tests Sonar.
- …..
De la façon la plus concise possible, sur un projet de type .Net core la build se déroulera en 4 commandes :
- dotnet restore
- dotnet build
- dotnet tests
- dotnet publish
Tests
Pour nos services, différent type de tests sont à mettre en œuvre pour garantir la stabilité du code source et éviter les régressions :
Tests unitaires
Chaque test valide le bon fonctionnement d’une méthode bien précise de notre service, l’utilisation d’un framework de mock (moq, rhinoMock) est indispensable pour garantir le caractère « unitaire » de nos tests. Un framework de mock permet de simuler le fonctionnement d’une méthode.
Par exemple, nous testons la méthode B. Dans l’implémentation de B il y a un appel a la méthode A qui retourne un booléen. Alors pour notre test de B on précisera en amont que notre méthode A renverra systématiquement true si elle est appelée. Pendant notre test si A() est appelé, on est assuré d’avoir le résultat true, et on peut tester notre méthode B indépendamment de A.
Microsoft propose son propre framework de mocking : Microsoft.Fakes.
A noter que la mise en œuvre d’une stratégie Test Driven Development (TDD) peut aider à garder une couverture de tests satisfaisante.
Tests d’intégration
Chaque test valide le bon fonctionnement d’une méthode de notre service, de l’appel jusque la base de données. Le test balaie donc la totalité de notre méthode. Par exemple avec l’appel GET http://www.urltest.com/clients/2, on pourra valider qu’en sortie on obtient un client provenant de la base de données dont l’identifiant est 2.
Tests de qualité
Il est possible d’intégrer un outils comme Sonar pour la qualimétrie logicielle et l’analyse du code :
- Respect des normes de développement
- Complexité cyclomatique
- Présence des commentaires
- Duplication de code
- Évaluation de la couverture de code
Tests statiques
On peut utiliser le module de code review de VSTS pour la relecture de code entre développeurs.
Les tests statiques sont effectués par les développeurs avant de pousser leurs modifications sur la forge. Les tests unitaires, d’intégration et de qualité quand à eux pourront être exécuté de manière automatisée par notre outils DevOps pendant une build. En cas d’erreur sur un des tests, l’archivage sera rejeté pour être corriger par le développeur.
Déploiements
La partie Déploiements de notre solution est géré par les « Releases » de VSTS. Les releases permettent à partir d’une build de déployer nos dll dans un environnement cible, serveurs interne ou environnement cloud.
L’hébergement de notre architecture microservices peut se faire dans un environnement Cloud afin de répondre facilement aux besoins de disponibilités et de scalabilité des applications. Ici nous nous intéresserons évidemment à Azure et aux différentes solutions offertes par cette plateforme pour répondre à notre besoin.
Les releases permettent en plus du déploiement d’effectuer des opérations comme :
- Jouer des scripts SQL
- Déplacer des fichiers (xml, json)
- Exécuter des commandes PowerShell, FTP
- …
A noter que des outils externes à Microsoft s’interface très bien avec VSTS, au niveau des builds comme des releases pour exécuter diverses taches. Je pense notamment à Octopus, Sonar, Docker, WebPack … Un système de plugin est même mis en œuvre pour pouvoir ajouter des fonctionnalités à VSTS.
Microsoft VSTS est donc un outils très complet pour la gestion du cycle de vie de nos applications. Il conviendra parfaitement dans le cadre d’un projet microservices déployé dans Azure.