Elixir 開発環境 2017 in ACCESS

• Elixir のチームでの開発環境について
• エムスリーでの Elixir 開発環境 ver.2017 #m3dev - エムスリーテックブログ

上記の2つのElixir開発環境記事ブームに触発されてこの記事は書きました。

ACCESS(某オフィススイートの方ではなく、そのような名前の会社の方です)では2年ほど前から Elixir をプロダクションで利用するようになり、複数の案件のサービスを Elixir で開発・運用しているので、その開発環境に関して書きます。
別のエンジニアの方が環境整備した部分が大部分なので、それぞれのツールを選んだ理由とかは書けません。

開発環境の統一

Erlang, Elixir, Node, Rubyのバージョンは、リポジトリ内にasdf の.tool-versionsファイルを置いて、開発者は皆 asdf を利用するという方法で揃えています。

プロジェクトによっては ElasticSearch なども使いますが、私の参加したプロジェクトで ElasticSearch 使った時はサーバ開発者が2人だったので docker 化はしてなかったですが、少人数でもメリットはあるので docker 化してもよかったかもしれません。

コーディングルールとツール

大まかには下記に従っており、一部異なる部分のルールが markdown に書かれています。あとは既存のコードを読んで雰囲気を掴んで書きます。

• A community driven style guide for Elixir
• Credo's Elixir Style Guide

Credo の利用に関しては、プラットホームコア的な OTP Application のリポジトリの.credo.exsを、それを利用する全プロジェクトのリポジトリからシンボリックリンクで参照し、同じ設定を利用しています。基本的に credo でのチェックしてからPRします。

少し特徴的なコーディングスタイルとして、社内に開発者が存在する Croma を関数定義・Struct定義・エラー処理に頻繁に利用します。

コンパイルオプション

warnings_as_errors を true に設定しています。

Dialyzer

パブリック関数(def)は@specを書き、プライベート関数(defp)もよほどシンプルでなければ@specを書きます。上記の Croma のdefunで@specを生成することが多いです。

そして、PR前に dialyze でチェックします。type指定を間違えた時に気づけるようにunknownオプション付きで実行するので、mix dialyze --unknownとして実行します。14000行ほどのプロジェクトで30〜40秒ほどかかります。他の作業がしにくいこの微妙な時間が少し辛いです。

ユニットテストとカバレッジ

外部のサーバに接続する部分などは meck でモックすることがほとんどですが、プロジェクトによっては一部実際に ElasticSearch に接続するようなテストケースも書きます。

ユニットテストをどの程度書くかはプロジェクトによりますが、基本的にはステートメントカバレッジとしてはエラーの箇所も通るようにします。
カバレッジのパーセンテージは気にしておらず、例えば、コントローラーやロジックレイヤーは大体97%ぐらいはいきますが、ほぼロジックを含まないファイルのテストケースをサボったりすると全体は90%ぐらいに落ちたりしますが、余り気にしません。気にしていません。
そのプロジェクトではテストコードと実装コードの割合は大体2:1でした。

カバレッジは以前は coverex を使ってましたが、確かマクロ部分の結果をもっと見やすく表示できるということで、現在は excoveralls を使っています。
前述したようにパーセンテージは見ておらず、むしろ実装した部分のエラー処理を含めたテストケースを書いた時に、 excoveralls から出力された html を確認してエラー処理部分のコードを含めてきちんと「赤」ではなく「緑」になっており、テスト時に実行されていることを確認するのが目的です。

CI/CD

トピックブランチが master ブランチにマージされると、jenkins により開発環境のサーバにデプロイ準備＆デプロイがされます(release ブランチにマージするとプロダクション環境にデプロイされます)。
デプロイ準備では各種チェック＆テストが走り、1つでも失敗したらメール&HipChatに失敗の通知がされ、デプロイは行われません。

1. Webフロントエンドを持つサービスの場合、npm からデプロイ前のフロントエンド側のチェック＆テスト実行(この中の処理はプロジェクト毎に大きく異なり、ある1つのプロジェクトでの内容を記述する)
   • ESLint の実行
   • stylelint の実行
   • Flow のチェックの実行
   • Mocha の JavaScript のユニットテストの実行
   • webpack で結合した JavaScript/CSS ファイルの作成
2. Elixir 側のmix testの実行(コンパイル時の warnings_as_errors は true)。このとき excoveralls でカバレッジ取得＆html出力もしており、各プロジェクトのテストカバレッジ状況はブラウザから見れるようになっています。
3. Webフロントエンドを持つサービスの場合、上記で結合された JavaScript/CSS と画像のファイルに関して、ファイルの内容のハッシュを計算し、そのハッシュ付きのファイル名で S3 にファイルがアップロードされ、 CloudFront からアクセスできるようになります。ハッシュをファイル名に付けるのは、内容が変わらない限りブラウザにそのファイルを長期にキャッシュさせるためです。
4. relx をリリースに利用して Hot code upgrade でデプロイ実行。この辺りは OTP Application によってAWS EC2インスタンスのローリングアップデートでデプロイする場合もあり、詳しくはこの部分を実装したエンジニアが tokyo.ex #8 で発表した資料 Hot code upgrade in ACCESS に少し書かれています。

最後に

関数型でパターンマッチが強力で OTP が付いてる Elixir での開発は相当楽しいです。