CircleCIを用いてテストからリリースまでを省力化する
株式会社ココナラ / takumi.yoshikawa
チームリーダー / インフラエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
利用プラン | 利用機能 | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
---|---|---|---|---|
カスタムプラン | ワークフロー、Insights | 51名〜100名 | 2018年 | B to C |
利用プラン | カスタムプラン |
---|---|
利用機能 | ワークフロー、Insights |
ツールの利用規模 | 51名〜100名 |
ツールの利用開始時期 | 2018年 |
事業形態 | B to C |
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
エンジニアが本番環境へリリースを行うにあたり
- 開発者のローカルで手動でテストを実行する
- PRのレビューを受けてマージする
- 専用のデプロイサーバへログイン
- サーバ内で特定のコマンドを実行して本番サーバへリリース
という手順を実施していました。この状態では以下が大きく問題となります。
- 開発者がほんとうにテストを実行したのか確認しづらい、またローカル環境差異があり開発者によってテスト結果が異なる
- 実施コマンドが手動であるため、誤ったコマンドを実行してしまう
- 1回のリリースにおける手動作業コストが高く、リリースに対するデモチベーションにつながる
どのような状態を目指していたか
いわゆるGitOpsな状態で、Gitの特定ブランチにpush(PRをマージ)することで、システマチックにリリースがなされる状態を目指しています。
比較検討したサービス
- Jenkins
- AWS Codeシリーズ
比較した軸
- 設定が比較的容易で、インフラまわりに強くなくても記載ができること
- CI/CDをするためのサーバを管理する必要がないこと
選定理由
Githubとリポジトリを数クリックで連携することができ、簡単な設定ファイルをコミットするだけで、ワークフローが動き出すという、導入の手軽さです。
導入の成果
先にあげた課題をほとんど解消することができています。 開発者のフローとしては
- 変更をpush、CIで実行結果を見てレビューに出す
- リリースしたいタイミングで特定ブランチへマージ
というごくシンプルなものになりました。より一層やるべきことへの注力ができる状態となっています。
導入時の苦労・悩み
ワークフローをどのように組むのかという設計です。
導入に向けた社内への説明
上長・チームへの説明
先にあげた課題を解消しないとエンジニア離れが起こってしまう、開発体験を改善することで長期的な目線で導入メリットを説明しました。
開発者向けには、あるリポジトリに対して簡単なフローをまず導入し、どれだけ作業負担が減るのかを実際に体験してもらいました。
活用方法
ほとんどのリポジトリでCircleCIが稼働するようになっています。 例えばfeatureブランチにpushされたら単体テストが実行され、mainブランチにマージされたらproduction環境にリリースがされる、といったワークフロー設定を組んでいます。
よく使う機能
- Insights機能
- CircleCI Orbs
ツールの良い点
- Insights機能というものがあり、実行時間や成功率の推移が可視化されている
- CIツールの先駆けといってもよく、ナレッジが豊富に存在する
ツールの課題点
共通化がなかなか難易度が高い。同一リポジトリ内のコマンドレベルであれば簡単に記載できるが、複数リポジトリで共通処理を行いたい場合に自前のOrbを作成する必要がある
ツールを検討されている方へ
CI系のツールは多少慣れが必要な部分もありますが、一度組んでしまえば開発者の体験向上に確実につなげることができます。 近年はGithubActionsやCodeシリーズの進化などがみられますが、CircleCIに存在するInsights機能というものが強力で、日々の状況が可視化されているため、分析→対処の流れを踏みやすいです。
株式会社ココナラ / takumi.yoshikawa
チームリーダー / インフラエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名
よく見られているレビュー
株式会社ココナラ / takumi.yoshikawa
チームリーダー / インフラエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名