Artykuły
Samouczki
Interaktywne przewodniki
Używanie flag funkcji Split w Bitbucket Pipelines
.png?cdnVersion=2267)
Warren Marusiak
Starszy propagator techniczny
Wdrażanie nowego kodu w środowisku produkcyjnym bywa ryzykowne. Błędy mogą trafić do środowiska produkcyjnego pomimo wykonania testów jednostkowych, integracyjnych oraz systemowych kodu w środowiskach testowych i przejściowych. Dotychczas gdy błąd trafił do środowiska produkcyjnego, a użytkownicy zostali poszkodowani, programiści mieli dwa wyjścia. Mogli wycofać błędny kod lub wdrożyć poprawkę. Jednak każde z tych rozwiązań wymagało czasu. Teraz programiści mogą włączać i wyłączać funkcję w środowisku jednym kliknięciem, oznaczając odpowiednie zmiany w kodzie jako flagi funkcji. Pozwala to błyskawicznie wyeliminować wpływ błędnego kodu na użytkowników, dając czas na opracowanie poprawki i bezpieczne ponowne wdrożenie. W tym artykule przedstawiono ten proces z wykorzystaniem Bitbucket Pipelines oraz flag funkcji Split w aplikacji demonstracyjnej ImageLabeller.
Wymagania wstępne
Demonstracja flag funkcji w aplikacji ImageLabeller
ImageLabeller jest niewielką aplikacją, która wykorzystuje uczenie maszynowe do oznaczania obrazów etykietami. Aplikacja ImageLabeller jest wdrażana w pięciu środowiskach: testowym Test, przejściowym Staging oraz trzech produkcyjnych — Production-us-west-2, Production-us-east-1 i Production-ca-central-1. W tym artykule przedstawiono, jak wykorzystać flagi funkcji do zarządzania zmianami w komponencie SubmitImage aplikacji ImageLabeller. SubmitImage jest funkcją AWS Lambda napisaną w Go. W tej demonstracji do zarządzania flagami funkcji użyto aplikacji Split. Do kontroli kodu źródłowego wykorzystano Bitbucket, a do obsługi funkcji CI/CD — Bitbucket Pipelines.
Używanie flag funkcji Split w Bitbucket Pipelines
Utwórz konto Split, wybierając kolejno opcje Admin settings (Ustawienia administratora), a następnie Workspaces (Przestrzenie robocze). Kliknij opcję View (Wyświetl) w domyślnej przestrzeni roboczej, aby wyświetlić dostępne środowiska.
Zmień nazwy środowisk domyślnych i dodaj nowe środowiska pasujące do Twojego przypadku użycia. Aplikacja ImageLabeller jest wdrażana w pięciu środowiskach: testowym, przejściowym oraz trzech środowiskach produkcyjnych odpowiadających trzem regionom AWS — US-WEST-2, US-EAST-1 i CA-CENTRAL-1.
Kliknij kolejno opcje Splits (Podziały), a następnie Create split (Utwórz podział) w lewym panelu nawigacyjnym, aby utworzyć nowy podział, czyli flagę funkcji.
Nadaj podziałowi nazwę i zmień wartość ustawienia Traffic Type (Typ ruchu) na user (użytkownik).
Kliknij przycisk Add rules (Dodaj reguły), aby dodać reguły kierowania podziału po jego utworzeniu. Utwórz reguły kierowania dla środowiska testowego. Każde środowisko może mieć oddzielne reguły kierowania. Reguły kierowania definiują dane zwracane przez podział po uzyskaniu do niego dostępu w kodzie. W tym przewodniku podział domyślnie zwraca wartość off, a w przypadku dostępu przez konkretnego użytkownika — wartość on.
Rozwiń sekcję Set the default rule (Ustaw regułę domyślną) i wybierz ustawienie off (wył.).
Rozwiń sekcję Set individual targets (Ustaw pojedyncze przypadki kierowania), a następnie kliknij przycisk Add Target (Dodaj przypadek kierowania) i na liście Serve (Zwracaj) wybierz opcję on (wł.), a w polu To Users (Dla użytkowników) wskaż użytkownika należącego do procesu QA. W tym przewodniku użytkownikiem testowym jest AtlassianDemoUser@atlassian.com.
Zapisz zmiany. Podział zawiera teraz reguły kierowania dla środowiska testowego. Kliknij menu rozwijane Environment (Środowisko) i wybierz inny region, na przykład środowisko przejściowe (Staging).
Kliknij opcję Copy targeting rules from (Kopiuj reguły kierowania z) i wybierz Test, aby skopiować utworzone wcześniej reguły kierowania. Powtórz ten proces dla każdego środowiska. Do każdego środowiska można przypisać całkiem odmienne reguły kierowania. W tym przewodniku zastosujemy takie same reguły kierowania do wszystkich środowisk.
Przejdź do sekcji Admin settings (Ustawienia administratora), a następnie do obszaru API keys (Klucze API), aby uzyskać listę kluczy API do każdego środowiska. W trakcie wywołań interfejsu API w kodzie klucze te są wysyłane z powrotem do podziału w celu pobrania jego poprawnej wersji. W tym przewodniku w przypadku każdego środowiska wykorzystano klucze po stronie serwera Server-side.
Przejdź do repozytorium Bitbucket, a następnie wybierz kolejno Repository settings (Ustawienia repozytorium) i Repository variables (Zmienne repozytorium), aby dodać zmienne dla każdego klucza API.
Edytuj plik bitbucket-pipelines.yml i dodaj zmienną STACK_PARAMETERS do kroku wdrożenia AWS SAM. Tę operację trzeba wykonać dla każdego środowiska. Poniższy fragment kodu YAML przedstawia krok wdrożenia dla środowiska TEST znajdującego się w regionie AWS US-WEST-1. W związku z tym krok ten odnosi się do skonfigurowanej wyżej zmiennej repozytorium split_test_env. Dla każdego środowiska należy użyć odpowiedniej zmiennej repozytorium.
- 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}"
}]'Edytuj plik template.yml AWS CloudFormation i dodaj sekcję Parameters odwołującą się do klucza zestawu SDK aplikacji Split.
Parameters:
SplitIOSDKKey:
Type: StringW pliku template.yml dodaj sekcję Environment do każdego zasobu AWS Lambda, który musi uzyskać dostęp do aplikacji Split. W tym przewodniku pokazano
Environment:
Variables:
SplitIOSDKKey:
Ref: SplitIOSDKKeyZaimportuj poniższe zależności do pliku Go, który będzie używał zestawu SDK aplikacji Split.
"github.com/splitio/go-client/v6/splitio/client"
"github.com/splitio/go-client/v6/splitio/conf"Ta funkcja tworzy klienta i pobiera wartość flagi funkcji dla elementu „SubmitImageDemoSplit” utworzonego w interfejsie użytkownika aplikacji Split. Przyjmuje jeden parametr „username” — nazwę użytkownika.
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
}Wywołaj funkcję, używając adresu e-mail. W tym przypadku someRandomUser@atlassian.com spowoduje pobranie wartości domyślnej flagi funkcji, ponieważ ten adres nie należy do listy dozwolonych powiązanej z flagą funkcji. Adres AtlassianTestUser@atlassian.com spowoduje pobranie wartości flagi funkcji powiązanej z listą dozwolonych, do której należy.
foo, err := getSplitIOFlag("someRandomUser@atlassian.com")
_ = foo
bar, err := getSplitIOFlag("AtlassianDemoUser@atlassian.com")
_ = bar
Po wykonaniu kodu przejrzyj wyniki w dziennikach usługi AWS CloudWatch. Zwróć uwagę, że flaga funkcji zostaje ponownie wyłączona przy próbie uzyskania dostępu z adresu someRandomUser@atlassian.com i ponownie włączona, gdy dostęp ma miejsce z adresu AtlassianTestUser@atlassian.com.
Dzięki temu programiści mogą kontrolować wykonywanie swojego kodu bez konieczności przeprowadzania kolejnego wdrożenia. Jeśli w środowisku zostaną wykryte błędy, można wyłączyć flagę funkcji w takim środowisku, co umożliwi aktywowanie starego kodu.
Wnioski
Flagi funkcji Split można z łatwością zintegrować z aplikacją wdrażaną za pośrednictwem Bitbucket Pipelines. Flagi funkcji umożliwiają programistom kontrolowanie wykonywania wdrażanego kodu. Pozwala to przyspieszyć reagowanie na błędne wdrożenia, ograniczając ich wpływ na użytkowników. Poświęć chwilę na uruchomienie instancji Bitbucket i Split oraz przetestowanie możliwości dla Twojego zespołu.
Udostępnij ten artykuł
Następny temat
Zalecane lektury
Dodaj te zasoby do zakładek, aby dowiedzieć się więcej na temat rodzajów zespołów DevOps lub otrzymywać aktualności na temat metodyki DevOps w Atlassian.
Społeczność DevOps
Ścieżka szkoleniowa DevOps
