新しく参画したプロジェクトで導入したブランチ運用とCI・CDの紹介 #Rails

最近会社で新しいプロジェクトにSREとしてジョインし、ブランチ運用やCI・CDを導入したので忘備録がてら紹介。

参画したプロジェクトとかに関して

今回ジョインしたのはサーバーサイドがRails、インフラがGCP、フロントはVueのプロジェクトです。自分がジョインした時点でCI・CDの仕組みはほぼ存在せず、ブランチ運用も特に定まってない状態でした。

CIの導入

ここは至って普通なので軽く済ませますが、Github ActionsでRspecによる自動テストとrubocopによるコードチェックをPR作成時に走らせるようにしました。rubocopに関しては以下のActionsを使えばそれなりにリッチな仕組みが簡単に実現できるのでとても便利ですね。
https://github.com/reviewdog/action-rubocop

ブランチ運用

基本はGitflow

基本的にはGitflowに近い運用を採用しました。ただし、厳密なGitflowは今回のチームでは大げさに思えたので一部簡略化してます。使うのは以下のブランチです。

main
develop
feature/xxx
hotfix/xxx
qa

releaseブランチは使わない

Gitflowではreleaseブランチを挟んでmainへのマージを行いますが、ここは省略してdevelopブランチを直接mainにマージする運用にしました。もう少し具体的に言うとdevelopからmainに向けたリリース用のPRを作成し、そのPRをマージすることでmainが反映されます。

このリリース用PRの作成には、git-pr-releaseと言うOSSを使います。これをgithub actionsで動かすことで、以下のようにdevelopとmainの差分がまとまったPRがdevelopブランチ更新時に自動で作成されます。もちろんdevelopブランチが更新されるごとにPRも自動で更新されます。

検証環境デプロイ用のQAブランチ

後述する自動デプロイ(CD)の仕組みを使って検証環境にデプロイするために使うブランチです。featureブランチからこのqaブランチにチェックアウトしてgithubにpushすることで検証環境にデプロイされます。

自動デプロイ(CD)に関して

CloudBuildで各ブランチをTrigger

CDは全てCloudBuildで行なっています。以下のように各ブランチが動作環境に紐づいており、ブランチが更新されるとCloudBuildのTriggerが検知してデプロイが始まります。

develop -> staging環境
main -> 本番環境
qa -> 検証環境

docker buildにはkanikoを使う

RailsのAPIはCloudRunで動かすのですが、CloudRunに上げるDocker imageのbuildにはkanikoを使いました。
https://cloud.google.com/build/docs/optimize-builds/kaniko-cache?hl=ja
これを使えばとても簡単にdocker buildのキャッシュが利用できます。

steps:
  - name: gcr.io/kaniko-project/executor:latest
    args:
      - --destination=${_IMAGE_NAME}
      - --cache=true
      - --cache-ttl=120h

また、この記述だけでArtifact Registryへのpushまで行ってくれます。

DBのスキーマ更新はCloudRun Jobsで

Railsだと多くの場合DBのスキーマ更新のためにmigrateを行うことなると思いますが、この処理はCloudRun Jobsで実行しています。

- name: "gcr.io/cloud-builders/gcloud"
  args:
    [
      "beta",
      "run",
      "jobs",
      "update",
      "migrate",
      "--project=${PROJECT_ID}",
      "--region=asia-northeast1",
      "--image=${_IMAGE_NAME}",
    ]
- name: "gcr.io/cloud-builders/gcloud"
  args:
    [
      "beta",
      "run",
      "jobs",
      "execute",
      "migrate",
      "--project=${PROJECT_ID}",
      "--region=asia-northeast1",
      "--wait",
    ]

1つ目のstepでjobのimageを更新し、2つ目のstepでjobを実行しています。

まとめ

今回ジョインしたのは比較的小さいチームだったため、シンプルさを優先してCI・CDの仕組みを導入しました。今後チームが大きくなってきたら本格的なBranch環境の自動デプロイの仕組みや、slack opsも導入していきたいです。