Git 未経験者が GitHub Actions で CI/CD できるようになるまで Git 未経験者が GitHub Actions で CI/CD できるようになるまで 2022-11-27 JJUG CCC 2022 Fall BABYJOB 株式会社　浅野正貴（@mackey0225）

Git 未経験者が GitHub Actions で CI/CD できるようになるまで このセッションについて 【内容】 Git 未経験者が GitHub Actions を用いた CI/CD を実現していく中で 得られた成果や苦労、学び・気づきについてお話します Javaについては、ほとんど登場しないです。。。スミマセン。。。

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 目次 ● 自己紹介 ● 実施前の状態 ○ 構成や改善点 ○ GitHub Actions について ● 実施したこと ● 実施後の状態 ● 実施したうえでの学び・気づき

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 自己紹介 名前: 浅野　正貴 所属: BABY JOB 株式会社（2022-06 入社） 役割: Javaエンジニア Twitter: @mackey0225 GitHub: @mackey0225 経歴: - 前職: カタログ通販会社 社内SE を 8年ほど 趣味: -　2歳の息子と遊ぶこと

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 前提の説明 【前提について】 言語 ： Java フレームワーク ： Spring Boot ビルドツール ： Gradle 環境 ： AWS Elastic Beanstalk 本番環境と検証環境の2環境 リリース周期 ： 基本として1週間 【着手前の状態】 ● テストとビルドまでは自動化済み ○ ビルド後は、人力・手動でデプロイ実施 →今回は検証環境へのデプロイのみを自動化 ○ →テストのみで、静的解析・フォーマッターなどは未適用 ● 私自身が Git / GitHub を使ったチーム開発が初

Git 未経験者が GitHub Actions で CI/CD できるようになるまで GitHub Actions について 概要レベルですが ● GitHub が提供している CI/CD プラットフォーム ● YAML で定義 ● GitHub 上の様々なイベントをトリガーにすることが可能 ○ 手動実行 や スケジュール（cron）も可能 ● 利用料金は ○ パブリックリポジトリは無料（標準ランナー） ○ プライベートリポジトリはプランに応じた月単位の無料枠がある ■ GitHub Free ： 2,000分 ■ GitHub Pro ： 3,000分

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 取り組んだこと 大きくは以下の２つ 1. AWS Elastic Beanstalk へのデプロイ処理の実装 2. 静的解析ツール・コードフォーマッターの選定と適用

Git 未経験者が GitHub Actions で CI/CD できるようになるまで AWS Elastic Beanstalk へのデプロイ実装 【結論】 今回、einaregilsson/beanstalk-deploy を使用した 【選んだ理由】 Elastic Beanstalk を操作する Action で 公式なものは無かった 現状の運用に沿っているもので、利用例が多いものを選んだ （コンテナであれば、docker や AWS が提供している Action はある） 【利用方法】 次ページにて簡単に紹介 【einaregilsson/beanstalk-deploy】 https://github.com/marketplace/actions/beanstalk-deploy https://github.com/einaregilsson/beanstalk-deploy

Git 未経験者が GitHub Actions で CI/CD できるようになるまで Elastic Beanstalk へのデプロイ実装 ＜略：検証環境向けの .war ビルドを実行＞ - name: Build zip uses: gradle/[email protected] with: arguments: | buildZip - name: Deploy to Elastic Beanstalk uses: einaregilsson/beanstalk-deploy@v20 with: aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }} aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} application_name: application_name environment_name: environment_name version_label: ${{ env.VERSION_LABEL_NAME }} region: ap-northeast-1 deployment_package: build/distributions/release.zip ＜略＞

Git 未経験者が GitHub Actions で CI/CD できるようになるまで Elastic Beanstalk へのデプロイ実装 ＜略：検証環境向けの .war ビルドを実行＞ - name: Build zip uses: gradle/[email protected] with: arguments: | buildZip - name: Deploy to Elastic Beanstalk uses: einaregilsson/beanstalk-deploy@v20 with: aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }} aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} application_name: application_name environment_name: environment_name version_label: ${{ env.VERSION_LABEL_NAME }} region: ap-northeast-1 deployment_package: build/distributions/release.zip ＜略＞ 実行前に、デプロイする資源をビルドし Zip化 している。 その際、プロジェクトの build.gradle に定義したタスクを呼び出している。

