Verwenden von Split-Feature-Flags mit Bitbucket Pipelines
.png?cdnVersion=2441)
Warren Marusiak
Senior Technical Evangelist
Das Bereitstellen von neuem Code in einer Produktionsumgebung ist riskant. Bugs können auch dann in die Produktionsumgebung gelangen, wenn der Code in Test- und Staging-Umgebungen Unit-Tests, Integrationstests und Systemtests durchlaufen hat. Bisher hatten Entwickler zwei Möglichkeiten, wenn ein Bug in die Produktionsumgebung gelangt war und Benutzer davon betroffen waren: Sie konnten ein Rollback für den fehlerhaften Code oder ein Rollforward auf eine Version mit Fix durchführen. Beide Varianten brauchten Zeit. Jetzt können Entwickler eine Funktion in einer Umgebung mit nur einem Klick aktivieren oder deaktivieren, indem sie die entsprechenden Codeänderungen in ein Feature-Flag einschließen. So können die Auswirkungen von fehlerhaftem Code auf Benutzer sofort gemildert werden und die Entwickler erhalten die Möglichkeit, auf sichere Weise einen Fix zu entwickeln und zu implementieren. In diesem Artikel wird dieser Prozess mit Bitbucket Pipelines und Split-Feature-Flags in der ImageLabeller-Demo-Anwendung demonstriert.
Voraussetzungen
ImageLabeller-Feature-Flag-Demo
ImageLabeller ist eine kleine Anwendung, die maschinelles Lernen nutzt, um Images mit Stichwörtern zu versehen. ImageLabeller wird in fünf Umgebungen bereitgestellt: Test, Staging, Production-us-west-2, Production-us-east-1 und Production-ca-central-1. In diesem Artikel erfährst du, wie du mithilfe von Feature-Flags Änderungen an der SubmitImage-Komponente von ImageLabeller verwalten kannst. SubmitImage ist ein in Go geschriebenes AWS Lambda. Bei dieser Demo wird Split verwendet, um Feature-Flags zu verwalten. Bitbucket wird für die Quellcodekontrolle eingesetzt und Bitbucket Pipelines für CI/CD-Funktionen.
Verwenden von Split-Feature-Flags mit Bitbucket Pipelines
Erstelle ein Split-Konto. Navigiere zu den Admin-Einstellungen und dann zu Arbeitsbereiche. Klicke im Standard-Arbeitsbereich auf Anzeigen, um die verfügbaren Umgebungen zu sehen.
Du kannst die Standardumgebungen je nach Anwendungsfall umbenennen und neue Umgebungen hinzufügen. ImageLabeller wird in fünf Umgebungen bereitgestellt: Test, Staging und drei Produktionsumgebungen, die drei AWS-Regionen entsprechen (US-WEST-2, US-EAST-1 und CA-CENTRAL-1).
Klicke auf Splits und dann im linken Navigationsbereich auf Create split (Split erstellen), um einen neuen Split zu erstellen, d. h. ein Feature-Flag.
Gib dem Split einen Namen und ändere den Wert unter Traffic Type (Datenverkehrstyp) in "user" (Benutzer).
Klicke auf Regeln hinzufügen, um dem Split Targeting-Regeln hinzuzufügen, nachdem er erstellt wurde. Erstelle Targeting-Regeln für die Testumgebung. Jede Umgebung kann separate Targeting-Regeln haben. Die Targeting-Regeln definieren, welche Daten der Split zurückgibt, wenn darauf im Code zugegriffen wird. In diesem Leitfaden wird festgelegt, dass der Split standardmäßig off zurückgibt. Er gibt on zurück, wenn ein bestimmter Benutzer darauf zugreift.
Erweitere den Punkt Set the default rule (Standardregel festlegen), und setze sie auf off (Aus).
Erweitere den Punkt Set individual targets (Individuelle Ziele festlegen) und klicke dann auf Add Target (Ziel hinzufügen). Setze anschließend Serve (Bereitstellen) auf on (Ein), und lege unter To Users (Für Benutzer) einen Benutzer fest, der Teil des QS-Prozesses ist. In diesem Leitfaden wird AtlassianDemoUser@atlassian.com als Testbenutzer verwendet.
Speichere die Änderungen. Der Split weist jetzt Targeting-Regeln für die Testumgebung auf. Klicke auf das Drop-down-Menü Umgebung, um eine andere Region auszuwählen, beispielsweise "Staging".
Klicke auf Copy targeting rules from (Targeting-Regeln kopieren von) und wähle "Test" aus, um die zuvor erstellten Targeting-Regeln zu kopieren. Wiederhole diesen Vorgang für jede Umgebung. Es ist möglich, je nach Umgebung ganz unterschiedliche Targeting-Regeln festzulegen. In diesem Leitfaden sind die Targeting-Regeln in allen Umgebungen gleich.
Unter Admin settings > API keys (Admin-Einstellungen > API-Schlüssel) kannst du eine Liste der API-Schlüssel für die einzelnen Umgebungen abrufen. Diese API-Schlüssel werden bei API-Aufrufen im Code an Split zurückgesendet, um die richtige Version eines Splits zu erhalten. In diesem Leitfaden werden für alle Umgebungen die serverseitigen Schlüssel verwendet.
Wechsle zu deinem Bitbucket-Repository, dann zu den Repository-Einstellungen, dann zu den Repository-Variablen und füge Variablen für jeden API-Schlüssel hinzu.
Bearbeite die Datei bitbucket-pipelines.yml und füge STACK_PARAMETERS dem AWS SAM-Deployment-Schritt hinzu. Dies wird pro Umgebung durchgeführt. Das folgende YAML-Snippet zeigt den Deployment-Schritt für die TEST-Region, die sich in AWS US-WEST-1 befindet. Daher verweist der Schritt auf die zuvor eingerichtete Repository-Variable split_test_env. Verwende die passende Repository-Variable für jede Umgebung.
- 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}"
}]'Bearbeite die AWS CloudFormation-Datei "template.yml" und füge den Abschnitt "Parameter" hinzu, der auf den Split-SDK-Schlüssel verweist.
Parameters:
SplitIOSDKKey:
Type: StringFüge in der Datei "template.yml" jeder AWS Lambda-Ressource, die auf Split zugreifen muss, den Abschnitt "Umgebung" hinzu. Dieser Leitfaden zeigt
Environment:
Variables:
SplitIOSDKKey:
Ref: SplitIOSDKKeyImportiere die nachfolgend genannten Abhängigkeiten in die Go-Datei, die das Split-SDK verwenden soll.
"github.com/splitio/go-client/v6/splitio/client"
"github.com/splitio/go-client/v6/splitio/conf"Mit dieser Funktion wird ein Client erstellt und der Feature-Flag-Wert für das in der Split-UI erstellte "SubmitImageDemoSplit" abgerufen. Die Funktion erfordert nur einen Parameter: den Benutzernamen ("username").
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
}Rufe die Funktion mit einer E-Mail-Adresse auf. In diesem Fall wird bei someRandomUser@atlassian.com der Standardwert des Feature-Flags abgerufen, da der Benutzer nicht in einer mit dem Feature-Flag verknüpften Positivliste enthalten ist. Bei AtlassianTestUser@atlassian.com wird der Wert des Feature-Flags abgerufen, das der Positivliste zugeordnet ist, in der es enthalten ist.
foo, err := getSplitIOFlag("someRandomUser@atlassian.com")
_ = foo
bar, err := getSplitIOFlag("AtlassianDemoUser@atlassian.com")
_ = bar
Sieh dir die Ausgabe in den AWS CloudWatch-Protokollen an, nachdem der Code ausgeführt wurde. Du wirst bemerken, dass das Feature-Flag "off" zurückgibt, wenn es von someRandomUser@atlassian.com aufgerufen wird, und dass es "on" zurückgibt, wenn es von AtlassianTestUser@atlassian.com aufgerufen wird.
Auf diese Weise können Entwickler die Ausführung ihres Codes kontrollieren, ohne ein weiteres Deployment durchführen zu müssen. Wenn in einer Umgebung Bugs gefunden werden, kann das Feature-Flag in dieser Umgebung deaktiviert werden, sodass wieder der alte Code ausgeführt wird.
Fazit
Split-Feature-Flags lassen sich problemlos in eine Anwendung integrieren, die über Bitbucket Pipelines bereitgestellt wird. Mit Feature-Flags können Entwickler die Ausführung des bereitgestellten Codes kontrollieren. Dadurch kann schneller auf fehlerhafte Deployments reagiert werden, wodurch die Auswirkungen auf die Benutzer reduziert werden. Nimm dir die Zeit, eine Bitbucket-Instanz und Split einzurichten und die Funktionen für dein Team zu testen.
Diesen Artikel teilen
Nächstes Thema
Lesenswert
Füge diese Ressourcen deinen Lesezeichen hinzu, um mehr über DevOps-Teams und fortlaufende Updates zu DevOps bei Atlassian zu erfahren.
DevOps-Community
DevOps-Lernpfad
