Artikelen
Tutorials
Interactieve handleidingen
Split-functievlaggen met Bitbucket-pipelines gebruiken
.png?cdnVersion=1581)
Warren Marusiak
Senior Technical Evangelist
Het implementeren van nieuwe code in een productieomgeving is riskant. Het kan gebeuren dat er bugs in de productie sluipen, zelfs nadat de code een unittest, integratietest en systeemtest heeft doorlopen in test- en stagingomgevingen. Van oudsher hebben ontwikkelaars twee keuzes als er eenmaal een bug in de productie zit, en dit heeft gevolgen voor gebruikers. Ze kunnen de buggy code terugdraaien of een oplossing inbrengen. Beide oplossingen kosten tijd. Nu kunnen ontwikkelaars een functie in een omgeving met één klik op de knop in- of uitschakelen door de gerelateerde codewijzigingen te verpakken in een functievlag. De impact van buggy code op gebruikers kan onmiddellijk worden beperkt, en er kan een oplossing worden ontwikkeld en op een veilige manier worden toegepast. Dit artikel laat dit zien aan de hand van Bitbucket Pipelines en de functievlaggen van Split in de ImageLabeller-demotoepassing.
Vereisten
Een demo van een ImageLabeller-functievlag
ImageLabeller is een kleine toepassing die gebruikmaakt van machine learning om afbeeldingen te labelen. ImageLabeller wordt geïmplementeerd in vijf omgevingen: Testen, Staging, Production-US-West-2, Production-US-East-1 en Production-CA-Central-1. Dit artikel laat zien hoe je functievlaggen kunt gebruiken om wijzigingen in de SubmitImage-component van ImageLabeller te beheren. SubmitImage is een AWS Lambda, geschreven in Go. Deze demo gebruikt Split om functievlaggen te beheren, Bitbucket voor bronbeheer en Bitbucket-pipelines voor CI/CD-functionaliteit.
Split-functievlaggen met Bitbucket-pipelines gebruiken
Maak een Split-account aan, ga naar Admin-instellingen en vervolgens naar Workspaces. Klik op Bekijken op de standaardworkspace om de beschikbare omgevingen te bekijken.
Hernoem de standaardomgevingen en voeg nieuwe omgevingen toe die passen bij je usecase. ImageLabeller wordt geïmplementeerd in vijf omgevingen. Test-, staging- en drie productieomgevingen die overeenkomen met drie AWS-regio's. US-WEST-2, US-EAST-1 en CA-CENTRAL-1.
Klik op Splitsingen en vervolgens op Splitsing aanmaken in het linkernavigatievenster om een nieuwe splitsing aan te maken: een functievlag.
Geef de splitsing een naam en wijzig het verkeerstype naar gebruiker.
Klik op Regels toevoegen om doelregels toe te voegen aan de splitsing nadat deze is gemaakt. Stel doelregels op voor de testomgeving. Elke omgeving kan verschillende doelregels hebben. De doelregels bepalen welke gegevens per splitsing worden geretourneerd wanneer ze in code worden geopend. In deze handleiding wordt de splitsing zo ingesteld dat deze standaard wordt uitgeschakeld, en op wanneer een specifieke gebruiker toegang heeft tot de splitsing.
Vouw Stel de standaardregel in uit en zet deze op uit.
Vouw Individuele doelen instellen uit, klik op Doel toevoegen en stel vervolgens Verzenden in op Aan, en stel Aan gebruikers in op een gebruiker die deel uitmaakt van het QA-proces. In deze handleiding wordt AtlassianDemoUser@atlassian.com gebruikt als testgebruiker.
Sla de wijzigingen op. De splitsing bevat nu doelregels voor de Testomgeving. Klik op de vervolgkeuzelijst Omgeving in een andere regio. Staging bijvoorbeeld.
Klik op Doelregels kopiëren van en kies Test om de doelregels te kopiëren die eerder zijn opgesteld. Herhaal dit proces voor elke omgeving. Het is mogelijk om per omgeving heel verschillende doelregels te hebben. In deze handleiding blijven de regels in alle omgevingen hetzelfde.
Ga naar de beheerdersinstellingen en vervolgens naar de API-sleutels voor een lijst van de API-sleutels voor elke omgeving. Deze api-sleutels worden teruggestuurd naar split tijdens API-aanroepen in code om de juiste versie van een split te krijgen. In deze handleiding worden de sleutels aan de kant van de Server gebruikt voor elke omgeving.
Ga naar je Bitbucket-repository, vervolgens naar Repository-instellingen, dan Repository-variabelen, en voeg variabelen toe voor elke API-sleutel.
Bewerk het bestand bitbucket-pipelines.yml en voeg STACK_PARAMETERS toe aan de implementatiestap van AWS SAM. Dit gebeurt per omgeving. Het YAML-fragment hieronder toont de implementatiestap voor de TEST-regio, in AWS US-WEST-1. Daarom verwijst de stap naar de bovenstaande repositoryvariabele split_test_env. Gebruik de juiste repositoryvariabele voor elke omgeving.
- 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}"
}]'Bewerk het template.yml-bestand van AWS CloudFormation en voeg een sectie Parameters toe die verwijst naar de Split SDK-sleutel.
Parameters:
SplitIOSDKKey:
Type: StringVoeg in het sjabloon.yml-bestand een sectie Omgeving toe aan elke AWS Lambda-bron die toegang nodig heeft tot Split. Deze handleiding demonstreert
Environment:
Variables:
SplitIOSDKKey:
Ref: SplitIOSDKKeyImporteer de volgende afhankelijkheden in het Go-bestand dat de Split SDK gaat gebruiken.
"github.com/splitio/go-client/v6/splitio/client"
"github.com/splitio/go-client/v6/splitio/conf"Deze functie maakt een client aan en haalt de functievlagwaarde op voor de 'SubmitImageDemoSplit' die gemaakt is in de Split UI. Er is maar één parameter voor nodig, namelijk de gebruikersnaam.
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
}Roep de functie op met een e-mailadres. In dat geval pakt someRandomUser@atlassian.com de standaardwaarde van de functievlag op, aangezien deze geen onderdeel is van een lijst met toelatingen die gekoppeld is aan de functievlag. AtlassianTestUser@atlassian.com pakt de waarde op van de functievlag die gekoppeld is aan de lijst met toegestane personen waarvan deze onderdeel is.
foo, err := getSplitIOFlag("someRandomUser@atlassian.com")
_ = foo
bar, err := getSplitIOFlag("AtlassianDemoUser@atlassian.com")
_ = bar
Kijk naar de uitvoer in de AWS CloudWatch-logboeken nadat de code is uitgevoerd. Houd er rekening mee dat de functievlag als 'uit' terugkeert wanneer deze wordt geopend door someRandomUser@atlassian.com, en als 'aan' wanneer AtlassianTestUser@atlassian.com deze opent.
Op deze manier kunnen ontwikkelaars de uitvoering van hun code controleren zonder een nieuwe implementatie uit te voeren. Als er bugs worden gevonden in een omgeving, kan de functievlag in die omgeving worden uitgeschakeld en kan de oude code worden uitgevoerd.
Conclusie
De functievlaggen van Split kunnen eenvoudig worden geïntegreerd in een toepassing die via Bitbucket-pipelines geïmplementeerd wordt. Met functievlaggen kunnen ontwikkelaars de uitvoering van de geïmplementeerde code controleren. Dit kan ervoor zorgen dat er sneller gereageerd kan worden op implementaties met fouten, waardoor de gevolgen voor gebruikers worden beperkt. Neem de tijd om een installatie van Bitbucket en Split te starten, en test de mogelijkheden voor je team.
.png?cdnVersion=1581)
Deel dit artikel
Volgend onderwerp
Aanbevolen artikelen
Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.
DevOps-community
DevOps-leertraject
