kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

CircleCIをRailsで使う

CircleCIってなに?

SaaSのCIツール

SasS

Software as a Service

  • 必要な機能だけサービスとして切り出したソフトウェア
  • インターネット経由でサービスを提供するのが一般的

CI

Continuous Integration 継続的インテグレーション

ビルドやテストを継続的に実行していく為の習慣

Jenkins じゃダメなの?

Jenkins ツライ

  • 設定がめんどいので属人化しがち
  • ダウンタイムがあったりするとリリースできなくなるので大変
    • それを自社サーバで管理とか、監視やら運用に人的コストがかかってつらい
  • サーバ環境が同一なので、異なる環境で動作するアプリのテストができない

そこでCricleCIですよ

  • テスト毎に仮想環境を立ち上げられる
  • 他サービスとの連携が豊富
    • HitHub
    • Slack
    • heroku 等...
  • それなりに安定している
    • とはいえ、AWSGithubに依存しているので、そちらの障害の影響も受ける
    • とはいえ、よっぽど死んだら困るシステムでない限りは、Jenkinsサーバの面倒を見るよりは、お金で解決しちゃった方が、エンジニアにより重要なお仕事を任せられるのでは?

ちなみにステータス情報は以下

お値段

  • 1コンテナ無料
  • 2コンテナ目以降、50$/コンテナ

コンテナって?

  • テストを実行する仮想環境のインスタンス
  • コンテナに空きがあった場合、テストを複数のコンテナで並列に走らせるので早い
  • コンテナに空きがない場合、空きが発生するまで待つ

テストに時間が掛かったり、複数のプロジェクトをごりごりcommitする場合などは課金してコンテナを増やしたほうが良い

試してみる

プロジェクトの追加

https://circleci.com/add-projects

後は勝手に環境を判断して、bundle install してテストを実行してくれる

  • 賢い!!

ブランチをPRすると、勝手にテストを実行してPRにテスト結果を貼り付けてくれる

  • 賢い!!

Add_failed_test_by_kasei-san_·_Pull_Request__1_·_kasei-san_circle_ci_demo_-_Vimperator.png

結果をslackに通知したい

プロジェクトの歯車マーク → Chatroom Integrations → Slack に webhook の URL を入れる

おんなじテストをもっかい実行したい

対象のバージョンを選んで「Rebuild」ボタンを押下

テストが失敗したbranchのマージを禁止したい

githubprotected branchesなる機能がある

settingsから設定可能。指定したbranchに以下の制限を追加できる

  • テストが通っていないbranchのマージ禁止
  • force push 禁止

Branches_-_Vimperator.png

Protected_branch_-_master_-_Vimperator.png

上から

  • force push の禁止
  • ステータスチェックを通らないbranchのマージ禁止
    • 管理者でも禁止
    • ステータスチェック : ci/circleci

こんな感じに、テスト失敗するとマージボタンが押せない

Add_failed_test_by_kasei-san_·_Pull_Request__1_·_kasei-san_circle_ci_demo_-_Vimperator.png

環境変数を設定したい

# circle.yml
machine:
  environment:
    FLEX_HOME: /home/ubuntu/.flex
    PATH: $FLEX_HOME/bin:$PATH

参考

ついでに、circle.yml の話

circle.yml ってなに?

CircleCI環境独自の設定を書くところ

6個のセクションを持つ

  • machine : VM環境の設定
  • checkout : コードチェックアウト後の処理
  • dependencies : 依存関係。環境作成時の処理
  • database : DBの初期処理
  • test : テストコマンド
  • deployment : テスト正常終了後に実行されるデプロイコマンドを設定

machine 以外では、以下の設定が共通

  • pre : それの前にやる処理
  • post : それの後やる処理
  • override : その処理をまるっと上書き

例えば、checkout の post ならば、「コードをチェックアウトした後にやる処理」になる

machine

VM環境の設定

machine:
  hosts:
    dev.circleci.com: 127.0.0.1
  • 言語のversion
  • 動作させるservice

checkout

コードチェックアウト後の処理

  • post のみ設定可能
checkout:
  post:
    - git submodule sync
    - git submodule update --init
    - mv config/.app.yml config/app.yml

dependencies

依存関係。環境作成時の処理

  • bundler : without でGemfileにあるけど、使わない dependency groups を設定
  • cache_directories : キャッシュするディレクトリを指定
    • フレームワーク固有のキャッシュは、よしなにキャッシュしてくれる様子
    • キャッシュされたディレクトリは、つぎのインスタンスにも持ち回される
    • テストの実行が遅くなってきた時に使う

Rubyだと、デフォルトで入っている bundler のバージョンを最新にするのをよくやる

dependencies:
  pre:
    - gem uninstall bundler
    - gem install bundler --pre
  bundler:
    without: [production, osx]

database

DBの初期処理

datbase.yml に独自の設定を使いたい場合

database:
  override:
    - mv config/database.ci.yml config/database.yml
    - bundle exec rake db:create db:schema:load --trace

test

テストコマンド

rubocopも一緒にやりたい場合

test:
  pre:
    - bundle exec rubocop
  • override でテストコマンドそのものも変更できる

deployment

オプション。テスト正常終了後に実行されるデプロイコマンドを設定できる

  • 長くなるので別記事で

TODO

  • RuboCopの実行結果をPRに追記したい
  • masterリポジトリのテスト通ったらherokuにデプロイしたい

参考