どうも、Kohei(@koheinishino_)です。
今回はCircleCIの使い方と注意点について解説します。
CircleCI(サークルシーアイ)とは、CI/CDを実現するためのSaaSです。
CircleCIでは主に下記の3つのタスクを実行できます。
- ビルド：ソースコードからアプリケーションを構築する。
- テスト：テストコードや静的コード解析を実行する。
- デプロイ：ビルドしてテストにパスしたソースコードを検証環境や本番環境にリリースする。
そして、他のCI/CDツールと比較して下記の特徴があります。
- シンプルな設定方法のおかげで環境構築コストが低い
- GitHub/Bitbucketと容易に連携できる
- 規模の大きさに応じて料金がかかる
この記事を読むことでCircleCIの使い方や躓きやすいポイントについて理解して、テストやデプロイの自動化をサクッと実現できるようになります。
初めてCircleCIを導入することになったけど使い方がよくわからない…。
CircleCIの使い方や注意点を知りたい！
と悩まれている方は是非最後までお読みください！
今回の記事作成にあたり、下記のサイトを参考にさせていただきました。
CircleCIの使い方
まずはCircleCIの大まかな利用の流れについて確認し、次に根幹となる設定ファイルの内容について説明します。
そして最後に私が実際に作成したRailsアプリケーションでテストを自動実行する設定を例に、設定ファイルの具体的な書き方について解説します。
利用の流れ
基本的なCircleCIの利用の流れは下記となります。
- CircleCIとGitHubを連携する
- 対象のリポジトリ内に.circleci/config.ymlを作成する
- リポジトリにプッシュするとconfig.ymlの内容が自動で実行される
実際に利用してみると感じると思いますが、驚くほどにシンプルで分かりやすいです。
しかし、上記の説明だけでは
「config.ymlの内容が自動で実行される」ってどこで実行されるの？
と思われるかもしれません。
結論から言うと、CircleCIが用意してくれているクラウド環境にプルしてきたDockerコンテナ内、もしくは自身で用意した仮想マシン (VM) 内で実行されます。
基本的にはDockerコンテナを使用することが多いので、最初はDockerを使用するのがオススメです。
.circleci/config.ymlの説明
正直な話、CircleCIの設定は.circleci/config.ymlでほぼほぼ完結すると言っても過言ではありませんw
基本編
ここからはHelloWorldを出力するだけの簡単なconfig.ymlを例に、各項目について解説していきます。
下記のconfig.ymlは簡単に言うと、「circleci/node:4.8.2」というDockerコンテナをプルして、そのコンテナ内で該当のソースをチェックアウトしてechoコマンドを実行しています。
version: 2.1
jobs:
build:
docker:
- image: circleci/node:4.8.2
steps:
- checkout
- run: echo "hello world"
そして、上記config.ymlのキーが意味する内容は下記となります。ちなみにconfig.ymlにおいて、下記のキーは必須です。
- version：CircleCIのバージョンを指定する。
- jobs：1つ以上のjobを設定する。jobが1つだけの場合、job名は「build」でなければならない。各jobではCI環境設定などを行う。
- steps：CI環境上で動作させるコマンドや実行結果の保存、キャッシュ操作などを設定する。
あとはリポジトリにプッシュするだけで設定したjobが実行される、という流れですね。jobに指定されている名前はbuild、test、deployの3種類が多いイメージです。
応用編
応用編として下記のようなキーもあります。必須ではないのですが、config.ymlを冗長に書かないようにするために役立ちます。
- orbs：ジョブ、コマンド、Executorなどの構成要素をまとめた共有可能なパッケージのこと。要は設定を短く書ける。
- executors：jobsで再利用可能な実行環境を定義する。
- commands：jobsで再利用可能なcommandを定義する。関数のように扱える。
特にexecutorsとcommandsを使うとDRYに書けるので、スッキリとした設定ファイルを書きたい方は是非使ってみてください。
RSpecを自動実行する設定を解説
ここからは具体的としてRSpecを自動実行する設定の書き方を、私が作成したRailsアプリケーション用のコチラの.circleci/config.ymlを例に解説していきます。
まず、全体的な流れは下記となります。featureブランチの内容がmasterブランチにマージされた場合の動作を想定しています。
- RubyとMySQLのコンテナを用意し、GitHubからマージされたソースコードをプルする。
- コンテナにgemをインストールし、DBを立ち上げる。
- RSpecを実行する。
- RSpecがすべてパスした場合、本番環境用のEC2インスタンスにSSH接続して、テスト済みの最新ソースコードをプルする。
上記の応用編でも解説したorbsやexecutors、commandsを使用して可読性を高めているのがポイントです。
また、AWS関連などのマスクする必要のある値はCircleCI上に環境変数を設定する箇所に設定しています。下記の記事を参考にしました。
CircleCIの注意点
ここまではCircleCIの基本的な使い方について解説してきました。ここからは私が初めてCircleCIを使う方に伝えたい注意点を説明していきます。
本記事は私がCircleCIを初めて使ってから3日後くらいに執筆しているので、かなり鮮度の高い内容となっておりますw
まずは公式のリポジトリをフォークして動きを確認
自分のつくったアプリケーションの設定ファイルを作成する前に、まずはCircleCI公式のリポジトリをフォークしてきて試しに動かしてみるのがオススメです。
なぜなら、最初は正しく動作する設定ファイルを見て書き方や動作を確認してからのほうが、自身のアプリケーションの設定ファイルを作成する際に処理の流れがイメージしやすくなるからです。
Railsアプリケーションであれば下記の記事に沿ってリポジトリをフォークして一旦動きを確認してみるのがオススメです。
CircleCIってこんな風に動いてるんだ！
というような感じで理解できると思います。
最初は冗長な書き方でOK
最初に書くときはorbsやcommandは使わなくてもOKです。
なぜなら、冗長性を意識するよりもとりあえず正しく動作する設定ファイルを作成するほうが優先度が高いからです。
orbsやcommandはあくまで設定ファイルを冗長に書かなくて済むためのものなので必須ではありません。
もちろん冗長でない方が良いのですが、まずは冗長でも良いので意図したとおりに正しく動作する設定ファイルを作成することを目標にしましょう。
プログラミング同様あとからリファクタリングできます。私が作成したコチラの設定ファイルではorbsとcommandを使用しているので、設定ファイルを作成できた方は参考にしてみてください。
デプロイ自動化は別途ツールを使用したほうが良い
CircleCIでデプロイまで自動化できると書きましたが、現実的にはデプロイ部分は別でデプロイ用のツールを利用するのがベターだと言えます。
なぜなら、デプロイの処理は基本的に長いのでCircleCIの設定ファイルにデプロイの処理まで書いてしまうと読みづらくなってしまうからです。デプロイツールは別途用意して、CircleCIからはデプロイツールを叩く処理のみ記述するのがベターです。
RubyであればCapistrano、PythonであればFabric等がメジャーかなと思います。私自身デプロイツールは記事執筆時点で使ったことがないので、使用する機会があればまた記事にしたいと考えています。
フルでCI/CDを実装したい方は自分のアプリケーションで推奨されているデプロイツールに是非キャッチアップしてみてください。
まとめ：CircleCIでテストとデプロイの自動化にチャレンジ
CircleCIの使い方と注意点について解説しました。
CircleCIは少し学習コストはあるものの、それを上回るくらいのメリットがあるので導入すべきだなと感じました。一度導入してしまえばプログラムの修正や機能追加に集中できるからです。
私自身Jenkinsの導入にも挑戦してみましたが、初学者でも理解できるドキュメントが少ないことや設定できる項目が多すぎてアレルギー発症したことが原因で挫折しました…。それに比べるとCircleCIは日本語ドキュメントも豊富かつシンプルに設定できます。
初めてのCI/CDツールとしてCircleCIは最適だと思うので、是非CircleCIでテストとデプロイの自動化へチャレンジしてみてください！
