Close

Utilizzo dei flag delle funzioni di Split con Bitbucket Pipelines

Primo piano di Warren Marusiak
Warren Marusiak

Senior Technical Evangelist

La distribuzione di nuovo codice in un ambiente di produzione è rischiosa. I bug possono entrare in produzione anche dopo che il codice, l'integrazione e il sistema sono stati testati in ambienti di test e staging. In passato gli sviluppatori avevano a disposizione due possibilità una volta che un bug entrava nell'ambiente di produzione e si verificavano conseguenze per gli utenti. Potevano eseguire il rollback del codice difettoso o apportare una correzione successiva, ma entrambe le soluzioni richiedevano tempo. Ora gli sviluppatori possono attivare o disattivare una funzione in un ambiente con un semplice clic racchiudendo le relative modifiche al codice in un flag delle funzioni. In questo modo l'impatto del codice difettoso sugli utenti si riduce immediatamente ed è possibile sviluppare una correzione da implementare in sicurezza successivamente. Questo articolo lo dimostra utilizzando Bitbucket Pipelines e i flag delle funzioni di Split nell'applicazione demo ImageLabeller.

Una demo del flag delle funzioni di ImageLabeller

ImageLabeller è una piccola applicazione che utilizza l'apprendimento automatico per etichettare le immagini. ImageLabeller è distribuita in cinque ambienti: test, staging, Production-us-west-2, Production-us-east-1 e Production-ca-central-1. Questo articolo dimostra come utilizzare i flag delle funzioni per gestire le modifiche al componente SubmitImage di ImageLabeller. SubmitImage è un AWS Lambda scritto in Go. Questa demo utilizza Split per gestire i flag delle funzioni. Bitbucket per il controllo del codice sorgente e Bitbucket Pipelines per la funzionalità CI/CD.

Come utilizzare i flag delle funzioni di Split con Bitbucket Pipelines

Crea un account Split, vai a Admin settings (Impostazioni di amministrazione) e quindi a Workspaces (Spazi di lavoro). Clicca su View (Visualizza) nell'area di lavoro predefinita per visualizzare gli ambienti disponibili.

Screenshot degli spazi di lavoro nelle impostazioni dell'amministratore

Rinomina gli ambienti predefiniti e aggiungi nuovi ambienti adatti al tuo caso d'uso. ImageLabeller è distribuita in cinque ambienti: Test, staging e tre ambienti di produzione corrispondenti a tre regioni AWS. US-WEST-2, US-EAST-1, and CA-CENTRAL-1.

Opzione di modifica dell'area di lavoro

Clicca su Splits, quindi su Create split (Crea split) nel pannello di navigazione a sinistra per creare un nuovo split, che è un flag delle funzioni.

Finestra pop-up per la creazione di uno split

Assegna un nome allo split e imposta il tipo di traffico su User (Utente).

Inserimento del tipo di traffico nella finestra di creazione di uno split

Clicca su Add Rules (Aggiungi regole) per aggiungere regole di targeting alla divisione dopo la sua creazione. Crea regole di targeting per l'ambiente di test. Ogni ambiente può avere regole di targeting distinte. Le regole di targeting definiscono i dati restituiti dallo split quando vi si accede in codice. Questa guida imposta lo split in modo che sia disattivato per impostazione predefinita e venga attivato quando un utente specifico vi accede.

Aggiunta di regole

Espandi Set the default rule (Imposta la regola predefinita) e impostala su off (disattivata).

Impostazione della regola predefinita

Espandi Set individual targets (Imposta target individuali), clicca su Add Target (Aggiungi target), quindi imposta Serve (Presenta) su on (attivata) e imposta To Users (A utenti) su alcuni utenti che fanno parte del processo di controllo di qualità. Questa guida utilizza AtlassianDemoUser@atlassian.com come utente di test.

Crea elenchi elementi consentiti

Salva le modifiche. Lo split ora dispone di regole di targeting per l'ambiente di test. Clicca sul menu a discesa Environment (Ambiente) in un'altra regione, ad esempio Staging.

Menu a discesa Environment (Ambiente)

