Bereitstellen von ImageLabeller mit GitLab
Warren kam 2021 zu Atlassian und ist ein ehemaliger Entwickler, der heute als Technical Evangelist arbeitet. Er hat schon an allem gearbeitet: von COBOL-Telekommunikationssoftware auf Mainframes bis hin zu moderner Cloud-Infrastruktur bei AWS. Er hat eine Leidenschaft für Technologie und einen Forschungshintergrund im Bereich maschinelles Lernen. Als Technical Evangelist macht Warren in Demos, Texten und Videos auf die Möglichkeiten der Produkte und Partnerintegrationen von Atlassian aufmerksam. In seiner Freizeit geht er seiner Leidenschaft für Brasilianisches Jiu-Jitsu nach.
Um zu demonstrieren, wie Anwendungen mit Jira Software und verschiedenen verbundenen Tools entwickelt, bereitgestellt und verwaltet werden können, hat unser Team ImageLabeller entwickelt. Dabei handelt es sich um eine einfache Demo-Anwendung, die auf AWS basiert und maschinelles Lernen nutzt, um Images mit Stichwörtern zu versehen.
Auf dieser Seite wird das Bereitstellen von ImageLabeller mit GitLab behandelt. Wir empfehlen dir, vorab die Seiten zur ImageLabeller-Architektur und zur AWS SageMaker-Einrichtung zu lesen, um mehr über den Kontext zu erfahren.
Voraussetzungen
Falls du noch keine GitLab-Organisation hast, befolge die Schritte in diesem GitLab-Leitfaden, um eine neue Organisation zu erstellen.
Öffentlich zugängliche GitHub-Repositorys mit ImageLabeller-Code
Demo-Video zur Integration zwischen Jira und GitLab
Integrieren von Jira und GitLab
Klicke in Jira auf Board, dann auf Apps und dann auf GitLab.
Klicke auf Jetzt herunterladen.
Klicke auf Apps und dann auf Apps verwalten.
Erweitere den Eintrag "GitLab for Jira".
Klicke auf Add namespace (Namespace hinzufügen).
Wähle deinen bestehenden Namespace aus, und klicke auf Verknüpfen. In dieser Anleitung wird davon ausgegangen, dass du bereits ein GitLab-Konto und eine GitLab-Gruppe hast.
Hinzufügen des SSH-Schlüssels zu GitLab
Klicke oben rechts auf dein Profilsymbol und dann auf Einstellungen.
Klicke auf SSH-Schlüssel und befolge die Anweisungen, um einen neuen SSH-Schlüssel zu generieren oder einen vorhandenen SSH-Schlüssel zu verwenden.
Erstellen eines Repositorys für die AWS S3-Infrastruktur
In einem standardmäßigen Entwicklungszyklus wählen Entwickler normalerweise Tasks aus Jira aus, verschieben sie in den Bearbeitungsstatus und erledigen dann die Entwicklungsarbeit. Die Jira-Vorgangs-ID ist der Schlüssel, der die Entwicklungsarbeit mit dem Jira-Vorgang verbindet. Er ist die zentrale Integrationskomponente zwischen den beiden Systemen.
Erstelle in Jira einen neuen Vorgang für das Hinzufügen eines AWS S3-Infrastruktur-Repositorys zu GitLab. Notiere die Vorgangs-ID. In diesem Beispiel lautet sie "IM-5".
Klicke in GitLab auf Neues Projekt.
Klicke auf Create blank project (Leeres Projekt erstellen).
Füge einen Projektnamen hinzu und wähle unter Projekt-URL die entsprechende Gruppe aus. Klicke auf Projekt erstellen, um fortzufahren.
Wechsle in deinem Terminal zum Repository "s3_infra" und führe den folgenden Befehl aus, um deine AWS CloudFormation-Datei "template.yml" an GitLab zu pushen.
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 mainlineHinzufügen des AWS-Zugriffsschlüssels
Klicke auf Einstellungen und dann auf CI/CD. Scrolle nach unten und erweitere den Punkt Variablen. Klicke auf Add variable (Variable hinzufügen).
Erstelle zwei Variablen: eine für deine AWS-Zugangsschlüssel-ID und eine für deinen geheimen AWS-Zugriffsschlüssel.
Schütze die Variablen so, dass sie nur von Pipelines verwendet werden können, die auf geschützte Branches und Tags zurückgreifen. Gewähre dem mit dem AWS-Zugriffsschlüssel verknüpften IAM-Benutzer Administratorzugriff. Du kannst dich auch für eine detailliertere Zugriffskontrolle entscheiden, indem du individuelle AWS-Zugriffsrichtlinien auswählst.
Konfigurieren von geschützten Branches für den Zugriff auf geschützte Variablen
Klicke auf Einstellungen und dann auf Repository. Scrolle nach unten, und erweitere den Punkt Protected branches (Geschützte Branches).
Gib dein Jira-Vorgangs-ID-Präfix und ein Sternchen (*) ein.
Die Jira-Vorgangs-IDs ähneln "IM-5" und "IM-6" in diesem Beispiel: Das Präfix lautet "IM-".
Gib "IM-*" ein, und klicke auf Protect (Schützen).
Als geschützte Branches werden "mainline" und "IM-*" angezeigt.
Einrichten von Deployment-Umgebungen
Klicke auf Deployments und dann auf Umgebungen. Klicke auf New environment (Neue Umgebung), um neue Umgebungen hinzuzufügen. In diesem Beispiel gibt es in US-WEST-1 und US-EAST-2 Testumgebungen sowie in US-WEST-2, US-EAST-1 und CA-CENTRAL-1 Produktionsumgebungen.
".gitlab-ci.yml" für das Bereitstellen in AWS
Wechsle in deinem Terminal zum Repository "s3_infra" und erstelle einen Branch, den du nach der Jira-Vorgangs-ID benennst.
1git checkout -b IM-5Erstelle die Datei ".gitlab-ci.yml" mit dem nachfolgend angegebenen YAML. Dies definiert einen Deployment-Workflow für deine Test-, Staging- und Produktionsumgebungen.
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 OpenDevOpsS3InfraErläuterungen zur Datei ".gitlab-ci.yml"
Phasen
Füge einen stages-Block (Phasen-Block) hinzu, um die Ausführungsreihenfolge deiner GitLab-Pipeline zu definieren. Phasen werden in der Reihenfolge ausgeführt, in der sie im "stages"-Block angegeben sind. Jobs, die derselben Phase zugeordnet sind, werden parallel ausgeführt.
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-1Stellenangebote
Jobs sind jeweils einer Phase zugeordnet und können einer Umgebung zugeordnet werden. Regeln steuern, ob ein bestimmter Job ausgeführt wird oder nicht. Mit der Regel in diesem Beispiel wird überprüft, ob der Pipeline-Branch nicht der Standard-Branch ist und ob die Pipeline nicht automatisch als Teil eines Merge-Requests ausgeführt wird.
Du kannst für jeden Job ein anderes Image angeben. Du kannst Images mit den Tools einrichten, die für deine Job-Skripte erforderlich sind. Im Abschnitt script (Skript) wird festgelegt, welche Schritte bei Ausführung des Jobs durchgeführt werden sollen.
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 OpenDevOpsS3InfraMerge-Request-Pipeline
Eine Pipeline wird von GitLab automatisch ausgeführt, wenn ein Merge-Request genehmigt wird. Du kannst einen Job für diese Pipeline erstellen, indem du eine Regel hinzufügst. In diesem Beispiel verläuft der Job immer erfolgreich.
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 truePushen an einen Feature Branch
Führe über die Befehlszeile den nachfolgend angegebenen Befehl aus, um deine Änderungen an den Branch "IM-5" deines Repositorys "s3_infra" zu pushen. Füge die Jira-Vorgangs-ID in Commit-Nachrichten und Branch-Namen ein, damit die Integration zwischen Jira und GitLab die Änderungen am Projekt verfolgen kann.
1git add --all
2git commit -m "IM-5 add .gitlab-ci.yml to s3_infra"
3git push -u origin IM-5Klicke auf CI/CD und dann auf Pipelines, um die Ausführung der Pipeline anzuzeigen.
Klicke auf die Pipeline-ID der laufenden Pipeline.
Klicke auf einen Job, um weitere Details anzuzeigen.
Erstellen eines Merge-Requests
Um einen Merge-Request zu erstellen, klicke auf Merge requests (Merge-Requests) und dann auf Create merge request (Merge-Request erstellen).
Wähle deinen Feature Branch als Quell-Branch aus, und klicke dann auf Compare branches and continue (Branches vergleichen und fortfahren).
Wähle eine zugewiesene Person und einen Prüfer aus.
Klicke auf Create merge request (Merge-Request erstellen).
Überprüfe die Code-Änderungen, und klicke dann auf Genehmigen.
Klicke auf CI/CD und dann auf Pipelines, um die Ausführung der Merge-Request-Pipeline anzuzeigen
Klicke auf die Pipeline-ID. Du wirst bemerken, dass "merge-request-pipeline-job" der einzige Job ist, der ausgeführt wurde.
Wechsle zurück zum Merge-Request, indem du auf Merge requests (Merge-Requests) klickst, dann auf den aktiven Merge-Request und dann auf Merge (Merge durchführen). Damit wird eine weitere Pipeline gestartet.
Klicke auf CI/CD und dann auf Pipelines. Klicke auf die Pipeline-ID.
Erstellen eines Repositorys für SystemTests
Erstelle in Jira einen Jira-Vorgang für das Hinzufügen eines SystemTests-Repositorys zu GitLab. Notiere die Jira-Vorgangs-ID. In diesem Beispiel lautet sie "IM-7".
Füge einen Projektnamen hinzu und wähle unter Projekt-URL die entsprechende Gruppe aus. Klicke auf Projekt erstellen, um fortzufahren.
Wechsle in deinem Terminal zum SystemTests-Repository und führe den folgenden Befehl aus, um deinen Code an GitLab zu pushen.
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 mainlineDas SystemTests-Repository erfordert keine Datei "gitlab-ci.yml". Es hat keine eigene Pipeline, da es Tests für andere Pipelines bereitstellt. Notiere die SystemTests-Remote-URL. Die CI/CD-Pipelines von SubmitImage, GetImageLabel und InvokeLabeller klonen das SystemTests-Repository während der Testschritte. Du musst "gitlab-ci.yml" für spätere Repositorys mit der richtigen URL aktualisieren.
Hinzufügen eines Deploy-Tokens
Du musst ein Deploy-Token hinzufügen, um dieses Repository während der Ausführung anderer Pipelines zu klonen. Klicke auf Einstellungen und dann auf Repository. Scrolle nach unten und erweitere den Punkt Deploy tokens (Deploy-Token).
Gib einen Namen ein, aktiviere das Kontrollkästchen read_repository und klicke dann auf Create deploy token (Deploy-Token erstellen).
Der Benutzername für das Deploy-Token wird automatisch generiert. Das Deploy-Token-Passwort wird einmal bei der Erstellung angegeben. Füge es zu einem Tool zur Verwaltung geheimer Schlüssel hinzu, damit später darauf zurückgegriffen werden kann. Im weiteren Verlauf dieses Leitfadens wird der Benutzername für das Deploy-Token als gitlab_deploy_token referenziert und das Deploy-Token-Passwort als gitlab_deploy_password.
Erstellen eines Repositorys für das AWS Lambda SubmitImage
Erstelle in Jira einen neuen Vorgang für das Hinzufügen eines Repositorys für das AWS Lambda SubmitImage zu GitLab. Notiere die Vorgangs-ID. In diesem Beispiel lautet sie "IM-8".
Klicke in GitLab auf Neues Projekt und dann auf Create blank project (Leeres Projekt erstellen). Füge einen Projektnamen hinzu und wähle unter Projekt-URL die entsprechende Gruppe aus. Klicke auf Projekt erstellen, um fortzufahren.
Wechsle in deinem Terminal zum Repository "SubmitImage" und führe den folgenden Befehl aus, um deinen Code an GitLab zu pushen.
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 mainlineDu musst AWS-Zugriffsschlüssel hinzufügen, geschützte Branches konfigurieren und Deployment-Umgebungen einrichten.
Füge dann die Deployment-Schlüssel aus deinem Repository "SystemTests" hinzu, damit die SubmitImage-GitLab-Pipeline heruntergeladen werden kann, und führe SystemTests aus.
Füge abschließend deine AWS-Konto-ID als CI/CD-Variable hinzu.
".gitlab-ci.yml" für das Bereitstellen in AWS
Wechsle in deinem Terminal zum Repository "SubmitImage" und erstelle einen Branch, den du nach der Jira-Vorgangs-ID benennst.
1git checkout -b IM-8Erstelle die Datei ".gitlab-ci.yml" mit dem nachfolgend angegebenen YAML. Dies definiert einen Deployment-Workflow für deine Test-, Staging- und Produktionsumgebungen. Du musst die "git clone"-Zeile aktualisieren, sodass SystemTests dein SystemTests-Repository ist.
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-1Die Durchführung der Integrationstests wird vorerst auskommentiert. Die Systemtests werden erst bestanden, wenn die gesamte Anwendung bereitgestellt wurde. Kommentiere die Integrationstestschritte in deinem Repository ein und führe einen weiteren Push durch, um die Deployment-Pipeline auszuführen, nachdem alle Komponenten von ImageLabeller bereitgestellt wurden. Du musst die "git clone"-Zeile aktualisieren, sodass SystemTests dein SystemTests-Repository ist.
Erläuterungen zur Datei ".gitlab-ci.yml"
In diesem Schritt werden Unit-Tests ausgeführt, die Teil des Repositorys "SubmitImage" sind.
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/...In diesem Schritt wird das AWS Lambda SubmitImage mithilfe von AWS SAM bereitgestellt. Beachte den Abschnitt before_script. Dieser Schritt wird vor dem script-Abschnitt ausgeführt und kann verwendet werden, um Abhängigkeiten zu implementieren und verschiedene Tools einzurichten.
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-changesetIn diesem Schritt werden die Integrationstests im SystemTests-Repository heruntergeladen und ausgeführt. Du musst die "git clone"-Zeile aktualisieren, sodass SystemTests dein SystemTests-Repository ist.
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-1In der "git clone"-Zeile wird auf das zuvor erstellte Deploy-Token verwiesen.
1- git clone https://${gitlab_deploy_token}:${gitlab_deploy_password}@gitlab.com/pmmquickstartguides/systemtests.gitPushen an einen Feature Branch
Führe über die Befehlszeile den nachfolgend angegebenen Befehl aus, um deine Änderungen an den Branch "IM-8" des Repositorys "SubmitImage" zu pushen. Füge die Jira-Vorgangs-ID in Commit-Nachrichten und Branch-Namen ein, damit die Integration zwischen Jira und GitLab die Änderungen am Projekt verfolgen kann.
Klicke auf CI/CD und dann auf Pipelines, um die Ausführung der Pipeline anzuzeigen.
Erstellen eines Merge-Requests
Erstelle einen Merge-Request zum Bereitstellen in deinen Produktionsumgebungen nach dem GitLab-Deployment in deinen Testumgebungen. Wähle den Branch "IM-8" aus.
Klicke auf CI/CD und dann auf Pipelines, um die laufende Merge-Request-Pipeline anzuzeigen.
Merge die Änderungen nach Abschluss der Merge-Request-Pipeline in "mainline". Klicke auf CI/CD und dann auf Pipelines, um die laufende Produktionspipeline anzuzeigen.
Erstellen eines Repositorys für das AWS Lambda InvokeLabeller
Erstelle in Jira einen neuen Vorgang für das Hinzufügen eines Repositorys für das AWS Lambda InvokeLabeller zu GitLab. Notiere die Vorgangs-ID. In diesem Beispiel lautet sie "IM-10".
Klicke in GitLab auf Neues Projekt und dann auf Create blank project (Leeres Projekt erstellen). Füge einen Projektnamen hinzu und wähle unter Projekt-URL die entsprechende Gruppe aus. Klicke auf Projekt erstellen, um fortzufahren.
Wechsle in deinem Terminal zum InvokeLabeller-Repository und führe den folgenden Befehl aus, um deinen Code an GitLab zu pushen.
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 mainlineDu musst AWS-Zugriffsschlüssel hinzufügen, geschützte Branches konfigurieren und Deployment-Umgebungen einrichten.
Füge dann die Deployment-Schlüssel aus deinem Repository "SystemTests" hinzu, damit die InvokeLabeller-GitLab-Pipeline heruntergeladen werden kann, und führe SystemTests aus.
Füge abschließend deine AWS-Konto-ID als CI/CD-Variable hinzu.
".gitlab-ci.yml" für das Bereitstellen in AWS
Wechsle in deinem Terminal zum InvokeLabeller-Repository und erstelle einen Branch, den du nach der Jira-Vorgangs-ID benennst.
1git checkout -b IM-10Erstelle die Datei ".gitlab-ci.yml" mit dem nachfolgend angegebenen YAML. Dies definiert einen Deployment-Workflow für deine Test-, Staging- und Produktionsumgebungen. Du musst die "git clone"-Zeile aktualisieren, sodass SystemTests dein SystemTests-Repository ist.
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-1Um zu demonstrieren, wie Anwendungen mit Jira Software und verschiedenen verbundenen Tools entwickelt, bereitgestellt und verwaltet werden können, hat unser Team ImageLabeller entwickelt. Dabei handelt es sich um eine einfache Demo-Anwendung, die auf AWS basiert und maschinelles Lernen nutzt, um Images mit Stichwörtern zu versehen.
Auf dieser Seite wird das Bereitstellen von ImageLabeller mit Bitbucket behandelt. Wir empfehlen dir, vorab die Seiten zur ImageLabeller-Architektur und zur AWS SageMaker-Einrichtung zu lesen, um mehr über den Kontext zu erfahren.
Aktualisieren von "src/app.py" mit dem AWS SageMaker-Endpunkt
Öffne die InvokeLabeller-Datei "src/app.py" und suche nach "query_endpoint". Ändere die Einträge unter "endpoint_name" (Endpunktname) und "client region_name" (Client-Regionsname) so, dass sie zu deinem AWS SageMaker-Notebook passen.
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_predictionsPushen an einen Feature Branch
Führe über die Befehlszeile den nachfolgend angegebenen Befehl aus, um deine Änderungen an den Branch "IM-10" des InvokeLabeller-Repositorys zu pushen. Füge die Jira-Vorgangs-ID in Commit-Nachrichten und Branch-Namen ein, damit die Integration zwischen Jira und GitLab die Änderungen am Projekt verfolgen kann.
1git add --all
2git commit -m "IM-10 add .gitlab-ci.yml to InvokeLabeller"
3git push -u origin IM-10Klicke auf CI/CD und dann auf Pipelines, um die Ausführung der Pipeline anzuzeigen.
Erstellen eines Merge-Requests
Erstelle einen Merge-Request zum Bereitstellen in deinen Produktionsumgebungen nach dem GitLab-Deployment in deinen Testumgebungen. Wähle den Branch "IM-10" aus.
Merge die Änderungen nach Abschluss der Merge-Request-Pipeline in "mainline". Klicke auf CI/CD und dann auf Pipelines, um die laufende Produktionspipeline anzuzeigen.
Um zu demonstrieren, wie Anwendungen mit Jira Software und verschiedenen verbundenen Tools entwickelt, bereitgestellt und verwaltet werden können, hat unser Team ImageLabeller entwickelt. Dabei handelt es sich um eine einfache Demo-Anwendung, die auf AWS basiert und maschinelles Lernen nutzt, um Images mit Stichwörtern zu versehen.
Auf dieser Seite wird das Bereitstellen von ImageLabeller mit Bitbucket behandelt. Wir empfehlen dir, vorab die Seiten zur ImageLabeller-Architektur und zur AWS SageMaker-Einrichtung zu lesen, um mehr über den Kontext zu erfahren.