Git 未経験者 が GitHub Actions で CICD できるようになるまで / 20221127-JJUGCCC-2022-Fall-Git-beginner-built-CICD-pipeline-with-GitHubActions

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

8. 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
   

   View Slide

9. Git 未経験者が GitHub Actions で CI/CD できるようになるまで
   Elastic Beanstalk へのデプロイ実装
   ＜略：検証環境向けの .war ビルドを実行＞
   - name: Build zip
   uses: gradle/gradle-build-action@v2.3.3
   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
   ＜略＞
   

   View Slide

10. Git 未経験者が GitHub Actions で CI/CD できるようになるまで
    Elastic Beanstalk へのデプロイ実装
    ＜略：検証環境向けの .war ビルドを実行＞
    - name: Build zip
    uses: gradle/gradle-build-action@v2.3.3
    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 に定義したタスクを呼び出している。
    

    View Slide

11. Git 未経験者が GitHub Actions で CI/CD できるようになるまで
    Elastic Beanstalk へのデプロイ実装
    ＜略：検証環境向けの .war ビルドを実行＞
    - name: Build zip
    uses: gradle/gradle-build-action@v2.3.3
    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」で管理
    

    View Slide

12. 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
    

    View Slide

13. 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
    

    View Slide

14. 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 の設定については割愛。
    

    View Slide

15. 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
    

    View Slide

16. 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
    

    View Slide

17. 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 のタスクを呼び出す
    

    View Slide

18. 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 を追加し設定する
    

    View Slide

19. 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 でコミットしたように見せるため、
    ユーザー情報を下記のように設定した
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide