狠狠撸

2023/10/17 リンカーズ株式会社鈴木竜太
GitLab + JIRA から
GitHub + Zenhub に乗り換えて
チーム運用を改善しつつある話
移植を通じた CircleCI の知見

GitLab + JIRA から
GitHub + Zenhub に乗り換えて
時間足りませんでした?

GitLab から
GitHub + CircleCI に乗り換えて

自己紹介
? 鈴木竜太
? 2018/6/1 入社
(6年目)
? Linkers for BANK (LFB)
? バックエンド (Ruby) 担当
? 最近はVue.jsも少々
? スイカゲーム
休日はだいたい音楽イベントへ

? 移行决断の背景
? CI移植作業
? 実行環境構築
? GitHub Actions
? GitHub Packages
? ジョブ実行: CircleCI
? 移行後の現状
? ブランチ運用
? 予算?実績管理
Agenda

? 2022/6/1 LFB新マネージャーKさん就任
? 「それ自前でやらなくてよくない？」
? テストの並列実行 (CIで実装)
? ライブラリの定期アップデート (CIで実装)
? コードレビュー運用
? セルフホストGitLabサーバーのメンテナンス
プロジェクト体制の見直し

? 決断: GitHubと既存ツール?機能を使う
? テストの並列実行 → CircleCI (parallelism)
? ライブラリの定期アップデート → Dependabot
? コードレビュー運用 → CODEOWNERS
? リポジトリの移行自体はほぼ作業なし
? 最大の障壁: GitLab CI
? それまでのテスト, Lintの品質を維持
この発表: CIをいかに再構築し、障壁を乗り越えたか
移行方針と障壁

構成図
gitlab-linkers.com
bank/docker-bank-ruby GitLab Container Registry
docker build
docker push
docker-bank-ruby
git push
git push
bank/hokug
docker pull
bundle install
mysql
yarn
...
bundle exec rspec
yarn test
yarn stylelint
go test
bundle exec rubocop
...

? Docker image
? プロダクト本体 (Rails app) とは独立したリポジトリ
? 主にRSpec, lint系のチェックを動かすために構築
? ruby (rbenv, bundler)
? node (yarn)
? MySQL client
? MinIO client
? ファイルサーバー (AWS S3 API) をローカルで再現
? その他補助ツール
? Chrome, ImageMagick, Nokogiri関係 (libxml2 libxslt
libxml2-devel libxslt-devel), sassc, etc.
旧環境: docker-bank-ruby

- test:rspec
- rspec time aggregate (※補足1)
- yarn test
- lint:rubocop
- lint:brakeman
- lint:frontend
- yarn eslint
- yarn stylelint
- yarn typecheck
- continuous_bundle_update (※補足2)
- etc.
実行していたジョブ (抜粋)

? rspec time aggregate (補足1)
? RSpec並列化実行時の各プロセスの実行時間平準化
? ファイルごとの実行時間を記録しAWS S3に保存
? 次回実行時に記録を元にファイルを割り当て
? .rake スクリプトを実装し、CIから bundle exec rake
テストの並列実行

? continuous_bundle_update (補足2)
? 定期的にGemのバージョンを更新するためのジョブ
? gitlabci-bundle-update-mr Gemを利用
? https://gitlab.com/sue445/gitlabci-bundle-update-mr
? GitLab CIの定期実行 (毎月1回) に登録
ライブラリの定期アップデート
gem install --no-doc gitlabci-bundle-update-mr
gitlabci-bundle-update-mr --user="GitLab CI"
--email="gitlabci@example.com" --labels="bundle update"

? コードレビュー運用
? ラベルによるステータス管理 (本来の使い方でない)
? タイトルに "WIP:" とか "Draft:" が必要
? 「未レビューならマージをブロック」無し (Premium限定)
? ググラビリティ
? GitHubについての記事を見つけて読み替え
? セルフホストサーバーのメンテナンス
その他、しんどかった部分

- 環境構築
- docker-bank-ruby
- Push trigger job
- test:rspec
- rspec time aggregate
- lint:rubocop
- lint:frontend
- etc.
- 定期実行Job
- continuous_bundle_update
移行先

