CircleCIを使ったSpringBoot/GAEアプリ開発の効率化ノウハウ

takemikamiʼs note ‒ http://takemikami.com/
CircleCIを使った
SpringBoot/GAEアプリ開発の効率化ノウハウ
Copyright (C) Takeshi Mikami. All rights reserved. 1
三上威 - @takemikami
アーリース情報技術株式会社代表取締役社⻑
CircleCI ユーザーコミュニティミートアップ #5
2019.6.28 @株式会社ビズリーチ

はじめに
•テーマ
CircleCIを使った
SpringBoot/GAEアプリ開発の効率化ノウハウ
•内容
• GitHub Flowによる開発プロセス
• コードレビューの効率化
本⽇のセッションでお話しする内容について⽰します
※ Spring Boot, Google App Engineを例に話しますが、
他のFrameworkや環境にも応⽤可能な内容です
※参考ソースコード: https://github.com/takemikami/circlecijp-20190628

⾃⼰紹介
• 三上威 (@takemikami)
• データエンジニア・サイエンティスト
• タスク: 分析・予測モデル開発・基盤構築 etc
• 対象: マーケティングデータ etc
• 略歴
• 甲南⼤学理学部応⽤数学科卒
• EC, CRM等のシステム構築 @ NEC系SIer
• ECサイトのマーケティングデータ分析 @ DeNA
• データ分析・予測モデル開発・基盤構築 @アーリース情報技術(株)
発表者のプロフィールを紹介します
※フリーランスの法⼈成り

⾃⼰紹介開発プロダクト
• objectify-appengine-memcacheclient
• Google Cloud DatastoreのJava⽤ライブラリ「Objectify」(v6以降)で、
Google AppEngine Memcache のキャッシュを利⽤するためのサービス
• https://github.com/takemikami/objectify-appengine-memcacheclient
• digdag-plugin-shresult
• ワークフローエンジン「Digdag」のプラグイン
• シェルスクリプトを実⾏し、標準出⼒をDigdagの変数に格納するオペレータ
• https://github.com/takemikami/digdag-plugin-shresult
発表者が作ったプロダクトを紹介します
etc

⾃⼰紹介技術同⼈誌
• Apache Hadoop & Sparkビッグデータプログラミング⼊⾨
• ビッグデータの加⼯や機械学習のためのプログラミングガイド
• 2019.4.14 技術書典6 @ 池袋サンシャインシティ2F 展⽰ホールD
発表者が執筆した同⼈誌を紹介します
https://takemikami.booth.pm/

GitHub Flowによる開発プロセス

効率化ノウハウの想定環境
• 想定環境
• ソースコード管理: GitHub
• 開発プロセス: GitHub Flow
• デプロイ先: Google App Engine Standard Environment
• フレームワーク: Spring Boot
• ビルドツール: Gradle
• IDE: IntelliJ IDEA
• CI/CDツール: CircleCI
→ 次ページ以降のスライドで、
GitHub Flow, Google App Engine について説明します
紹介する効率化ノウハウで想定する環境を⽰します

GitHub Flowとは
• 次のフローで運⽤
• masterブランチは常にデプロイ可能な状態であること
• 開発を始める時は、masterからブランチを切り、開発内容がわかるようにブラン
チ名をつける
• ローカルPCの作業は、同じブランチ名でサーバ(GitHub)にpushする
• 意⾒を求めたり、教えて欲しいことがある場合は、Pull Requestを使う
• 開発ブランチは、誰かにレビューを依頼して承認をもらったら、masterにマージ
できる
• masterにマージしたら、直ちにデプロイする
GitHub Flowを紹介します
「シンプルさ」に特徴がある
Gitによる開発ワークフローのモデル

GitHub Flowのブランチモデル
• GitHub Flowのブランチモデルは以下のようになります
GitHub Flowのブランチモデルを⽰します
commit
branch
branch
commit
merge
merge
(rebase) merge
commit
master branch
descriptive branch
descriptive branch
開発を始める時は
masterからブランチを切る
masterにマージしたら
直ちにデプロイ
レビュー承認をもらったら
masterにマージできる
masterは常に
デプロイ可能な状態に
開発中はPullRequestを使って相談

GitHub FlowとCI・レビュー・デプロイの関連
GitHub FlowとCI・レビュー・デプロイの関連を図に⽰します
Developer GitHub Reviewer CI
development
environment
staging
environment
clone/pull (master branch)
branch
commit
push (descriptive branch)
clone
send status(OK/NG)
auto test
deploy
review request
check check
approve
merge deploy
pull request
(⼈による)レビュー
CIによるチェック

Google App EngineのVersionとDeployment
• Google App Engineでは、Versionを作ってサービスを管理できる
Google App EngineのVersionとDeploymentについて説明します
20190629t101010
20190628t170812
20190628t131110
20190627t153324
endpoint
修正単位（機能追加や不具合修正）の単位Versionを作成可能
① 修正後、DeployしてVersionを作る
・・・
② Deploy後に、Versionを切り替え(promote)
新Versionでのサービスを公開する

