Articles
Tutoriels
Guides interactifs
Utilisation des feature flags Split avec Bitbucket Pipelines
.png?cdnVersion=1578)
Warren Marusiak
Senior Technical Evangelist
Le déploiement d'un nouveau code dans un environnement de production est risqué. Des bugs peuvent entrer en production même après que le code a été testé au niveau unitaire, de l'intégration et du système dans des environnements de test et de staging. Traditionnellement, les développeurs ont deux possibilités quand un bug arrive en production et que les utilisateurs sont touchés. Ils peuvent annuler le code qui pose problème ou déployer une correction. Ces deux solutions prennent du temps. Désormais, les développeurs peuvent activer ou désactiver une fonctionnalité dans un environnement en cliquant sur un bouton qui intègre les changements de code associés dans un feature flag. L'impact d'un code rempli de bugs sur les utilisateurs peut être atténué immédiatement, et une correction peut être développée et déployée en toute sécurité. Cet article présente cette solution à l'aide de Bitbucket Pipelines et des feature flags Split dans l'application de démo ImageLabeller.
Prérequis
Une démo de feature flag ImageLabeller
ImageLabeller est une petite application qui utilise l'apprentissage machine pour étiqueter des images. ImageLabeller est déployé dans cinq environnements. Test, Staging, Production-us-west-2, Production-us-east-1 et Production-ca-central-1. Cet article explique comment utiliser les feature flags pour gérer les changements apportés au composant SubmitImage d'ImageLabeller. SubmitImage est une fonction AWS Lambda écrite en Go. Cette démo utilise Split pour gérer les feature flags. Bitbucket pour le contrôle de version et Bitbucket Pipelines pour les fonctionnalités de CI/CD.
Comment utiliser des feature flags Split avec Bitbucket Pipelines
Créez un compte Split, accédez à Admin settings (Paramètres administrateur), puis à Workspaces (Espaces de travail). Cliquez sur View (Afficher) dans l'espace de travail par défaut pour voir les environnements disponibles.
Renommez les environnements par défaut et ajoutez de nouveaux environnements en fonction de votre cas d'usage. ImageLabeller est déployé dans cinq environnements. Test, Staging, et trois environnements de production correspondant à trois régions AWS : US-WEST-2, US-EAST-1 et CA-CENTRAL-1.
Cliquez sur Splits, puis sur Create split (Créer un split) dans le panneau de navigation de gauche pour créer un split, qui est un feature flag.
Donnez un nom au split et changez la valeur Traffic Type (Type de trafic) en User (Utilisateur).
Cliquez sur Add rules (Ajouter des règles) pour ajouter des règles de ciblage au split une fois celui-ci créé. Créez des règles de ciblage pour l'environnement de test. Chaque environnement peut avoir des règles de ciblage distinctes. Les règles de ciblage définissent les données renvoyées par le split lorsqu'un utilisateur y accède dans le code. Ce guide définit le split pour qu'il renvoie par défaut la valeur off et la valeur on lorsqu'un utilisateur spécifique y accède.
Développez Set the default rule (Définir la règle par défaut) et définissez sa valeur sur off.
Développez Set individual targets (Définir des cibles individuelles), cliquez sur Add Target (Ajouter une cible), puis définissez Serve (Envoyer) sur on, et dans To Users (Aux utilisateurs), indiquez les utilisateurs qui font partie du processus d'assurance qualité. Ce guide utilise AtlassianDemoUser@atlassian.com comme utilisateur test.
Enregistrez les changements. Le split comporte désormais des règles de ciblage pour l'environnement Test. Cliquez sur le menu déroulant Environment (Environnement) dans une autre région. Par exemple, Staging.
Cliquez sur Copy targeting rules from (Copier les règles de ciblage à partir de) et choisissez Test pour copier les règles de ciblage créées précédemment. Répétez cette procédure pour chaque environnement. Il est possible d'avoir des règles de ciblage très différentes par environnement. Ce guide conserve les mêmes règles de ciblage dans tous les environnements.
Accédez à Admin settings (Paramètres administrateur), puis à API keys (Clés d'API) pour obtenir la liste des clés d'API pour chaque environnement. Ces clés d'API sont renvoyées à Split lors des appels d'API sous forme de code afin d'obtenir la bonne version d'un split. Ce guide utilise les clés côté serveur pour chaque environnement.
Accédez à votre dépôt Bitbucket, à Repository settings (Paramètres du dépôt), puis à Repository variables (Variables de dépôt), et ajoutez des variables pour chaque clé d'API.
Modifiez le fichier bitbucket-pipelines.yml et ajoutez STACK_PARAMETERS à l'étape de déploiement d'AWS SAM. Cette opération s'effectue par environnement. Le snippet YAML ci-dessous montre l'étape de déploiement pour la région TEST qui se trouve dans AWS US-WEST-1. L'étape fait donc référence à la configuration de la variable du dépôt split_test_env ci-dessus. Utilisez la variable de dépôt appropriée pour chaque environnement.
- pipe: atlassian/aws-sam-deploy:1.2.0
variables:
AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
AWS_DEFAULT_REGION: 'us-west-1'
STACK_NAME: 'OpenDevOpsSubmitImage'
CAPABILITIES: [ 'CAPABILITY_IAM', 'CAPABILITY_NAMED_IAM', 'CAPABILITY_AUTO_EXPAND' ]
TEMPLATE: 'https://s3.amazonaws.com/open-devops-code-us-west-1-${AWS_ACCOUNT_ID}/submit-image-packaged.yml'
WAIT: 'true'
DEBUG: 'true'
S3_BUCKET: 'open-devops-code-us-west-1-${AWS_ACCOUNT_ID}'
SAM_TEMPLATE: 'build/template.yaml'
STACK_PARAMETERS: '[{
"ParameterKey": "SplitIOSDKKey",
"ParameterValue": "${split_test_env}"
}]'Modifiez le fichier template.yml AWS CloudFormation et ajoutez une section Parameters (Paramètres) faisant référence à la clé SDK de Split.
Parameters:
SplitIOSDKKey:
Type: StringDans le fichier template.yml, ajoutez une section Environment (Environnement) à chaque ressource AWS Lambda qui doit accéder à Split. Ce guide montre
Environment:
Variables:
SplitIOSDKKey:
Ref: SplitIOSDKKeyImportez les dépendances suivantes dans le fichier Go qui utilisera le SDK Split.
"github.com/splitio/go-client/v6/splitio/client"
"github.com/splitio/go-client/v6/splitio/conf"Cette fonction crée un client et récupère la valeur du feature flag pour l'élément « SubmitImageDemoSplit » créé dans l'interface utilisateur Split. Un seul paramètre est requis, le nom d'utilisateur.
func getSplitIOFlag(username string) (string, error) {
splitIOSDKKey := os.Getenv("SplitIOSDKKey")
cfg := conf.Default()
factory, err := client.NewSplitFactory(splitIOSDKKey, cfg)
if err != nil {
fmt.Printf("SDK init error: %s\n", err)
return "", err
}
splitClient := factory.Client()
err = splitClient.BlockUntilReady(10)
if err != nil {
fmt.Printf("SDK timeout: %s\n", err)
return "", err
}
treatment := splitClient.Treatment(username, "SubmitImageDemoSplit", nil)
fmt.Printf("SPLIT_DEMO treatment is %s, username is %s\n", treatment, username)
return treatment, nil
}Appelez la fonction avec une adresse e-mail. Dans ce cas, someRandomUser@atlassian.com récupérera la valeur par défaut du feature flag, puisqu'il ne fait pas partie d'une liste verte associée au feature flag. AtlassianTestUser@atlassian.com extraira la valeur du feature flag associée à la liste verte dont elle est membre.
foo, err := getSplitIOFlag("someRandomUser@atlassian.com")
_ = foo
bar, err := getSplitIOFlag("AtlassianDemoUser@atlassian.com")
_ = bar
Regardez les résultats dans les journaux AWS CloudWatch une fois le code exécuté. Notez que le feature flag se désactive lorsque someRandomUser@atlassian.com y accède, et qu'il s'active à nouveau lorsque AtlassianTestUser@atlassian.com y accède.
De cette façon, les développeurs peuvent contrôler l'exécution de leur code sans avoir à effectuer un autre déploiement. Si des bugs sont détectés dans un environnement, le feature flag de cet environnement peut être désactivé, et l'ancien code peut être exécuté.
Conclusion
Les feature flags Split s'intègrent facilement dans une application déployée via Bitbucket Pipelines. Les feature flags permettent aux développeurs de contrôler l'exécution du code déployé. Cela peut permettre de répondre plus rapidement aux déploiements remplis de bugs, réduisant ainsi l'impact sur les utilisateurs. Prenez le temps de créer une instance de Bitbucket et Split, et de tester les capacités de votre équipe.
.png?cdnVersion=1578)
Partager cet article
Thème suivant
Lectures recommandées
Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.
Communauté DevOps
Parcours de formation DevOps