? GitLab Container Registry で構築していたDocker Image
CircleCIにも必要なので移植
? Ruby, YARN → ghcr.io/linkers-corp/ci-ruby (自前)
? MySQL → cimg/mysql:5.7 (CircleCI コンビニエンスイメージ)
? MinIO → minio/minio (Docker Hub)
実行環境構築

? Docker Imageをpush/pullできる仕組みがGitHubにも存在
? ghcr.io (旧称 "GitHub Container Registry" の名残)
? LFBでの運用
? docker-bank-ruby/Docker
fi
le → lfb/ci-ruby/Docker
fi
le
? 中身ほぼ変わらず流用
? リポジトリを統合できた
? 関連するファイルへのcommit, pushを検知して
GitHub Actionsにより ghcr.io に docker push
GitHub Packages

lfb/
" .circleci/
" config.yml # test, lint 実行
" .github/
" workflows/
" build-ci-ruby-main.yml
" containers/
" ci-ruby/
" Dockerfile
" app/
" spec/
" ...
ディレクトリ構成
docker build

? work
fl
ows
? build
? rspec
? jest
? lint
? # etc.
? executors
? rails-executor
? ruby
? elasticsearch
? mysql
? minio
.circleci/config.yml の概要
? commands
? bundle install
? db setup
? yarn / webpack
? Slack notify
? jobs
? build
? rspec
? jest
? lint
? # etc.

Sample: jobs.rspec 全体
jobs:
rspec:
executor: rails-executor
parallelism: <<pipeline.parameters.parallelism>>
resource_class: <<pipeline.parameters.resource-class>>
steps:
- prepare
- run:
name: bundle exec rspec
command: |
mkdir ~/rspec
TESTFILES=$(circleci tests glob "<<pipeline.parameters.rspec-path>>")
echo $TESTFILES | circleci tests run --verbose --split-by=timings --command="xargs
bundle exec rspec
--format RspecJunitFormatter -o ~/rspec/rspec.xml
--format json --out ~/rspec/rspec-${CIRCLE_NODE_INDEX}.json
if [ -s coverage/.resultset.json ]; then
mv coverage/.resultset.json "coverage/.resultset-${CIRCLE_NODE_INDEX}.json"
else
circleci-agent step halt
fi
# 略

? 文法が違うということが把握いただければ
参考: GitLab 颁滨での実装

? 実行環境構築: 以前利用していたDocker Imageを引き継ぎ
? リポジトリは統合
? GitHub PackagesにContainerを保存
? GitHub Actions: docker push
? CircleCI: 最初から書き直し
? GitLab CIと文法が違う?環境構築も違う
? Parallelismを設定: 60並列
CI移植結果まとめ

GHCR/CircleCI 環境構成
Actions
ci-ruby
git push
push 検知
build
front-build
rspec
artifacts
docker build
docker push
GitHub
push 検知
app.circleci.com
実
docker pull
ghcr.io
checkout

? 実行時間を考慮してテストを並列実行できる
? 旧CIでは自前で実装
? rspec?time?aggregate
? CircleCIに移行せず
? .rake ファイルも廃止
Parallelism
# .circleci/config.yml
parameters:
parallelism:
default: 60
type: integer

? 既存の検証観点は維持
? 並列数拡大による実行時間削減
? 平均 GitLab CI: 00:30:07
? → 新CI: 00:20:01
Parallelism の効果

? 旧 gitlabci-bundle-update-mr
? まさにDependabotの機能と
判断され、置き換え
? 設定ファイルの実装
? 実行頻度
? チェック対象設定
? package-ecosystem
? 自動でPull Request作成
Dependabot
version: 2
updates:
- package-ecosystem: 'github-actions'
directory: '/'
schedule:
interval: 'weekly'
day: 'monday'
time: '09:00'
timezone: 'Asia/Tokyo'
- package-ecosystem: 'npm'
directory: '/'
schedule:
interval: 'weekly'
day: 'monday'
time: '09:00'
labels:
- 'dependencies'
- 'Frontend'
- package-ecosystem: 'bundler'
directory: '/'
schedule:
interval: 'weekly'
day: 'monday'
time: '09:00'
labels:
- 'dependencies'
- 'Backend'