Git 未経験者が GitHub Actions で CI/CD できるようになるまで Elastic Beanstalk へのデプロイ実装 ＜略：検証環境向けの .war ビルドを実行＞ - name: Build zip uses: gradle/[email protected] with: arguments: | buildZip - name: Deploy to Elastic Beanstalk uses: einaregilsson/beanstalk-deploy@v20 with: aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }} aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} application_name: application_name environment_name: environment_name version_label: ${{ env.VERSION_LABEL_NAME }} region: ap-northeast-1 deployment_package: build/distributions/release.zip ＜略＞ 先程の「beanstalk-deploy」を呼び出している。 また、AWS にアクセスするためのクレデンシャルは GitHub の「Settings > Secrets > Actions」で管理

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析ツール・コードフォーマッターの適用 【結論】 ● 静的解析ツール ： SpotBugs、　PMD ● コードフォーマッター ： Spotless 【選んだ理由】 Gradle プラグインがサポートされているかどうかで選定 ひとまずのスモールスタートを行うため、代表的なツールを導入 【利用方法】 次ページにて簡単に紹介 【SpotBugs】 https://spotbugs.github.io/ 【PMD】 https://pmd.github.io/ 【Spotless】 https://github.com/diffplug/spotless

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【静的解析】 ＜略＞ - name: PmdMain run: ./gradlew pmdMain - name: PmdTest run: ./gradlew pmdTest - name: SpotbugsMain run: ./gradlew spotbugsMain - name: SpotbugsTest run: ./gradlew spotbugsTest

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【静的解析】 ＜略＞ - name: PmdMain run: ./gradlew pmdMain - name: PmdTest run: ./gradlew pmdTest - name: SpotbugsMain run: ./gradlew spotbugsMain - name: SpotbugsTest run: ./gradlew spotbugsTest build.gradle に定義した各ツールのタスクを Gradle Wrapper スクリプトで呼び出す。 ※各ツールの Gradle の設定については割愛。

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【静的解析】 ＜略＞ - name: PmdMain run: ./gradlew pmdMain - name: PmdTest run: ./gradlew pmdTest - name: SpotbugsMain run: ./gradlew spotbugsMain - name: SpotbugsTest run: ./gradlew spotbugsTest 【参考情報】 PMD は GitHub Action に公式の Action があるので、手軽に利用することも可能 (各開発者端末でも同じルールセットでチェックさせたかったため、今回は使用していない) 【GitHub Action for PMD】 https://github.com/marketplace/actions/pmd

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【コードフォーマッター】 ＜略＞ - name: Spotless Apply run: | ./gradlew spotlessApply - name: Check for modified files in Spotless id: git-check run: echo "MODIFIED_IN_SPOTLESS=$(if git diff-index --quiet HEAD --; then echo "false"; else echo "true"; fi)" >> $GITHUB_ENV - name: Push in Modified File with Spotless if: env.MODIFIED_IN_SPOTLESS == 'true' run: | git config user.name github-actions[bot] git config user.email 41898282+github-actions[bot]@users.noreply.github.com git status git add . git commit -m "Formatted Java source code." git push origin HEAD

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【コードフォーマッター】 ＜略＞ - name: Spotless Apply run: | ./gradlew spotlessApply - name: Check for modified files in Spotless id: git-check run: echo "MODIFIED_IN_SPOTLESS=$(if git diff-index --quiet HEAD --; then echo "false"; else echo "true"; fi)" >> $GITHUB_ENV - name: Push in Modified File with Spotless if: env.MODIFIED_IN_SPOTLESS == 'true' run: | git config user.name github-actions[bot] git config user.email 41898282+github-actions[bot]@users.noreply.github.com git status git add . git commit -m "Formatted Java source code." git push origin HEAD build.gradle に定義した Spotless のタスクを呼び出す

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【コードフォーマッター】 ＜略＞ - name: Spotless Apply run: | ./gradlew spotlessApply - name: Check for modified files in Spotless id: git-check run: echo "MODIFIED_IN_SPOTLESS=$(if git diff-index --quiet HEAD --; then echo "false"; else echo "true"; fi)" >> $GITHUB_ENV - name: Push in Modified File with Spotless if: env.MODIFIED_IN_SPOTLESS == 'true' run: | git config user.name github-actions[bot] git config user.email 41898282+github-actions[bot]@users.noreply.github.com git status git add . git commit -m "Formatted Java source code." git push origin HEAD Spotless を適用した結果をプッシュするため、 差分の有無を $GITHUB_ENV に変数 MODIFIED_IN_SPOTLESS を追加し設定する

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 静的解析・コードフォーマッターの適用 【コードフォーマッター】 ＜略＞ - name: Spotless Apply run: | ./gradlew spotlessApply - name: Check for modified files in Spotless id: git-check run: echo "MODIFIED_IN_SPOTLESS=$(if git diff-index --quiet HEAD --; then echo "false"; else echo "true"; fi)" >> $GITHUB_ENV - name: Push in Modified File with Spotless if: env.MODIFIED_IN_SPOTLESS == 'true' run: | git config user.name github-actions[bot] git config user.email 41898282+github-actions[bot]@users.noreply.github.com git status git add . git commit -m "Formatted Java source code." git push origin HEAD 差分があれば、プッシュする プッシュ時は今回 GitHub Action でコミットしたように見せるため、 ユーザー情報を下記のように設定した

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 効果 【デプロイ自動化】 ● 週次でのデプロイ作業 ○ 作業工数削減 週あたり 30分 〜 1時間 ● 必要時の検証環境利用 ○ 属人化解消 デザイナーメンバでも検証環境にデプロイが可能 【静的解析・コードフォーマッター】 ● 静的解析結果の出力 ○ 現状の課題や懸念点の創出 ● コードの整形 ○ 不要な import の削除 ○ import の順番の統一化

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 実施していく中での気付き・学び 大きくは以下の４点 ● Git/GitHub の学習 ● 実装・テストする上での注意 ● レビュー時の観点 ● 運用開始に向けて開発組織への周知