Clicca su Copy targeting rules from (Copia regole di targeting da) e scegli Test per copiare le regole di targeting create in precedenza. Ripeti questa procedura per ogni ambiente. È possibile disporre di regole di targeting molto diverse per ambiente. In questa guida le regole di targeting restano invariate in tutti gli ambienti.

Copia delle regole di targeting

Da Admin settings (Impostazioni amministratore), vai alla sezione API keys (Chiavi API) per ottenere un elenco delle chiavi API per ogni ambiente. Le chiavi API vengono sottoposte a split durante le chiamate API in codice per ottenere la versione corretta di uno split. Questa guida utilizza le chiavi server-side per ogni ambiente.

Impostazioni dell'amministratore

Vai al repository Bitbucket, quindi a Repository settings (Impostazioni repository) e a Repository variables (Variabili repository), e aggiungi le variabili per ogni chiave API.

Variabili del repository nelle impostazioni del repository

Modifica il file bitbucket-pipelines.yml e aggiungi STACK_PARAMETERS al passaggio di distribuzione di AWS SAM. Questa operazione viene eseguita in base all'ambiente. Lo snippet YAML riportato di seguito mostra il passaggio di distribuzione per la regione TEST che si trova in AWS US-WEST-1. Pertanto, il passaggio fa riferimento alla variabile di repository split_test_env configurata sopra. Utilizza la variabile di repository appropriata per ogni ambiente.

- 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}"
    }]'

Modifica il file template.yml di AWS CloudFormation e aggiungi una sezione Parameters (Parametri) che fa riferimento alla chiave SDK Split.

Parameters:
  SplitIOSDKKey:
    Type: String

Nel file template.yml aggiungi una sezione Environment (Ambiente) a ogni risorsa AWS Lambda necessaria per l'accesso a Split. Questa guida dimostra

Environment:
  Variables:
    SplitIOSDKKey:
      Ref: SplitIOSDKKey

Importa le seguenti dipendenze nel file Go che utilizzerà l'SDK di Split.

"github.com/splitio/go-client/v6/splitio/client"
"github.com/splitio/go-client/v6/splitio/conf"

Questa funzione crea un client e recupera il valore del flag delle funzioni per "SubmitImageDemoSplit" creato nell'interfaccia utente di Split. È necessario un solo parametro, che è 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
}

Chiama la funzione con un indirizzo e-mail. In questo caso, someRandomUser@atlassian.com estrarrà il valore predefinito del flag delle funzioni poiché non fa parte di un elenco consentito associato al flag delle funzioni. AtlassianTestUser@atlassian.com estrarrà il valore del flag delle funzioni associato all'elenco di elementi consentiti di cui è membro.

foo, err := getSplitIOFlag("someRandomUser@atlassian.com")
  _ = foo

  bar, err := getSplitIOFlag("AtlassianDemoUser@atlassian.com")
  _ = bar

Guarda l'output nei log AWS CloudWatch dopo l'esecuzione del codice. Noterai che il flag delle funzioni si disattiva quando vi si accede da someRandomUser@atlassian.com e si riattiva quando vi si accede da AtlassianTestUser@atlassian.com.

Eventi del log

In questo modo, gli sviluppatori possono controllare l'esecuzione del loro codice senza dover eseguire un'altra distribuzione. Se vengono rilevati bug in un ambiente, il flag delle funzioni in quell'ambiente può essere disattivato ed è possibile eseguire il codice precedente.

Conclusione

I flag delle funzioni di Split si integrano facilmente in un'applicazione distribuita tramite Bitbucket Pipelines. Consentono agli sviluppatori di controllare l'esecuzione del codice distribuito, velocizzando in questo modo la risposta alle distribuzioni con bug e riducendo l'impatto sugli utenti. Prenditi il tempo necessario per creare un'istanza di Bitbucket, e di Split, e di testare le funzionalità per il tuo team.

Warren Marusiak
Warren Marusiak

Warren is a Canadian developer from Vancouver, BC with over 10 years of experience. He came to Atlassian from AWS in January of 2021.


Condividi l'articolo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Illustrazione su Devops

Community DevOps

Illustrazione su Devops

Percorso di apprendimento DevOps

Illustrazione di una mappa

Inizia gratis

Iscriviti alla nostra newsletter DevOps

Thank you for signing up