Upgrade to Pro — share decks privately, control downloads, hide ads and more …

受託開発でGitLab CI を活用していく

受託開発でGitLab CI を活用していく

主要CIツール3選!導入する前に知りたかった!各ツールのアピールポイント!
で発表した資料です

https://trident-qa.connpass.com/event/310009/

中川 聡也

March 27, 2024
Tweet

More Decks by 中川 聡也

Other Decks in Programming

Transcript

  1. サーバーレス:Serverless/Cloudflare/Momento /TiUG ゲーム‧アプリ:IGDA Japan / Japan Android Group Cloud Native:OCha

    Cafe! 他も顔出してます。どこかであったら声かけてください! まずは⾃⼰紹介 @xiombatsg
 2 何をしている⼈? 商品開発をしているお客様を技術⾯でご⽀援 チーム構築のご⽀援(Platform Engineer,SRE…) どんなジャンル? ゲーム/Webサービス/CG/組み込み/etc… どんなコミュニティに顔を出している? Cloudflare UG 東京, TiUGの運営に参画 中川 聡也 Satoya Nakagawa https://zenn.dev/nakagawa_satoya
  2. 【宣伝】Cloudflare Meet-up Tokyo Vol.4 4/1 から 始まるDeveloper week のre:Cap イベントです。

    毎年⾯⽩いアップデート内容があります。 今回も期待⼤です!是⾮参加お願いします! https://cfm-cts.connpass.com/event/313277/
  3. なぜ CI/CDを使うと良いの? CIが統合のトラブルを軽減 問題が⼩さなうちに解消し、複雑化させない CIでチームの開発を加速させる 開発者間の信頼を⾼め、ボトルネックを減らす CIがエラーを素早く検出 記憶に残っているうちにエラーを修正できる CDはすべての変更をリリース可能にする 各リリースのリスクが低下し、予測可能なものになる

    CDは価値を素早く、より多く提供する お客様の関⼼事を素早くフィードバック 02 01 05 04 03 CI/CDは、全ての部⾨間のコラボレーションを促進し、コードの作成と管理を容易にするだけで なく、次のような具体的なメリットがあります。
  4. Deploy & Operate Plan & Create Integrate & Verify Monitor

    & Improve 1つのワークフローで開発者、セキュリティ、各運⽤チームを統合
  5. 16 Built from the ground up as a single application

    200% faster DevSecOps lifecycle Secure Manage Plan Create Verify Package Release Configure Monitor Defend ✔ Single Conversation ✔ Single Data Store ✔ Single Permission Model ✔ Single Interface ✔ Governance & Security ✔ Team Collaboration ✔ Lifecycle Analytics Developers Product Management Quality Assurance Security Operations Infrastructure Collaborate Automate
  6. 19 DevOpsの基礎固め コミュニティサポート DevOpsの高度化 迅速なサポート体制 無償版 究極のDevOps-DevSecOps 迅速なサポート体制 プレミアム ウルティメイト

    コードレビューの迅速化 高度なCD/CD 企業版アジャイル管理 リリースのコントロール 自社運用の冗長性を強化 コードレビューの迅速化 高度なCD/CD 企業版アジャイル管理 リリースのコントロール 自社運用の冗長性を強化 セキュリティテスト高度化 セキュリティリスク管理 コンプライアンス ポートフォリオ管理 バリューストリーム管理 効率性と コントロール を強化 セキュリティ/コンプラ イアンス対策/計画管理 を強化
  7. GitLabパイプライングラフ • パイプラインで達成したいことを定義    ランナーによる実⾏    ステージでの実⾏ • ジョブを実⾏するタイミングと⽅法を定義  コードをコンパイルした後にテストを実⾏するステージがあります • 各ステージのジョブが並⾏して実⾏される

       ステージ内のすべてのジョブが成功した場合、パイプラインは次のステージに移動します    ステージ内のジョブが⼀つでも失敗すると、次のステージは(通常は)実⾏されません
  8. Shared Runner と Specifi Runner インスタンス環境 Specific Runner インスタンスにインストールして使⽤するRunner 物理マシンやジョブの実⾏が⻑い時などに利⽤

    Shared RunnerではできないDockerを使わないRunner もある SaaS環境 Shared Runner GitLab 社が ⽤意しているSaaS上で動くRunner 物理マシンを⽤意する必要がない コンピュート時間課⾦で利⽤可能(Free Tierあり) テストなどの⽐較的反復するJobはShared Runner 実⾏時間が⻑い、物理マシンにデプロイするなどはSpecific Runner の使い⽅が個⼈的におすすめです。
  9. .gitlab-ci.ymlを配置する ① DockerImageを指定(Docker HubにあるものでOK) ②パイプラインステージ名を定義(名前は⾃由) ③ジョブを定義 - stage は実⾏するstageを指定する -

    script は実⾏したいshellコマンド - artifacts はビルド⽣成物を定義(後ほどダウンロード できるようになる) ① ② ③ docker compose に慣れていると似たような記法なので 導⼊のハードルはそれほどありませんでした
  10. CI Runner を配置 試すだけであれば Shared Runner が簡単で良いです (free版でも400分枠があります) 弊社では基本 Shared

    Runner を使⽤し、特定環境のデプロイ時に のみRunnerをインストールしています。
  11. GitLab CLI はおすすめ インストール手順:https://gitlab.com/gitlab-org/cli/-/blob/main/docs/installation_options.md GitLab CLI のインストールをおすすめしてます。 <できること> 1. CI

    Lint (CIスクリプトの構⽂チェックができる) 2. CI Trace ローカルでCI実⾏ログが⾒れる) 3. CI View (CI実⾏状態をCLIで可視化) 4. CI Trigger (CI をマニュアル実⾏) などなど
  12. GitLab CI ちょっと残念なこと 1. ⾮エンジニアに触らせるには、UIが残念 a. エンジニアがメインで触るチームなら問題ない b. ダッシュボードを別で作るのもあり 2.

    Jobを分割して実⾏をすると、毎Job DockerImageのダウン ロードされて、遅い a. 実⾏時間が短いJobはまとめる b. Specific Runner にする(Shell Executer があるのでこちらは 早い)
  13. GitLab CI ちょっと残念なこと 3. ⽇本語ドキュメントがない a. クリエーションラインさんが⽇本語翻訳しています。そちら を⾒ましょう 4. Jobを分割して実⾏をすると、毎Job

    DockerImageの ダウンロードされて、遅い b. 実⾏時間が短いJobはまとめる c. Specific Runner にする(Shell Executer があるのでこちらは 早い)
  14. 弊社環境(GitLab.com) お客様環境 ケース1 レビュサーバ環境へのデプロイ インスタンス環境(EC2など) コンテナ環境(ECSなど) CI Trigger テスト/ビルド Docker Image

    ビルド リポジトリ GitLab Project Shared Runner Container Registry お客様環境でデプロイ リポジトリミラー Specific Runner デプロイ Runner をインスタンスにインストールしておいて、 デプロイに必要なコマンドの実⾏などを⾏っています。 git からの pull,マイグレーションなど ビルドした artifact の取得など CI のパイプライントリガで ECS環境にデプロイします Container Registry で作ったイメージをデプロイします デプロイ
  15. 弊社環境(GitLab.com) お客様環境 ケース2 Webフロントのデプロイ ドキュメント環境(GitLab Pages) Webフロント環境確認(Cloudflare Pages) リポジトリ GitLab Project

    お客様環境でデプロイ リポジトリミラー Specific Runner CI Trigger テスト/ビルド Shared Runner デプロイ レビュブランチ毎にデプロイ 本番サイトもCloudflare 上であれば同じ構成にしています Pages Job OpenAPI や Docusaurus をデプロイ
  16. 弊社環境(GitLab.com) ケース3 オンプレ環境へのデプロイ 本番環境(Windows Serverなど) GitLab Project Specific Runner CI Trigger

    テスト/ビルド Shared Runner デプロイ Runner をインスタンスにインストールしておいて、 デプロイに必要なコマンドの実⾏などを⾏っています。 git からの pull,マイグレーションなど ビルドした artifact の取得など Pull型のRunner特性を活かして、 お客様のオンプレサーバーに Runner をインストールし、 Job を登録してデプロイ
  17. 弊社環境(GitLab.com) ケース4 アプリのビルド ゲームビルドPC環境 GitLab Project Specific Runner CI Trigger テスト

    Shared Runner ビルド ビルド時間が⻑いものは 専⽤のビルドPCを⽤意してビルド モバイルアプリ ビルドRunner Shared Runner GitLab で Android/iOS ビルド向け に Fastlane を使ったビルド環境が 提供されている Windows アプリビルド Runner Shared Runner GitLab で Windowsビルド環境が 提供されている
  18. こういうこともやってます テスト用DBとの接続はサービスの機能を使用 • GitLab CI には Docker Executer を使⽤してジョブ中に使⽤できる DB

    を構築することができます。 • 弊社では MySQL が多いですが、 PostgresSQL や Redis のサービスも あります
  19. 今後個人的に期待すること 1. CIカタログが GitHub Marketplace のようになる 2. 各社のCIスクリプトノウハウが共有される世界 3. IDE

    Extenstion にCI 機能を追加される 4. CI トリガーに Epicやissue,Wikiなど プロジェクト以外のもので もトリガーできるようになる a. 現在はWebHookを使っていく必要がある