Git 未経験者が GitHub Actions で CI/CD できるようになるまで Git/GitHub の学習 【結論】 「習うより慣れろ」 【背景・理由】 ● すべての機能を理解する必要はない ○ 本当に必要なものは案外少ない ● 開発からリリースまでの1サイクル で必要な機能を最低限押さえる ○ 組織やプロダクト ごとに ブランチ戦略 や リリース手順 が違う ○ 目的に立ち返ると「CI/CD の実現」 ○ もし Git 未導入であれば ブランチ戦略の検討 から始める

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 実装・テスト 【結論①】 本番環境 や 実開発作業に影響を与えないよう、 「ダミー の リポジトリ・ブランチ を作成」 する 【背景・理由】 ● 開発への影響を与えず、自由に触れる環境が必要 ○ 稼働中のワークフローが存在していた ○ 意図せず動作した際のリスクを下げたかった ○ 一方、いろんなパターンで挙動の確認は必要だった

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 実装・テスト 【結論②】 月次の利用枠を枯渇しないよう、 「不要な JOB はコメントアウト」 して対応 【背景・理由】 ● 上限に達し、開発で使用しているワークフローが実行できなくなった ○ その際は必要な分を課金した 【参考】 課金は処理のトータル時間ではなく、ジョブ単位で切り上げられる →仮に 1ワークフロー で 1秒のジョブ を 50回 呼ぶ →ワークフローは1分以内に終了 →利用としては 1分 ではなく 50分 となる

Git 未経験者が GitHub Actions で CI/CD できるようになるまで レビュー 【結論】 最低限の観点として ● セキュリティ上の問題の有無 ● クレデンシャル情報はどのように保持しているか など ● 使用した Action の妥当性 ● Action が活きているか（定期的にバージョンアップの有無） ● 適切なバージョンを指定しているか など 【背景・理由】 ● 事故につながらない状態であれば良しとする ● 時間の経過とともにゴールが変わることもあるので BEST を追い求めない ○ 誰にとっても保守しやすいかどうかのほうが重要

Git 未経験者が GitHub Actions で CI/CD できるようになるまで 運用開始に向けて開発組織への周知 【結論】 ● 「細かく」「事前に」「何度も」を心がける ● 各メンバーの作業や業務がどう変わるかを意識する 【背景・理由】 ● 大前提として 開発体験の劣化 は避ける ○ 適用前に実環境でテストを行うため利用調整があった ○ 適用後の運用がどう変わるかまで考える必要がある

Git 未経験者が GitHub Actions で CI/CD できるようになるまで まとめ ● GitやGitHubの習熟は習うより慣れろ ○ チームで必要な最低限必要な機能は限られている（はず） ● ブランチ戦略とその運用が重要 ○ トリガーの条件の決定に必要となる ○ チームへの適用時の影響範囲確認が容易になる ● 挙動の確認はダミー(ブランチ・リポジトリ)を作って実施 ○ 本番への影響を避けるため、ダミーで壁打ち ■ 壁打ちする際は、利用枠の枯渇に注意 ● 稼働開始に際してはメンバとの緊密なコミュニケーションが必要 ○ あくまでもチームの開発体験向上が目的 ○ 無理に開始してコケると、次の一手が出しづらくなる

Git 未経験者が GitHub Actions で CI/CD できるようになるまで おしまい 28