コードレビューの効率化

コードレビューの⾯倒さ
• 他のブランチをチェックアウトするのが⾯倒
• IDEに取り込みInspectorでチェックしたいが、⾃分の作業を⼀段落させてブラン
チ切り替えるのは⾯倒
• 修正の差分のみに着⽬してレビューしにくい
• GitHubのPullRequestではコード差分をチェックできるが、Inspectorの指摘と紐
付けて確認したい
• 動作確認環境を作るのが⾯倒
• 簡単に動作確認したいが、PullRequestごと切り替えて環境を⽤意するのは⾯倒
→これらの課題に対する対処ノウハウを考えていきます
コードレビューの⾯倒さについて⽰します

GitHub FlowとCI・レビュー・デプロイの関連
GitHub FlowとCI・レビュー・デプロイの関連を図に⽰します
development
environment
staging
environment
branch
commit
clone
send status(OK/NG)
auto test
deploy
review request
check check
approve
merge deploy
pull request
(⼈による)レビュー
CIによるチェック
CIによって
レビューを⽀援

コードチェックの⾃動化
CIによるコードチェックの⾃動化イメージを⽰します
development
environment
staging
environment
branch
commit
clone
send status(OK/NG)
auto test
deploy
review request
check check
approve
merge deploy
pull request
CIでチェックツールを動かす

コードチェックの⾃動化 .circleci/config.yml
• CIでのコードチェックの⾃動化の流れ (.circleci/config.yml)
steps:
- run:
name:
command: |
./gradlew check
- store_artifacts:
path: ~/repo/build/reports
- run:
name: report
when: always
command: |
.circleci/report.sh
Gradleからチェックツールを実⾏
結果レポートをArtifactに保存
レポートへのリンクをPullRequestにコメント
（シェルスクリプトで実装）
※失敗時も実⾏するので「when: always」に

コードチェックの⾃動化レポートへのリンク
• Artifactのリンクがやや深い → botでPullRequestにリンクをコメント
リンクがやや深い
リンクをコメント

コードチェックの⾃動化 Artifactのリンク取得
• ArtifactのリンクURL⼀覧は以下コマンドで取得
※環境変数「CIRCLE_TOKEN」にtokenの設定要
• 例) PMDのレポートのURL取得
$ curl
https://circleci.com/api/v1.1/project/github/$CIRCLE_PROJECT_USERNAME/$CIRCLE_PROJE
CT_REPONAME/$CIRCLE_BUILD_NUM/artifacts?circle-token=$CIRCLE_TOKEN | jq -r '.[].url'
URL_LIST=$(curl
https://circleci.com/api/v1.1/project/github/$CIRCLE_PROJECT_USERNAME/$CIRCLE_PROJE
CT_REPONAME/$CIRCLE_BUILD_NUM/artifacts?circle-token=$CIRCLE_TOKEN | jq -r '.[].urlʼ)
URL_PMD=$(echo "$URL_LIST" | grep "pmd/main.html$")
後⽅⼀致でGrepすればOK

コードチェックの⾃動化 PullRequestにコメント
• GitHubのPullRequestへのコメントは以下のコマンドで可能
※環境変数「GITHUB_ACCESS_TOKEN」にtokenの設定要
GH_COMMENT_BODY="※コメント内容※"
CIRCLE_REPO=$CIRCLE_PROJECT_USERNAME/$CIRCLE_PROJECT_REPONAME
CIRCLE_PR_NUM="${CIRCLE_PR_NUMBER:-${CIRCLE_PULL_REQUEST##*/}}”
curl -s -u $GITHUB_ACCESS_TOKEN
-X POST
--data "{"body":"$GH_COMMENT_BODY"}"
https://api.github.com/repos/$CIRCLE_REPO/issues/$CIRCLE_PR_NUM/comments

補遺: CircleCIでIntelliJ IDEA のInspector実⾏
• IntelliJ IDEAのInspectionはバッチ実⾏が可能
• プロジェクト内で使⽤するIDEを統⼀出来る場合、
以下のような理由で、運⽤しやすい
• 指摘項⽬を各⾃PCとCIで統⼀出来る
• 指摘項⽬の設定をIntelliJ IDEAのGUIで設定できる
• レポートはxml形式なので、xmllintなどで加⼯すると⾒やすい
CircleCIでIntelliJ IDEAのInspectorを実⾏する参考情報を⽰します
(参考)
CircleCIでIntelliJ IDEAのInspection機能による静的テストを実⾏する | takemikami.com
https://takemikami.com/2018/12/08/CircleCIIntelliJ-IDEAInspection.html

修正差分に対するコードチェック
• PullRequestのコード差分箇所に対する
「チェックツールの指摘項⽬」に注⽬してレビューしたい
→各チェックツールの指摘項⽬を、コード差分箇所に絞り込み
PullRequestにbotでコメントする
修正差分に対するコードチェックの対応イメージを⽰します
絞り込んだ指摘項⽬を
コメント

修正差分に対するコードチェック
• 修正差分箇所のファイル名・⾏番号は、gitコマンドで取得
• masterブランチに対する未マージコミット⼀覧を表⽰
• ⾏ごとに最終変更コミットを表⽰
→これらの結果から、指摘項⽬をフィルタ
修正差分に対するコードチェックの対応イメージを⽰します
git --no-pager log --no-merges origin/master...HEAD | grep -e '^commit'
git --no-pager blame (対象ファイル)

動作確認⽤のデプロイ
動作確認⽤デプロイの対応イメージを⽰します
development
environment
staging
environment
branch
commit
clone
send status(OK/NG)
auto test
deploy
review request
check check
approve
merge deploy
pull request 開発中のモジュールを
動作確認⽤のVersionにデプロイ

• Google App EngineのVersion・PullRequestを対応づけてデプロイ
4
3
2
1
・・・
4
3
2
1
・・・
GitHub
PullRequest
App Engine
Version
PullRequest番号をVersionとして
デプロイする

• デプロイ時のVersion指定⽅法 (build.gradle)
// appengine deployment settings
appengine {
deploy {
projectId = System.getenv("GOOGLE_PROJECT_ID")
version = System.getenv("CIRCLE_PR_NUM") ?: (new Date()).format("yyyyMMdd't'HHmmss")
promote = "master" == System.getenv("CIRCLE_BRANCH")
}
}
PullRequestの番号をVersionに
masterへのマージ時以外は
切り替えない(promoteしない)

• Google App EngineのVersion・PullRequest番号を揃えてあるので、
次のリンクをPullRequestにbotで簡単にコメントできる
• アプリケーションへのリンク
• App Engine Dashboardへのリンク
• Stackdriver Loggingのログへのリンク
対象Versionの
各種リンクをコメント

• サービスのリンク:
• https://${CIRCLE_PR_NUM}-dot-default-dot-
${GOOGLE_PROJECT_ID}.appspot.com/
• Dashboardへのリンク:
• https://console.cloud.google.com/appengine?hl=ja&project=${GOOGLE_PROJ
ECT_ID}&serviceId=default&duration=PT1H&versionId=${CIRCLE_PR_NUM}
• Loggingへのリンク:
• https://console.cloud.google.com/logs/viewer?project=${GOOGLE_PROJECT_
ID}&hl=ja&resource=gae_app%2Fmodule_id%2Fdefault%2Fversion_id%2F${CI
RCLE_PR_NUM}&minLogLevel=0&expandAll=false
※ Version・PullRequest番号を揃えておくとリンクを⽣成しやすい

botによるPull Requestへのコメント
botによるPullRequestへのコメントのイメージ全体を⽰します
動作確認⽤
アプリケーションへ
Dashboard Logging
PMD Report
Checkstyle Report 指摘事項のコード
コメントを
レビュー⽤ポータルに

まとめ
• コードレビューには、次のような⾯倒さが伴う
• 他のブランチをチェックアウトするのが⾯倒
• 修正の差分のみに着⽬してレビューしにくい
• 動作確認環境を作るのが⾯倒
• コードレビューの⾯倒さをCI/CDによる⽀援で軽減できる
• レビュー担当者が⼿元に開発環境を⽤意せずレビュー可能
• PullRequestコメントをレビュー⽤ポータルにすると便利
本セッションのまとめです

参考情報

その他のCI関連ノウハウ
• GitHubのPullRequestでデプロイ先環境を切り替える運⽤⽅法
https://takemikami.com/2018/12/04/GitHubPullRequest.html
• groovyとcheckstyleによるプロジェクト固有のコーディングルールの
チェック⼿順
https://takemikami.com/2018/08/31/groovycheckstyle.html
• GitHubのPullRequestを⽤いた暫定対処コードのコントロール⼿法の提
案
https://takemikami.com/2019/06/02/GitHubPullRequest.html
• RubocopでPullRequestの変更箇所で問題があった場合のみCIを失敗さ
せる
https://takemikami.com/2018/01/30/RubocopPullRequestCI.html
その他のCI関連ノウハウの情報を⽰します

参考Webサイトリスト
• Built-in Environment Variables | circleci Docs
https://circleci.com/docs/2.0/env-vars/#built-in-environment-
variables
• Download an artifact file | circleci Docs
https://circleci.com/docs/api/#download-an-artifact-file
• Comments | GitHub REST API v3
https://developer.github.com/v3/issues/comments/
• Gradle と App Engine プラグインを使⽤する | Google App Engine
https://cloud.google.com/appengine/docs/standard/java/tools/gradl
e
本資料作成にあたって参考にしたWebサイトのリストです

CircleCIを使ったSpringBoot/GAEアプリ開発の効率化ノウハウ

More Related Content

What's hot

Similar to CircleCIを使ったSpringBoot/GAEアプリ開発の効率化ノウハウ

More from Takeshi Mikami

CircleCIを使ったSpringBoot/GAEアプリ開発の効率化ノウハウ