Wdrażanie aplikacji ImageLabeller za pomocą GitLab
Warren najpierw był programistą, a następnie został ewangelistą technicznym. Do firmy Atlassian dołączył w 2021 roku. Zajmował się zarówno tworzeniem oprogramowania telekomunikacyjnego w języku COBOL na komputerach mainframe, jak i pracą w nowoczesnej infrastrukturze chmurowej AWS. Pasjonuje się technologiami, a jego doświadczenie badawcze obejmuje uczenie maszynowe. Jako ewangelista techniczny Warren promuje możliwości produktów Atlassian i ich integracji z produktami partnerów, tworząc demonstracje, teksty i filmy. W wolnym czasie ćwiczy brazylijskie jiu-jitsu.
Aby zademonstrować sposób opracowywania i wdrażania aplikacji oraz zarządzania nimi przy użyciu Jira Software oraz różnych połączonych narzędzi, nasz zespół utworzył ImageLabeller, prostą aplikację demonstracyjną opartą na usłudze AWS, która wykorzystuje uczenie maszynowe do oznaczania etykietami obrazów.
Na tej stronie opisano, jak wdrożyć aplikację ImageLabeller za pomocą GitLab. Przed rozpoczęciem najlepiej zapoznać się ze stronami na temat architektury aplikacji ImageLabeller oraz konfiguracji AWS SageMaker, aby uzyskać kontekst.
Wymagania wstępne
Jeśli nie masz jeszcze grupy GitLab, utwórz ją od podstaw, wykonując procedurę opisaną w tym przewodniku GitLab.
Publiczne repozytoria GitHub z kodem aplikacji ImageLabeller
Film z demonstracją integracji systemu Jira z GitLab
Integracja systemu Jira z GitLab
W systemie Jira kliknij kolejno opcje Tablica, Aplikacje, a następnie GitLab.
Kliknij przycisk Pobierz teraz.
Kliknij Aplikacje, a następnie Zarządzaj aplikacjami.
Rozwiń pozycję GitLab for Jira.
Kliknij przycisk Dodaj przestrzeń nazw.
Wybierz istniejącą przestrzeń nazw i kliknij przycisk Połącz. Ten przewodnik zakłada, że masz już istniejące konto GitLab i grupę GitLab.
Dodawanie klucza SSH do GitLab
Kliknij ikonę profilu w prawym górnym rogu, a następnie wybierz opcję Preferences (Preferencje).
Kliknij opcję SSH Keys (Klucze SSH) i wykonaj instrukcje, aby wygenerować nowy klucz SSH lub użyć istniejącego klucza SSH.
Utworzenie repozytorium dla infrastruktury AWS S3
Standardowa pętla pracy programisty polega zazwyczaj na pobraniu przez programistę zadania z systemu Jira, przeniesieniu go do kolumny prac w toku, a następnie przystąpieniu do prac programistycznych. Identyfikator zgłoszenia Jira jest kluczem łączącym pracę programisty ze zgłoszeniem Jira. Jest on podstawowym składnikiem integracji między dwoma systemami.
Przejdź do systemu Jira i utwórz nowe zgłoszenie dotyczące dodania repozytorium infrastruktury AWS S3 do GitLab. Zanotuj identyfikator zgłoszenia. W tym przykładzie jest to IM-5.
Przejdź do GitLab i kliknij przycisk New project (Nowy projekt).
Kliknij opcję Create blank project (Utwórz pusty projekt).
Wprowadź wartość w polu Project name (Nazwa projektu) i wybierz odpowiednią grupę w sekcji Project URL (Adres URL projektu). Kliknij przycisk Create project (Utwórz projekt), aby kontynuować.
W terminalu przejdź do repozytorium s3_infra i uruchom poniższe polecenie, aby wypchnąć plik template.yml AWS CloudFormation do GitLab.
1git add --all
2git commit -m "IM-5 add s3_infra repository to gitlab"
3git remote add origin git@gitlab.com:pmmquickstartguides/s3_infra.git
4git branch -m mainline
5git push -u origin mainlineDodawanie klucza dostępu AWS
Kliknij opcję Settings (Ustawienia), a następnie pozycję CI/CD. Przewiń w dół i rozwiń obszar Variables (Zmienne). Kliknij przycisk Add variable (Dodaj zmienną).
Utwórz dwie zmienne. Jedną dla identyfikatora klucza dostępu AWS, a drugą dla tajnego klucza dostępu AWS.
Zabezpiecz zmienne tak, aby były używane jedynie przez pipeline'y uruchamiane na chronionych gałęziach i tagach. Przyznaj użytkownikowi IAM powiązanemu z kluczem dostępu AWS dostęp administratora. Możesz również zdecydować się na użycie bardziej szczegółowych ustawień kontroli dostępu, wybierając poszczególne zasady dostępu AWS.
Konfiguracja chronionych gałęzi w celu uzyskania dostępu do chronionych zmiennych
Kliknij opcję Settings (Ustawienia), a następnie Repository (Repozytorium). Przewiń w dół i rozwiń obszar Protected branches (Gałęzie chronione).
Wprowadź przedrostek identyfikatora zgłoszenia Jira oraz symbol *.
W tym przykładzie, gdzie identyfikatory zgłoszeń Jira mają postać IM-5, IM-6 itp., przedrostkiem jest IM-.
Wprowadź IM-* i kliknij przycisk Protect (Chroń).
Gałąź mainline oraz gałęzie IM-* zostaną wyświetlone jako gałęzie chronione.
Konfiguracja środowisk wdrożeniowych
Kliknij kolejno opcje Deployments (Wdrożenia), a następnie Environments (Środowiska). Kliknij przycisk New environment (Nowe środowisko), aby dodać nowe środowiska. W tym przykładzie występują środowiska testowe w regionach US-WEST-1 i US-EAST-2 oraz trzy środowiska produkcyjne w regionach US-WEST-2, US-EAST-1 i CA-CENTRAL-1.
Plik .gitlab-ci.yml wdrażania w AWS
Przejdź do repozytorium s3_infra w terminalu i utwórz gałąź o nazwie zgodnej z identyfikatorem zgłoszenia Jira.
1git checkout -b IM-5Utwórz plik .gitlab-ci.yml zawierający poniższy kod yaml. Definiuje on wdrożeniowy przepływ pracy dla środowiska testowego, przejściowego i produkcyjnego.
1stages:
2 - merge-request
3 - test-us-west-1
4 - test-us-east-2
5 - production-us-west-2
6 - production-us-east-1
7 - production-ca-central-1
8
9merge-request-pipeline-job:
10 stage: merge-request
11 rules:
12 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
13 script:
14 - echo "This pipeline always succeeds and enables merges during merge requests"
15 - echo true
16
17deploy-test-us-west-1:
18 stage: test-us-west-1
19 environment: test-us-west-1
20 rules:
21 - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
22 image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
23 script:
24 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
25 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
26 - aws cloudformation deploy --region us-west-1 --template-file template.yml --stack-name OpenDevOpsS3Infra
27
28deploy-test-us-east-2:
29 stage: test-us-east-2
30 environment: test-us-east-2
31 rules:
32 - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
33 image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
34 script:
35 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
36 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
37 - aws cloudformation deploy --region us-east-2 --template-file template.yml --stack-name OpenDevOpsS3Infra
38
39deploy-production-us-west-2:
40 stage: production-us-west-2
41 environment: production-us-west-2
42 rules:
43 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
44 image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
45 script:
46 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
47 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
48 - aws cloudformation deploy --region us-west-2 --template-file template.yml --stack-name OpenDevOpsS3Infra
49
50deploy-production-us-east-1:
51 stage: production-us-east-1
52 environment: production-us-east-1
53 rules:
54 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
55 image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
56 script:
57 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
58 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
59 - aws cloudformation deploy --region us-east-1 --template-file template.yml --stack-name OpenDevOpsS3Infra
60
61deploy-production-ca-central-1:
62 stage: production-ca-central-1
63 environment: production-ca-central-1
64 rules:
65 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
66 image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
67 script:
68 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
69 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
70 - aws cloudformation deploy --region ca-central-1 --template-file template.yml --stack-name OpenDevOpsS3InfraInformacje o pliku .gitlab-ci.yml
Etapy
Dodaj blok stages, aby zdefiniować kolejność wykonywania pipeline'u w GitLab. Etapy są wykonywane w kolejności, w której zostały zdefiniowane w bloku stages. Zadania powiązane z danym etapem są wykonywane równolegle.
1stages:
2 - merge-request
3 - test-us-west-1
4 - test-us-east-2
5 - production-us-west-2
6 - production-us-east-1
7 - production-ca-central-1Zadania
Zadania są powiązane z etapem i mogą być powiązane ze środowiskiem. Reguły określają, czy konkretne zadanie będzie wykonywane. Reguła w tym przykładzie sprawdza, czy gałąź pipeline'u nie jest gałęzią domyślną oraz czy pipeline nie jest uruchamiany automatycznie w ramach wniosku o scalenie.
Dla każdego zadania można zdefiniować inny obraz. Obrazy można skonfigurować za pomocą narzędzi niezbędnych do tworzenia skryptów zadań. Sekcja script definiuje zestaw kroków uruchamianych podczas wykonywania zadania.
1deploy-test-us-west-1:
2 stage: test-us-west-1
3 environment: test-us-west-1
4 rules:
5 - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
6 image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest
7 script:
8 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
9 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
10 - aws cloudformation deploy --region us-west-1 --template-file template.yml --stack-name OpenDevOpsS3InfraPipeline wniosku o scalenie
Pipeline jest uruchamiany automatycznie przez GitLab po zatwierdzeniu wniosku o scalenie. Zadanie można utworzyć dla tego pipeline'u przez dodanie reguły. W tym przykładzie zadanie zawsze przebiega pomyślnie.
1merge-request-pipeline-job:
2 stage: merge-request
3 rules:
4 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
5 script:
6 - echo "This pipeline always succeeds and enables merges during merge requests"
7 - echo trueWypychanie do gałęzi funkcji
Wykonaj poniższą instrukcję z poziomu wiersza polecenia, aby wypchnąć zmiany do gałęzi IM-5 repozytorium s3_infra. Uwzględnij identyfikator zgłoszenia Jira w komunikatach commita oraz nazwach gałęzi, aby wykorzystać integrację systemu Jira z GitLab do śledzenia, co dzieje się z Twoim projektem.
1git add --all
2git commit -m "IM-5 add .gitlab-ci.yml to s3_infra"
3git push -u origin IM-5Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić przebieg pipeline'u.
Kliknij identyfikator uruchomionego pipeline'u.
Kliknij zadanie, aby zobaczyć więcej szczegółów.
Tworzenie wniosku o scalenie
Aby utworzyć wniosek o scalenie, kliknij opcję Merge requests (Wnioski o scalenie), a następnie przycisk Create merge request (Utwórz wniosek o scalenie).
Wybierz gałąź funkcji jako gałąź źródłową, a następnie kliknij przycisk Compare branches and continue (Porównaj gałęzie i kontynuuj).
Wybierz odpowiednie osoby w sekcjach Assignee (Osoba przypisana) i Reviewer (Recenzent).
Kliknij przycisk Create merge request (Utwórz wniosek o scalenie).
Przejrzyj zmiany kodu, a następnie kliknij przycisk Approve (Zatwierdź).
Kliknij opcję CI/CD, a następnie opcję Pipelines (Pipeline'y), aby wyświetlić przebieg pipeline'u wniosku o scalenie.
Kliknij identyfikator pipeline'u. Zwróć uwagę, że zadanie merge-request-pipeline-job jest jedynym uruchomionym zadaniem.
Wróć do wniosku o scalenie, klikając opcję Merge requests (Wnioski o scalenie), a następnie kliknij aktywny wniosek o scalenie i przycisk Merge (Scal). To spowoduje zainicjowanie kolejnego pipeline'u.
Kliknij kolejno opcje CI/CD i Pipelines (Pipeline'y). Kliknij identyfikator pipeline'u.
Utworzenie repozytorium SystemTests
Przejdź do systemu Jira i utwórz zgłoszenie Jira dotyczące dodania repozytorium SystemTests do GitLab. Zanotuj identyfikator tego zgłoszenia Jira. W tym przykładzie jest to IM-7.
Wprowadź wartość w polu Project name (Nazwa projektu) i wybierz odpowiednią grupę w sekcji Project URL (Adres URL projektu). Kliknij przycisk Create project (Utwórz projekt), aby kontynuować.
W terminalu przejdź do repozytorium SystemTests i uruchom poniższe polecenie, aby wypchnąć kod do GitLab.
1git add --all
2git commit -m "IM-8 add SubmitImage to gitlab"
3git remote add origin git@gitlab.com:pmmquickstartguides/submitimage.git
4git branch -m mainline
5git push -u origin mainlineRepozytorium SystemTests nie wymaga pliku .gitlab-ci.yml. Nie ma własnych pipeline'ów, ponieważ udostępnia testy do uruchomienia w innych pipeline'ach. Zwróć uwagę na zdalny adres URL repozytorium SystemTests. Pipeline'y CI/CD SubmitImage, GetImageLabel i InvokeLabeller będą klonować repozytorium SystemTests podczas poszczególnych kroków testów. Konieczne będzie zaktualizowanie plików gitlab-ci.yml utworzonych później repozytoriów o poprawny adres URL.
Dodawanie tokena wdrożenia
Musisz dodać token wdrożenia, aby sklonować to repozytorium podczas wykonywania innych pipeline'ów. Kliknij opcję Settings (Ustawienia), a następnie Repository (Repozytorium). Przewiń w dół i rozwiń obszar Deploy tokens (Tokeny wdrożenia).
Wprowadź nazwę, zaznacz pozycję read_repository i kliknij przycisk Create deploy token (Utwórz token wdrożenia).
Nazwa użytkownika tokena wdrożenia jest generowana automatycznie. Hasło tokena wdrożenia podaje się jeden raz podczas jego tworzenia. Dodaj token do narzędzia zarządzania tajnymi kluczami, aby można było się do niego później odwołać. W dalszej części tego przewodnika odniesieniem do nazwy użytkownika tokena wdrożenia będzie gitlab_deploy_token, a odniesieniem do hasła tokena wdrożenia — gitlab_deploy_password.
Utworzenie repozytorium dla funkcji AWS Lambda SubmitImage
Przejdź do systemu Jira i utwórz nowe zgłoszenie dotyczące dodania repozytorium funkcji AWS Lambda SubmitImage do GitLab. Zanotuj identyfikator zgłoszenia. W tym przykładzie jest to IM-8.
Przejdź do GitLab, a następnie kliknij kolejno opcje New project (Nowy projekt) i Create blank project (Utwórz pusty projekt). Wprowadź wartość w polu Project name (Nazwa projektu) i wybierz odpowiednią grupę w sekcji Project URL (Adres URL projektu). Kliknij przycisk Create project (Utwórz projekt), aby kontynuować.
W terminalu przejdź do repozytorium SumbitImage i uruchom poniższe polecenie, aby wypchnąć kod do GitLab.
1git add --all
2git commit -m "IM-8 add SubmitImage to gitlab"
3git remote add origin git@gitlab.com:pmmquickstartguides/submitimage.git
4git branch -m mainline
5git push -u origin mainlineMusisz dodać klucze dostępu AWS, skonfigurować gałęzie chronione i skonfigurować środowiska wdrożeniowe.
Następnie dodaj klucze wdrożenia z repozytorium SystemTests, aby umożliwić pobranie pipeline'u GitLab SubmitImage i uruchom SystemTests.
Na końcu dodaj swój identyfikator konta AWS jako zmienną CI/CD.
Plik .gitlab-ci.yml wdrażania w AWS
Przejdź do repozytorium SubmitImage w terminalu i utwórz gałąź o nazwie zgodnej z identyfikatorem zgłoszenia Jira.
1git checkout -b IM-8Utwórz plik .gitlab-ci.yml zawierający poniższy kod yaml. Definiuje on wdrożeniowy przepływ pracy dla środowiska testowego, przejściowego i produkcyjnego. Musisz zaktualizować wiersz git clone dla SystemTests zgodnie z Twoim repozytorium SystemTests.
1stages:
2 - merge-request
3 - run-unit-tests
4#US-WEST-1
5 - deploy-us-west-1
6 - test-us-west-1
7#US-EAST-2
8 - deploy-us-east-2
9 - test-us-east-2
10#US-WEST-2
11 - deploy-us-west-2
12 - test-us-west-2
13#US-EAST-1
14 - deploy-us-east-1
15 - test-us-east-1
16#CA-CENTRAL-1
17 - deploy-ca-central-1
18 - test-ca-central-1
19
20merge-request-pipeline-job:
21 stage: merge-request
22 rules:
23 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
24 script:
25 - echo "This pipeline always succeeds and enables merge"
26 - echo true
27
28run-unit-tests:
29 stage: run-unit-tests
30 image: golang:buster
31 rules:
32 - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
33 script:
34 - cd submitImage
35 - go test ./opendevopslambda/...
36
37#US-WEST-1
38deploy-us-west-1:
39 stage: deploy-us-west-1
40 environment: test-us-west-1
41 image: python:latest
42 rules:
43 - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
44 before_script:
45 - pip3 install awscli --upgrade
46 - pip3 install aws-sam-cli --upgrade
47 - wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
48 - rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
49 - export PATH=$PATH:/usr/local/go/bin
50 - go version
51 script:
52 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
53 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
54 - sam build
55 - sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --region us-west-1
56 - sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-1 --no-fail-on-empty-changeset
57
58 #test-us-west-1:
59 # stage: test-us-west-1
60 # environment: test-us-west-1
61 # image: golang:buster
62 # rules:
63 # - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
64 # script:
65 # - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
66 # - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
67 # - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
68 # - cd systemtests
69 # - go test -v ./... -aws_region=us-west-1
70
71#US-EAST-2
72deploy-us-east-2:
73 stage: deploy-us-east-2
74 environment: test-us-east-2
75 image: python:latest
76 rules:
77 - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
78 before_script:
79 - pip3 install awscli --upgrade
80 - pip3 install aws-sam-cli --upgrade
81 - wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
82 - rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
83 - export PATH=$PATH:/usr/local/go/bin
84 - go version
85 script:
86 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
87 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
88 - sam build
89 - sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-east-2-$AWS_ACCOUNT_ID --region us-east-2
90 - sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage --s3-bucket open-devops-code-us-east-2-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-east-2 --no-fail-on-empty-changeset
91
92 #test-us-east-2:
93 # stage: test-us-east-2
94 # environment: test-us-east-2
95 # image: golang:buster
96 # rules:
97 # - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
98 # script:
99 # - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
100 # - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
101 # - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
102 # - cd systemtests
103 # - go test -v ./... -aws_region=us-east-2
104
105#US-WEST-2
106deploy-us-west-2:
107 stage: deploy-us-west-2
108 environment: production-us-west-2
109 image: python:latest
110 rules:
111 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
112 before_script:
113 - pip3 install awscli --upgrade
114 - pip3 install aws-sam-cli --upgrade
115 - wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
116 - rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
117 - export PATH=$PATH:/usr/local/go/bin
118 - go version
119 script:
120 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
121 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
122 - sam build
123 - sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-west-2-$AWS_ACCOUNT_ID --region us-west-2
124 - sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage --s3-bucket open-devops-code-us-west-2-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-2 --no-fail-on-empty-changeset
125
126 #test-us-west-2:
127 # stage: test-us-west-2
128 # environment: production-us-west-2
129 # image: golang:buster
130 # rules:
131 # - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
132 # script:
133 # - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
134 # - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
135 # - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
136 # - cd systemtests
137 # - go test -v ./... -aws_region=us-west-2
138
139#US-EAST-1
140deploy-us-east-1:
141 stage: deploy-us-east-1
142 environment: production-us-east-1
143 image: python:latest
144 rules:
145 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
146 before_script:
147 - pip3 install awscli --upgrade
148 - pip3 install aws-sam-cli --upgrade
149 - wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
150 - rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
151 - export PATH=$PATH:/usr/local/go/bin
152 - go version
153 script:
154 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
155 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
156 - sam build
157 - sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-east-1-$AWS_ACCOUNT_ID --region us-east-1
158 - sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage --s3-bucket open-devops-code-us-east-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-east-1 --no-fail-on-empty-changeset
159
160 #test-us-east-1:
161 # stage: test-us-east-1
162 # environment: production-us-east-1
163 # image: golang:buster
164 # rules:
165 # - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
166 # script:
167 # - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
168 # - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
169 # - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
170 # - cd systemtests
171 # - go test -v ./... -aws_region=us-east-1
172
173#CA-CENTRAL-1
174deploy-central-1:
175 stage: deploy-ca-central-1
176 environment: production-ca-central-1
177 image: python:latest
178 rules:
179 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
180 before_script:
181 - pip3 install awscli --upgrade
182 - pip3 install aws-sam-cli --upgrade
183 - wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
184 - rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
185 - export PATH=$PATH:/usr/local/go/bin
186 - go version
187 script:
188 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
189 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
190 - sam build
191 - sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-ca-central-1-$AWS_ACCOUNT_ID --region ca-central-1
192 - sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage --s3-bucket open-devops-code-ca-central-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region ca-central-1 --no-fail-on-empty-changeset
193
194 #test-central-1:
195 # stage: test-ca-central-1
196 # environment: production-ca-central-1
197 # image: golang:buster
198 # rules:
199 # - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
200 # script:
201 # - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
202 # - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
203 # - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
204 # - cd systemtests
205 # - go test -v ./... -aws_region=ca-central-1Wykonanie testów integracyjnych jest na ten moment ujęte w komentarz. Testy systemowe zakończą się powodzeniem tylko wówczas, gdy cała aplikacja zostanie wdrożona. Po wdrożeniu wszystkich komponentów aplikacji ImageLabeller usuń oznaczenie komentarzem kroki testów integracyjnych w swoim repozytorium i wykonaj kolejne wypchnięcie, aby uruchomić pipeline wdrożenia. Musisz zaktualizować wiersz git clone dla SystemTests zgodnie z Twoim repozytorium SystemTests.
Informacje o pliku .gitlab-ci.yml
Ten krok wykonuje testy jednostkowe będące częścią repozytorium SubmitImage.
1unit-test-us-west-1:
2 stage: unit-test-us-west-1
3 environment: test-us-west-1
4 image: golang:buster
5 rules:
6 - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
7 script:
8 - cd submitImage
9 - go test ./opendevopslambda/...To zadanie wykorzystuje AWS SAM do wdrożenia funkcji AWS Lambda SubmitImage. Zwróć uwagę na sekcję before_script. Ten krok jest uruchamiany przed sekcją script i można go używać do instalowania zależności i konfigurowania różnych narzędzi.
1deploy-us-west-1:
2 stage: deploy-us-west-1
3 environment: test-us-west-1
4 image: python:latest
5 rules:
6 - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
7 before_script:
8 - pip3 install awscli --upgrade
9 - pip3 install aws-sam-cli --upgrade
10 - wget https://golang.org/dl/go1.16.6.linux-amd64.tar.gz
11 - rm -rf /usr/local/go && tar -C /usr/local -xzf go1.16.6.linux-amd64.tar.gz
12 - export PATH=$PATH:/usr/local/go/bin
13 - go version
14 script:
15 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
16 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
17 - sam build
18 - sam package --output-template-file submit-image-packaged.yaml --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --region us-west-1
19 - sam deploy --template-file submit-image-packaged.yaml --stack-name OpenDevOpsSubmitImage --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-1 --no-fail-on-empty-changesetTen krok pobiera i uruchamia testy integracyjne w repozytorium SystemTests. Musisz zaktualizować wiersz git clone dla SystemTests zgodnie z Twoim repozytorium SystemTests.
1test-us-west-1:
2 stage: test-us-west-1
3 environment: test-us-west-1
4 image: golang:buster
5 rules:
6 - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
7 script:
8 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
9 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
10 - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
11 - cd systemtests
12 - go test -v ./... -aws_region=us-west-1Wiersz git clone zawiera odwołanie do utworzonego wcześniej tokena wdrożenia.
1- git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.gitWypychanie do gałęzi funkcji
Wykonaj poniższą instrukcję z poziomu wiersza polecenia, aby wypchnąć zmiany do gałęzi IM-8 repozytorium SubmitImage. Uwzględnij identyfikator zgłoszenia Jira w komunikatach commita oraz nazwach gałęzi, aby wykorzystać integrację systemu Jira z GitLab do śledzenia, co dzieje się z Twoim projektem.
Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić przebieg pipeline'u.
Tworzenie wniosku o scalenie
Utwórz wniosek o scalenie, aby dokonać wdrożenia w środowiskach produkcyjnych po tym, jak GitLab przeprowadzi wdrożenia w środowiskach testowych. Wybierz gałąź IM-8.
Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić uruchomiony pipeline wniosku o scalenie.
Po ukończeniu pipeline'u wniosku o scalenie scal zmiany z gałęzią mainline. Kliknij opcję CI/CD, a następnie Pipeline'y, aby wyświetlić uruchomiony pipeline produkcyjny.
Utworzenie repozytorium dla funkcji AWS Lambda InvokeLabeller
Przejdź do systemu Jira i utwórz nowe zgłoszenie dotyczące dodania repozytorium funkcji AWS Lambda InvokeLabeller do GitLab. Zanotuj identyfikator zgłoszenia. W tym przykładzie jest to IM-10.
Przejdź do GitLab, a następnie kliknij kolejno opcje New project (Nowy projekt) i Create blank project (Utwórz pusty projekt). Wprowadź wartość w polu Project name (Nazwa projektu) i wybierz odpowiednią grupę w sekcji Project URL (Adres URL projektu). Kliknij przycisk Create project (Utwórz projekt), aby kontynuować.
W terminalu przejdź do repozytorium InvokeLabeller i uruchom poniższe polecenie, aby wypchnąć kod do GitLab.
1git add --all
2git commit -m "IM-10 add InvokeLabeller to gitlab"
3git remote add origin git@gitlab.com:pmmquickstartguides/invokelabeller.git
4git branch -m mainline
5git push -u origin mainlineMusisz dodać klucze dostępu AWS, skonfigurować gałęzie chronione i skonfigurować środowiska wdrożeniowe.
Następnie dodaj klucze wdrożenia z repozytorium SystemTests, aby umożliwić pobranie pipeline'u GitLab InvokeLabeller i uruchom SystemTests.
Na końcu dodaj swój identyfikator konta AWS jako zmienną CI/CD.
Plik .gitlab-ci.yml wdrażania w AWS
Przejdź do repozytorium InvokeLabeller w terminalu i utwórz gałąź o nazwie zgodnej z identyfikatorem zgłoszenia Jira.
1git checkout -b IM-10Utwórz plik .gitlab-ci.yml zawierający poniższy kod yaml. Definiuje on wdrożeniowy przepływ pracy dla środowiska testowego, przejściowego i produkcyjnego. Musisz zaktualizować wiersz git clone dla SystemTests zgodnie z Twoim repozytorium SystemTests.
1stages:
2 - merge-request
3 - run-unit-tests
4#US-WEST-1
5 - deploy-us-west-1
6 - test-us-west-1
7#US-EAST-2
8 - deploy-us-east-2
9 - test-us-east-2
10#US-WEST-2
11 - deploy-us-west-2
12 - test-us-west-2
13#US-EAST-1
14 - deploy-us-east-1
15 - test-us-east-1
16#CA-CENTRAL-1
17 - deploy-ca-central-1
18 - test-ca-central-1
19
20merge-request-pipeline-job:
21 stage: merge-request
22 rules:
23 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
24 script:
25 - echo "This pipeline always succeeds and enables merge"
26 - echo true
27
28run-unit-tests:
29 stage: run-unit-tests
30 image: python:3.8-buster
31 rules:
32 - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
33 before_script:
34 - pip3 install pytest
35 - pip3 install moto
36 - pip3 install -r tst/requirements.txt --user
37 script:
38 - python3 -m pytest -v tst/unit --junitxml=test-reports/report.xml
39
40#US-WEST-1
41deploy-us-west-1:
42 stage: deploy-us-west-1
43 environment: test-us-west-1
44 image: python:3.8-buster
45 rules:
46 - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
47 before_script:
48 - pip3 install awscli --upgrade
49 - pip3 install aws-sam-cli --upgrade
50 script:
51 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
52 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
53 - sam build
54 - sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --region us-west-1
55 - sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller --s3-bucket open-devops-code-us-west-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-1 --no-fail-on-empty-changeset
56
57 #test-us-west-1:
58 # stage: test-us-west-1
59 # environment: test-us-west-1
60 # image: golang:buster
61 # rules:
62 # - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
63 # script:
64 # - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
65 # - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
66 # - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
67 # - cd systemtests
68 # - go test -v ./... -aws_region=us-west-1
69
70#US-EAST-2
71deploy-us-east-2:
72 stage: deploy-us-east-2
73 environment: test-us-east-2
74 image: python:3.8-buster
75 rules:
76 - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
77 before_script:
78 - pip3 install awscli --upgrade
79 - pip3 install aws-sam-cli --upgrade
80 script:
81 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
82 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
83 - sam build
84 - sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-us-east-2-$AWS_ACCOUNT_ID --region us-east-2
85 - sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller --s3-bucket open-devops-code-us-east-2-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-east-2 --no-fail-on-empty-changeset
86
87 #test-us-east-2:
88 # stage: test-us-east-2
89 # environment: test-us-east-2
90 # image: golang:buster
91 # rules:
92 # - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
93 # script:
94 # - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
95 # - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
96 # - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
97 # - cd systemtests
98 # - go test -v ./... -aws_region=us-east-2
99
100#US-WEST-2
101deploy-us-west-2:
102 stage: deploy-us-west-2
103 environment: production-us-west-2
104 image: python:3.8-buster
105 rules:
106 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
107 before_script:
108 - pip3 install awscli --upgrade
109 - pip3 install aws-sam-cli --upgrade
110 script:
111 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
112 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
113 - sam build
114 - sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-us-west-2-$AWS_ACCOUNT_ID --region us-west-2
115 - sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller --s3-bucket open-devops-code-us-west-2-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-west-2 --no-fail-on-empty-changeset
116
117 #test-us-west-2:
118 # stage: test-us-west-2
119 # environment: production-us-west-2
120 # image: golang:buster
121 # rules:
122 # - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
123 # script:
124 # - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
125 # - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
126 # - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
127 # - cd systemtests
128 # - go test -v ./... -aws_region=us-west-2
129
130#US-EAST-1
131deploy-us-east-1:
132 stage: deploy-us-east-1
133 environment: production-us-east-1
134 image: python:3.8-buster
135 rules:
136 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
137 before_script:
138 - pip3 install awscli --upgrade
139 - pip3 install aws-sam-cli --upgrade
140 script:
141 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
142 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
143 - sam build
144 - sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-us-east-1-$AWS_ACCOUNT_ID --region us-east-1
145 - sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller --s3-bucket open-devops-code-us-east-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region us-east-1 --no-fail-on-empty-changeset
146
147 #test-us-east-1:
148 # stage: test-us-east-1
149 # environment: production-us-east-1
150 # image: golang:buster
151 # rules:
152 # - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
153 # script:
154 # - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
155 # - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
156 # - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
157 # - cd systemtests
158 # - go test -v ./... -aws_region=us-east-1
159
160#CA-CENTRAL-1
161deploy-central-1:
162 stage: deploy-ca-central-1
163 environment: production-ca-central-1
164 image: python:3.8-buster
165 rules:
166 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
167 before_script:
168 - pip3 install awscli --upgrade
169 - pip3 install aws-sam-cli --upgrade
170 script:
171 - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
172 - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
173 - sam build
174 - sam package --output-template-file invoke-labeller-packaged.yaml --s3-bucket open-devops-code-ca-central-1-$AWS_ACCOUNT_ID --region ca-central-1
175 - sam deploy --template-file invoke-labeller-packaged.yaml --stack-name OpenDevOpsInvokeLabeller --s3-bucket open-devops-code-ca-central-1-$AWS_ACCOUNT_ID --capabilities CAPABILITY_IAM --region ca-central-1 --no-fail-on-empty-changeset
176
177 #test-central-1:
178 # stage: test-ca-central-1
179 # environment: production-ca-central-1
180 # image: golang:buster
181 # rules:
182 # - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE != "merge_request_event"
183 # script:
184 # - export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID
185 # - export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY
186 # - git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.git
187 # - cd systemtests
188 # - go test -v ./... -aws_region=ca-central-1Aby zademonstrować sposób opracowywania i wdrażania aplikacji oraz zarządzania nimi przy użyciu Jira Software oraz różnych połączonych narzędzi, nasz zespół utworzył ImageLabeller, prostą aplikację demonstracyjną opartą na usłudze AWS, która wykorzystuje uczenie maszynowe do oznaczania etykietami obrazów.
Na tej stronie opisano, jak wdrożyć aplikację ImageLabeller za pomocą Bitbucket. Przed rozpoczęciem najlepiej zapoznać się ze stronami na temat architektury aplikacji ImageLabeller oraz konfiguracji AWS SageMaker, aby uzyskać kontekst.
Aktualizacja pliku src/app.py o punkt końcowy AWS SageMager
Otwórz plik src/app.py w repozytorium InvokeLabeller i wyszukaj pozycję query_endpoint. Zmień wartości endpoint_name i client region_name zgodnie z notesem AWS SageMaker.
1def query_endpoint(img):
2 endpoint_name = 'jumpstart-dft-image-labeller-endpoint'
3 client = boto3.client(service_name='runtime.sagemaker', region_name='us-west-1')
4 response = client.invoke_endpoint(EndpointName=endpoint_name, ContentType='application/x-image', Body=img)
5 model_predictions = json.loads(response['Body'].read())['predictions'][0]
6 return model_predictionsWypychanie do gałęzi funkcji
Wykonaj poniższą instrukcję z poziomu wiersza polecenia, aby wypchnąć zmiany do gałęzi IM-10 repozytorium InvokeLabeller. Uwzględnij identyfikator zgłoszenia Jira w komunikatach commita oraz nazwach gałęzi, aby wykorzystać integrację systemu Jira z GitLab do śledzenia, co dzieje się z Twoim projektem.
1git add --all
2git commit -m "IM-10 add .gitlab-ci.yml to InvokeLabeller"
3git push -u origin IM-10Kliknij opcję CI/CD, a następnie Pipelines (Pipeline'y), aby wyświetlić przebieg pipeline'u.
Tworzenie wniosku o scalenie
Utwórz wniosek o scalenie, aby dokonać wdrożenia w środowiskach produkcyjnych po tym, jak GitLab przeprowadzi wdrożenia w środowiskach testowych. Wybierz gałąź IM-10.
Po ukończeniu pipeline'u wniosku o scalenie scal zmiany z gałęzią mainline. Kliknij opcję CI/CD, a następnie Pipeline'y, aby wyświetlić uruchomiony pipeline produkcyjny.
Aby zademonstrować sposób opracowywania i wdrażania aplikacji oraz zarządzania nimi przy użyciu Jira Software oraz różnych połączonych narzędzi, nasz zespół utworzył ImageLabeller, prostą aplikację demonstracyjną opartą na usłudze AWS, która wykorzystuje uczenie maszynowe do oznaczania etykietami obrazów.
Na tej stronie opisano, jak wdrożyć aplikację ImageLabeller za pomocą Bitbucket. Przed rozpoczęciem najlepiej zapoznać się ze stronami na temat architektury aplikacji ImageLabeller oraz konfiguracji AWS SageMaker, aby uzyskać kontekst.