? レビュアーを指定し、レビューの承認フローを構築
? バックエンド、フロントエンドグループを定義し、
ファイル種類によってレビュアーを割り当て
CODEOWNERS
# Other files are owned by backend team
* @linkers-corp/lfb-backend
# Frontend files are owned by frontend team
# Order is important; the last matching pattern takes the most precedence
/app/javascript/ @linkers-corp/lfb-frontend
/config/locales/javascript.ja.yml @linkers-corp/lfb-frontend
/__mocks__/ @linkers-corp/lfb-frontend
/__tests__/ @linkers-corp/lfb-frontend
.npmrc @linkers-corp/lfb-frontend
package.json @linkers-corp/lfb-frontend
# etc.
# Auto-generated routing files by JsRoutes
/app/javascript/packs/utility/routes_api_common.js @linkers-corp/lfb-backend
/app/javascript/packs/utility/routes_api_banker.js @linkers-corp/lfb-backend
/app/javascript/packs/utility/routes_api_customer.js @linkers-corp/lfb-backend

? Draft status
? CODEOWNERS / Protect branch
? JS, vue, node関係のファイルはフロントエンドチーム
? それ以外のファイルはバックエンドチーム
? 「レビューが通るまでマージ不可」を実現 (念願！)
コードレビュー運用

? 巨大なCIを最初から書き直すという珍しい経験
? 時には開発環境の根本的な見直しも必要
? 既存の利用できるツールは使っていくべき
? GitHub Actions / CircleCIに詳しくなれた
? 周辺技術も (GitHub Packages, CODEOWNERS)
? 予算関係も実は大変だった
? ツールの利用料
? 移行作業自体の開発工数

补足?ディレクターズカット

? そもそもなぜGitLabを使っていた？
? 「日本国内にデータを保存しなければならない」
という金融庁の指針
? ソースコードはデータ自体ではないという解釈
? DBはAWS東京リージョンを利用
補足

実行環境ビルド用 GitHub Actions
name: Build Ruby and binary container for CI with `latest` tag
on:
push:
branches:
- develop
paths:
- containers/ci-ruby/**
- .github/workflows/build-ci-ruby-main.yml
jobs:
build-ci-ruby-main:
runs-on: ubuntu-latest
env:
IMAGE_NAME: ci-ruby
steps:
- name: Checkout
uses: actions/checkout@v2
# To Be Continued...
# ← Actionsが起動する条件

CircleCI 用 GitHub Actions
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Set up QEMU
uses: docker/setup-qemu-action@v2 # 補足1
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v1 # 補足2
- name: Login to Github Container Registry
uses: docker/login-action@v1
with:
registry: ghcr.io
username: ${{ secrets.GHCR_USER }}
password: ${{ secrets.GHCR_PAT }}
- name: Build and push
uses: docker/build-push-action@v2
with:
context: ${{ github.workspace }}/containers/ci-ruby
platforms: linux/amd64
push: true
tags: |
ghcr.io/${{ github.repository_owner }}/${{ env.IMAGE_NAME }}:latest
ghcr.io/${{ github.repository_owner }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

? 公式もしくは有志が再利用可能なActionを公開?共有
? 一般ユーザーは少ない手順で再利用可能
? Docker build / push に利用
? docker/setup-qemu-action
? docker/setup-buildx-action
? docker/login-action
? docker/build-push-action
Composite Action

? 補足1: docker/setup-qemu-action@v2
? QEMU: OSSプロセッサエミュレータ (Q EMU)
? ビルド対象のQEMU仮想アーキテクチャを取得
(arm, amd64, ...)
? 補足2: docker/setup-buildx-action@v1
? ビルドコマンドの拡張
? QEMUと合わせてマルチプラットフォーム対応コンテナをビルド
GitHub Actions 補足

狠狠撸

GitLab から GitHub + CircleCI に乗り換えてチーム運用を改善しつつある話

Recommended

More Related Content

Similar to GitLab から GitHub + CircleCI に乗り換えてチーム運用を改善しつつある話 (20)

More from R S (6)

GitLab から GitHub + CircleCI に乗り換えてチーム運用を改善しつつある話