Share
Embed
Transcript
109 slides
-
#jjug_ccc CIパイプラインの対象範囲 14 • Single Page Application • Vue.js •
Spring Boot • PostgreSQL Vue.js PostgreSQL -
Gitlab-CIとは 16 GitLab CI/CDパイプラインは、統合され た単一のワークフローの一部としてコー ドのビルド、テスト、デプロイ、監視を行 います。 Forrester CI Wave™のリーダーに選出
されました。 https://www.gitlab.jp/stages-devops-lifecycle/continuous-integration/ -
#jjug_ccc Gitlab-CIの特徴 17 • マルチプラットフォーム: Unix、Windows、macOS、その他Goをサポートするあらゆるプラットフォームでビルドを実行 できます。 • 安定性: ビルドは
GitLab とは別のマシンで実行されます。 • 柔軟なパイプライン: ステージごとに複数の並列ジョブを定義し、 他のビルドをトリガー することができます。 • バージョン管理されたパイプライン: .gitlab-ci.yml ファイル にはテストなどのすべてのステップが含まれています。 ブ ランチで .gitlab-ci.yml ファイルを変更することで、誰でも安全にパイプラインの変更を試すことができます。 • Dockerのサポート: カスタムDockerイメージを使用したり、テストの一環として サービス を起動したり、 新しいDocker イメージをビルド したり、Kubernetes上で実行したりすることができます。 • コンテナレジストリ: コンテナイメージを保存、共有、使用するための 組み込みコンテナレジストリ を利用できます。 • 保護変数: 環境ごとに 保護変数 を使用して、デプロイに必要な認証情報などを安全に保存し、使用することができま す。 https://www.gitlab.jp/stages-devops-lifecycle/continuous-integration/ -
#jjug_ccc Gitlab-CIの特徴 18 • マルチプラットフォーム: Unix、Windows、macOS、その他Goをサポートするあらゆるプラットフォームでビルドを実行 できます。 • 安定性: ビルドは
GitLab とは別のマシンで実行されます。 • 柔軟なパイプライン: ステージごとに複数の並列ジョブ を定義し、 他のビルドをトリガー することができます。 • バージョン管理されたパイプライン: .gitlab-ci.yml ファイル にはテストなどのすべてのステップが含まれています。 ブ ランチで .gitlab-ci.yml ファイルを変更することで、誰でも安全にパイプラインの変更を試すことができます。 • Dockerのサポート: カスタムDockerイメージを使用したり、テストの一環として サービス を起動したり、 新しいDocker イメージをビルド したり、Kubernetes上で実行したりすることができます。 • コンテナレジストリ: コンテナイメージを保存、共有、使用するための 組み込みコンテナレジストリ を利用できます。 • 保護変数: 環境ごとに 保護変数 を使用して、デプロイに必要な認証情報などを安全に保存し、使用することができま す。 https://www.gitlab.jp/stages-devops-lifecycle/continuous-integration/ -
#jjug_ccc Gitlab-CIの特徴 19 • マルチプラットフォーム: Unix、Windows、macOS、その他Goをサポートするあらゆるプラットフォームでビルドを実行 できます。 • 安定性: ビルドは
GitLab とは別のマシンで実行されます。 • 柔軟なパイプライン: ステージごとに複数の並列ジョブを定義し、 他のビルドをトリガー することができます。 • バージョン管理されたパイプライン: .gitlab-ci.yml ファイル にはテストなどのすべてのステップが含まれています。 ブ ランチで .gitlab-ci.yml ファイルを変更することで、誰でも安全にパイプラインの変更を試すことができます。 • Dockerのサポート: カスタムDockerイメージを使用したり、テストの一環として サービス を起動したり、 新しいDocker イメージをビルド したり、Kubernetes上で実行したりすることができます。 • コンテナレジストリ: コンテナイメージを保存、共有、使用するための 組み込みコンテナレジストリ を利用できます。 • 保護変数: 環境ごとに 保護変数 を使用して、デプロイに必要な認証情報などを安全に保存し、使用することができま す。 https://www.gitlab.jp/stages-devops-lifecycle/continuous-integration/ -
#jjug_ccc .gitlab-ci.yml $ cat .gitlab-ci.yml stages: - build - test
build-code-job: stage: build script: - echo "Check the ruby version, then build some Ruby project files:" - ruby -v - rake test-code-job1: stage: test script: - echo "If the files are built successfully, test some files with one command:" - rake test1 test-code-job2: stage: test script: - echo "If the files are built successfully, test other files with a different command:" - rake test2 20 https://docs.gitlab.com/ee/ci/yaml/gitlab_ci_yaml.html -
#jjug_ccc Gitlab-CIの特徴 21 • マルチプラットフォーム: Unix、Windows、macOS、その他Goをサポートするあらゆるプラットフォームでビルドを実行 できます。 • 安定性: ビルドは
GitLab とは別のマシンで実行されます。 • 柔軟なパイプライン: ステージごとに複数の並列ジョブを定義し、 他のビルドをトリガー することができます。 • バージョン管理されたパイプライン: .gitlab-ci.yml ファイル にはテストなどのすべてのステップが含まれています。 ブ ランチで .gitlab-ci.yml ファイルを変更することで、誰でも安全にパイプラインの変更を試すことができます。 • Dockerのサポート: カスタムDockerイメージを使用したり、テストの一環として サービス を起動したり、 新しいDocker イメージをビルド したり、Kubernetes上で実行したりすることができます。 • コンテナレジストリ: コンテナイメージを保存、共有、使用するための 組み込みコンテナレジストリ を利用できます。 • 保護変数: 環境ごとに 保護変数 を使用して、デプロイに必要な認証情報などを安全に保存し、使用することができま す。 https://www.gitlab.jp/stages-devops-lifecycle/continuous-integration/ -
#jjug_ccc stageとは 37 $ cat .gitlab-ci.yml stages: # code -
build - test - deploy -
#jjug_ccc stageとは 41 $ cat .gitlab-ci.yml stages: # code -
build - test - deploy -
#jjug_ccc 静的解析 $ cat .gitlab-ci.yml stages: - test analysis: stage:
test image: openjdk script: - /bin/sh gradlew clean checkstyleMain checkstyleTest spotbugsMain pmdMain pmdTest 45 -
#jjug_ccc unit test job $ cat .gitlab-ci.yml stages: - test
services: - name: postgres unit-test: stage: test image: openjdk script: - /bin/sh gradlew clean test 48 -
#jjug_ccc servicesとは $ cat .gitlab-ci.yml stages: - test services: -
name: postgres unit-test: stage: test image: openjdk script: - /bin/sh gradlew clean test 49 -
#jjug_ccc unit test job $ cat .gitlab-ci.yml stages: - test
services: - name: postgres unit-test: stage: test image: openjdk script: - /bin/sh gradlew clean test 51 -
#jjug_ccc CIパイプラインへのテストの組み込み 55 code test deploy build merge request arch
test unit test analysis git push -
#jjug_ccc CIパイプラインへのテストの組み込み 56 code test deploy build analysis git push
arch test unit test analysis merge request -
#jjug_ccc CIパイプラインへのテストの組み込み 57 code test deploy build unit test git
push arch test unit test analysis merge request -
#jjug_ccc CIパイプラインへのテストの組み込み 58 code test deploy build arch test git
push arch test unit test analysis merge request -
#jjug_ccc CIパイプラインへのテストの組み込み 59 code test deploy build arch test unit
test analysis git push arch test unit test analysis merge request -
#jjug_ccc CIパイプラインへのテストの組み込み 60 code test build git push arch test
unit test analysis merge request arch test unit test analysis -
#jjug_ccc CIパイプラインへのテストの組み込み 61 code test deploy build build git push
arch test unit test analysis merge request arch test unit test analysis -
#jjug_ccc build job $ cat .gitlab-ci.yml stages: - build build:
stage: build image: openjdk script: - /bin/sh gradlew clean bootJar after_script: - aws s3 cp build/libs/app.jar s3://bucket/app.jar 63 -
#jjug_ccc build job $ cat .gitlab-ci.yml stages: - build build:
stage: build image: openjdk script: - /bin/sh gradlew clean bootJar after_script: - aws s3 cp build/libs/app.jar s3://bucket/app.jar 64 -
#jjug_ccc CIパイプラインへのテストの組み込み 65 code test deploy build build git push
arch test unit test analysis merge request arch test unit test analysis -
#jjug_ccc CIパイプラインへのテストの組み込み 66 code test deploy build git push arch
test unit test analysis merge request arch test unit test analysis build -
#jjug_ccc CIパイプラインへのテストの組み込み 67 code test deploy build trigger git push
arch test unit test analysis merge request arch test unit test analysis build -
#jjug_ccc trigger job $ cat .gitlab-ci.yml stages: - deploy trigger:
stage: deploy variables: APP_VERSION: 1.0 trigger: project: infra-repository 68 -
#jjug_ccc CIパイプラインへのテストの組み込み 69 code test deploy build trigger インフラ git
push arch test unit test analysis merge request arch test unit test analysis build -
#jjug_ccc CIパイプラインへのテストの組み込み 70 code test deploy build trigger インフラ deploy
git push arch test unit test analysis merge request arch test unit test analysis build -
#jjug_ccc deploy job $ cat .gitlab-ci.yml stages: - deploy deploy:
stage: deploy image: ansible script: - /usr/local/bin/ansible-playbook -i staging/hosts -e “app_version=${APP_VERSION’}” deploy.yml rules: - if ‘$APP_VERSION’ 71 -
#jjug_ccc deploy job $ cat .gitlab-ci.yml stages: - deploy deploy:
stage: deploy image: ansible script: - /usr/local/bin/ansible-playbook -i staging/hosts -e “app_version=${APP_VERSION’}” deploy.yml rules: - if ‘$APP_VERSION’ 72 -
#jjug_ccc CIパイプラインへのテストの組み込み 73 code test deploy build trigger インフラ deploy
git push merge request trigger analysis unit test arch test analysis unit test arch test build アプリケーション -
#jjug_ccc パフォーマンステストを自動化される前は 77 1. 負荷がかかるサーバを構築する 2. 負荷をかけるサーバを構築する 3. パフォーマンステストを実行する 4.
テストをもとにSpreadsheetのグラフに落としこむ 5. すべてのパフォーマンステストのシナリオに対して上記の作業を繰り返す -
#jjug_ccc パフォーマンステストを自動化される前は 80 1. 負荷がかかるサーバを構築する 2. 負荷をかけるサーバを構築する 3. パフォーマンステストを実行する 4.
テストをもとにSpreadsheetのグラフに落としこむ 5. すべてのパフォーマンステストのシナリオに対して上記の作業を繰り返す -
#jjug_ccc パフォーマンステストを自動化される前は 83 1. 負荷がかかるサーバを構築する 2. 負荷をかけるサーバを構築する 3. パフォーマンステストを実行する 4.
テストをもとにSpreadsheetのグラフに落としこむ 5. すべてのパフォーマンステストのシナリオに対して上記の作業を繰り返す -
#jjug_ccc パフォーマンステストを自動化される前は 84 1. 負荷がかかるサーバを構築する 2. 負荷をかけるサーバを構築する 3. パフォーマンステストを実行する 4.
テストをもとにSpreadsheetのグラフに落としこむ 5. すべてのパフォーマンステストのシナリオに対して上記の作業を繰り返す -
#jjug_ccc パフォーマンステストを自動化される前は 86 1. 負荷がかかるサーバを構築する 2. 負荷をかけるサーバを構築する 3. パフォーマンステストを実行する 4.
テストをもとにSpreadsheetのグラフに落としこむ 5. すべてのパフォーマンステストのシナリオに対して上記の作業を繰り返す -
#jjug_ccc パフォーマンステストを自動化される前は 87 1. 負荷がかかるサーバを構築する 2. 負荷をかけるサーバを構築する 3. パフォーマンステストを実行する 4.
テストをもとにSpreadsheetのグラフに落としこむ 5. すべてのパフォーマンステストのシナリオに対して上記の作業を繰り返す -
#jjug_ccc JMeter CLI $ jmeter -n -t scenario.jmx -l /usr/local/report/jtl.csv
-e -o /usr/local/report 89 -
#jjug_ccc パフォーマンステストを自動化される前は 90 1. 負荷がかかるサーバを構築する 2. 負荷をかけるサーバを構築する 3. パフォーマンステストを実行する 4.
テストをもとにSpreadsheetのグラフに落としこむ 5. すべてのパフォーマンステストのシナリオに対して上記の作業を繰り返す -
#jjug_ccc JTLファイル $ cat jtl.csv timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,fa ilureMessage,bytes,sentBytes,grpThreads,allThreads,URL,Latency,IdleTime,Connect 1234567890123,1,GET /index.html,200,OK,rakus.co.jp:1099-Thread Group
1-1,text,true,,1689,1,1,1,https://rakus.co.jp/,1,0,1 92 -
#jjug_ccc InfluxdbにJMeterの結果をインポートする方法 • JMeterのbackend listenerを利用する ◦ JMeterで負荷テスト中にリアルタイムで連携する方法 ◦ 3種類の方法がある ▪
(公式)InfluxDBBackendListenerClient ▪ (非公式)JMeter InfluxDB v2.0 listener plugin • JMeterのJTLファイルを利用する 94 -
#jjug_ccc 統計情報 $ cat statistics.json | jq . { "GET
/index.html" : { "transaction" : "GET /index.html", "sampleCount" : 1, "errorCount" : 0, "errorPct" : 0.0, "meanResTime" : 9.933357142857153, "medianResTime" : 3.0, "minResTime" : 0.0, "maxResTime" : 1557.0, "pct1ResTime" : 21.0, "pct2ResTime" : 34.0, "pct3ResTime" : 105.0, "throughput" : 23.258672993025723, "receivedKBytesPerSec" : 14.445816429262068, "sentKBytesPerSec" : 6.859491449115007 } } 96 -
#jjug_ccc パフォーマンステストを自動化される前は 101 1. 負荷がかかるサーバを構築する 2. 負荷をかけるサーバを構築する 3. パフォーマンステストを実行する 4.
テストをもとにSpreadsheetのグラフに落としこむ 5. すべてのパフォーマンステストのシナリオに対して上記の作業を繰り返す -
#jjug_ccc パフォーマンステストを自動化される前は 102 1. 負荷がかかるサーバを構築する 2. 負荷をかけるサーバを構築する 3. パフォーマンステストを実行する 4.
テストをもとにSpreadsheetのグラフに落としこむ 5. すべてのパフォーマンステストのシナリオに対して上記の作業を繰り返す -
#jjug_ccc パフォーマンステストを自動化される前の問題 1. 1つのJMeterシナリオをテストするのに時間がかかる → 自動化されたので夜間に実施できる 1. 手作業が多いので作業ミスが発生する → Ansibleを実行するのみで発生しにくくなった
1. テスト結果を確認するためのグラフを作るのに大変 → Grafanaが自動的に作成してくれる 107