Bonjour à tous. Aujourd'hui, nous partageons avec vous la dernière partie de l'article , une traduction préparée spécialement pour les étudiants du cours .
Test de déploiement
Le style de test abordé est une approche puissante qui nous permet de réaliser des tests en boîte blanche pour vérifier l'intérieur de notre code d'infrastructure. Cependant, cela limite quelque peu ce que nous pouvons vérifier. Les tests sont exécutés sur la base d'un plan de déploiement en mémoire, créé par Pulumi avant le déploiement proprement dit et donc, le déploiement lui-même n'est pas testable. Pour de tels cas, Pulumi dispose d'un cadre de tests d'intégration. Et ces deux approches fonctionnent parfaitement ensemble !
Le cadre de test d'intégration de Pulumi est écrit en Go, et c'est grâce à lui que nous testons la majeure partie de notre code interne. Si l'approche de test unitaire mentionnée précédemment ressemblait davantage à un test en boîte blanche, le test d'intégration est un test en boîte noire. (Il y a aussi des options pour un test interne approfondi.) Ce cadre a été créé pour prendre un programme Pulumi complet et exécuter diverses opérations de cycle de vie, telles que le déploiement d'une nouvelle pile à partir de zéro, sa mise à jour avec des variations, et sa suppression, potentiellement plusieurs fois. Nous les exécutons régulièrement (par exemple, la nuit) et en tant que tests de stress.
(Nous , pour que des capacités similaires de tests d'intégration soient disponibles dans le SDK natif des langages. Vous pouvez utiliser le cadre de test d'intégration Go indépendamment du langage dans lequel votre programme Pulumi est écrit).
En exécutant le programme via ce cadre, vous pouvez vérifier les éléments suivants :
- Le code de votre projet est syntaxiquement correct et fonctionne sans erreurs.
- Les paramètres de configuration de la pile et des secrets fonctionnent et sont correctement interprétés.
- Votre projet peut être déployé avec succès chez le fournisseur de cloud de votre choix.
- Votre projet peut être mis à jour avec succès de l'état initial à N autres états.
- Votre projet peut être détruit avec succès et supprimé de votre fournisseur de cloud.
Comme nous allons bientôt le voir, ce cadre peut également être utilisé pour effectuer une validation à l'exécution.
Test d'intégration simple
Pour voir cela en action, nous allons examiner le dépôt pulumi/examples, car notre équipe et la communauté Pulumi l'utilisent pour tester leurs propres demandes de tirage, commits et constructions nocturnes.
Voici un test simplifié de notre :
example_test.go :
package test
import (
"os"
"path"
"testing"
"github.com/pulumi/pulumi/pkg/testing/integration"
)
func TestExamples(t *testing.T) {
awsRegion := os.Getenv("AWS_REGION")
if awsRegion == "" {
awsRegion = "us-west-1"
}
cwd, _ := os.Getwd()
integration.ProgramTest(t, &integration.ProgramTestOptions{
Quick: true,
SkipRefresh: true,
Dir: path.Join(cwd, "..", "..", "aws-js-s3-folder"),
Config: map[string]string{
"aws:region": awsRegion,
},
})
} Ce test passe par le cycle de vie de base de création, modification et destruction d'une pile pour le dossier aws-js-s3-folder. Cela prendra environ une minute pour signaler que le test a réussi :
$ go test .
PASS
ok ... 43.993s Il existe de nombreux paramètres pour ajuster le comportement de ces tests. La liste complète des options se trouve ProgramTestOptions. Par exemple, vous pouvez configurer le point de terminaison Jaeger pour le traçage (Tracing), indiquer que vous vous attendez à un échec du test lors d'un test négatif (ExpectFailure), appliquer une série de « modifications » au programme pour un passage d'état séquentiel (EditDirs) et bien plus encore. Voyons comment les utiliser pour vérifier le déploiement de l'application.
Vérification des propriétés des ressources
L'intégration mentionnée ci-dessus garantit que notre programme « fonctionne » — il ne plante pas. Mais que faire si nous voulons vérifier les propriétés de la pile obtenue ? Par exemple, que certains types de ressources ont été (ou n'ont pas été) préparés et qu'ils ont des attributs spécifiques.
Paramètre ExtraRuntimeValidation pour ProgramTestOptions nous permet d'examiner l'état enregistré par Pulumi après le déploiement (post-deployment state), afin que nous puissions effectuer des vérifications supplémentaires. Cela inclut un instantané complet de l'état de la pile résultante, y compris la configuration, les valeurs de sortie exportées, toutes les ressources et les valeurs de leurs propriétés, ainsi que toutes les dépendances entre les ressources.
Pour voir un exemple de base de cela, vérifions que notre programme crée un S3 Bucket:
integration.ProgramTest(t, &integration.ProgramTestOptions{
// comme précédemment...
ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) {
var foundBuckets int
for _, res := range stack.Deployment.Resources {
if res.Type == "aws:s3/bucket:Bucket" {
foundBuckets++
}
}
assert.Equal(t, 1, foundBuckets, "Une seule AWS S3 Bucket attendue")
},
})Maintenant que nous allons exécuter go test, il passera non seulement par une batterie de tests de cycle de vie, mais également, après le déploiement réussi de la pile, effectuera une vérification supplémentaire de l'état résultant.
Tests d'exécution
Jusque-là, tous les tests portaient exclusivement sur le comportement lors du déploiement et sur la modélisation des ressources Pulumi. Que faire si vous souhaitez vérifier que votre infrastructure préparée fonctionne réellement ? Par exemple, que la machine virtuelle est opérationnelle, que le bucket S3 contient ce que nous attendons, etc.
Vous avez peut-être déjà deviné comment faire cela : l'option ExtraRuntimeValidation pour ProgramTestOptions est une excellente opportunité pour cela. À ce stade, vous exécutez un test Go arbitraire avec accès à l'état complet des ressources de votre programme. Cet état inclut des informations telles que les adresses IP des machines virtuelles, les URL, et tout ce qui est nécessaire pour interagir réellement avec les applications et infrastructures cloud obtenues.
Par exemple, notre programme de test exporte la propriété webEndpoint du bucket appelé websiteUrl, qui représente l'URL complète par laquelle nous pouvons accéder au document index. Bien que nous puissions fouiller dans le fichier d'état pour trouver bucket et lire cette propriété directement, dans de nombreux cas, nos piles exportent des propriétés utiles, telles que celle-ci, que nous pouvons facilement utiliser pour la vérification :
integration.ProgramTest(t, &integration.ProgramTestOptions{
// comme précédemment ...
ExtraRuntimeValidation: func(t *testing.T, stack integration.RuntimeValidationStackInfo) {
url := "http://" + stack.Outputs["websiteUrl"].(string)
resp, err := http.Get(url)
if !assert.NoError(t, err) {
return
}
if !assert.Equal(t, 200, resp.StatusCode) {
return
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
if !assert.NoError(t, err) {
return
}
assert.Contains(t, string(body), "Bonjour, Pulumi !")
},
}) Comme nos précédentes vérifications d'exécution, cette vérification sera effectuée immédiatement après le déploiement de la pile, et tout cela en réponse à un simple appel go test. Et ce n'est que la pointe de l'iceberg - toutes les fonctionnalités de test de Go sont accessibles, que vous pouvez écrire dans votre code.
Intégration continue de l'infrastructure
C'est bien de pouvoir exécuter des tests sur un ordinateur portable lorsque de nombreuses modifications sont apportées à l'infrastructure, afin de les vérifier avant de les soumettre pour une révision de code. Mais nous et de nombreux clients testons l'infrastructure à différentes étapes du cycle de développement :
- Dans chaque demande de tirage ouverte pour test avant la fusion.
- En réponse à chaque commit, pour vérifier que la fusion a été réalisée correctement.
- Périodiquement, par exemple, la nuit ou chaque semaine pour des tests supplémentaires.
- Dans le cadre des tests de performance ou de la validation de charge, qui sont généralement effectués sur une longue période et exécutent des tests en parallèle et/ou déploient plusieurs fois le même programme.
Pour chacun d'eux, Pulumi prend en charge l'intégration avec votre système d'intégration continue préféré. Avec l'intégration continue, cela vous donne la même couverture de test pour votre infrastructure que pour vos applications logicielles.
Pulumi prend en charge les systèmes CI courants. Voici quelques-uns d'entre eux :
Pour plus de détails, reportez-vous à la documentation sur .
Environnements éphémères
Une fonctionnalité très puissante qui se présente est la capacité de déployer des environnements éphémères uniquement à des fins de tests d'acceptation. Le concept de Pulumi est conçu de manière à permettre de déployer et de détruire facilement des environnements complètement isolés et indépendants, tout cela en quelques simples commandes CLI ou à l'aide d'un cadre de test d'intégration.
Si vous utilisez GitHub, Pulumi propose l' , qui vous aidera à connecter les tests d'acceptation aux demandes de tirage au sein de votre pipeline CI. Il suffit d'installer l'application dans le dépôt GitHub, puis Pulumi dans votre CI et des informations sur l'aperçu de l'infrastructure, les mises à jour et les résultats des tests seront ajoutées aux demandes de tirage :
En utilisant Pulumi pour vos tests d'acceptation principaux, vous obtiendrez de nouvelles possibilités d'automatisation qui amélioreront la productivité de l'équipe et renforceront la confiance dans la qualité des modifications.
Conclusion
Dans cet article, nous avons vu qu'en utilisant des langages de programmation polyvalents, de nombreuses méthodes de développement logiciel deviennent accessibles, lesquelles ont été utiles pour le développement de nos applications. Cela inclut les tests unitaires, les tests d'intégration, ainsi que leur interaction pour effectuer des tests d'exécution approfondis. Les tests peuvent être facilement lancés à la demande ou dans votre système CI.
Pulumi — un logiciel open source, il est gratuit à utiliser et fonctionne avec vos langages de programmation et infrastructures cloud préférés — !
→
Source : habr.com
