GitLab CI/CDを使ったPhoenixアプリケーションのテスト
Phoenixは Elixirで書かれたWeb開発フレームワークです。 Elixirは生産性とメンテナーのために設計された関数型言語で、Ellang VM上で動作します。 Ellang VMはとても高速で、非常に多くの同時ユーザを扱うことができます。
だから今日、私たちはフェニックスのことをよく耳にするのです。
このチュートリアルでは、PhoenixアプリケーションをビルドしてテストするためにGitLab CI/CDをセットアップする方法を説明します。
このチュートリアルでは、Phoenixアプリの作成方法、ローカルでのテストの実行方法、GitとGitLab UIの操作方法を知っていることを前提としています。
導入
フェニックスとは?
Phoenixは Elixirで書かれたWeb開発フレームワークです。Ellang VMを使用しているため、高速で信頼性が高く、高性能なアプリケーションを構築するのに便利です。
多くのコンポーネントやコンセプトは、Ruby on RailsやPythonのDjangoに似ています。 開発者の生産性が高く、アプリケーションのパフォーマンスが高いことは、使い方を学ぶ上でのほんの少しの利点です。 MVCパターンで動作し、モジュール式で柔軟性があるように設計されています。 成長するアプリを簡単にメンテナーできることはプラスです。
PhoenixはErlangがサポートされていればどのOSでも動作します:
- Ubuntu
- CentOS
- Mac OS X
- Debian
- Windows
- Fedora
- ラズベリーパイOS
詳しくはフェニックス・ラーニング・ガイドをご覧ください。
Elixirとは何ですか?
Elixirは、Erlang(30年前!)の成熟した部分を簡単に使えるように作られた動的な関数型言語です。 構文を中心にRubyと似ているので、Ruby開発者はElixirの急成長にとても興奮しています。 フルスタックのRuby開発者であれば、ElixirとPhoenixの使い方を数週間で習得できます!
Elixir にはmix
というコマンドがあります。これはプロジェクトの作成、テスト、マイグレーションの実行などを行うためのヘルパーです。このチュートリアルの後半でこのコマンドを使います。
詳しくはElixirのドキュメントをご覧ください。
要件
このチュートリアルに従うには、インストールが必要です:
- Elixirのインストール手順
- Phoenix Frameworkのインストール手順
- PostgreSQL (MySQL サーバを使用する必要がある場合は、Phoenix の説明を参照してください)
Phoenixプロジェクトの新規作成
ターミナルを開き、プロジェクトを作成したいディレクトリに移動してください。プロジェクトのファイル用に空のディレクトリを作成する必要はありません。mix
コマンドがそれをやってくれるからです。
mix
、2つの引数を渡します:
- 実行させたいタスク:
phoenix.new
- そして、
phoenix.new
というパラメーターが必要です。これは新しいプロジェクトの名前です。この場合、hello_gitlab_ci
と呼んでいますが、自由に名前を設定してください:
mix phoenix.new hello_gitlab_ci
と聞かれたら、Y
と答えて、依存関係を取得してインストールします。
すべてがうまくいけば、次のような出力が得られます:
これで、プロジェクトはmix
コマンドに渡したのと同じ名前のディレクトリ、例えば~/GitLab/hello_gitlab_ci
の内部に配置されました。 ディレクトリを見てみると、Phoenix ファイルと実行に必要な依存関係があることがわかります。
PostgreSQLデータベースの初期化
デフォルトでは、PhoenixはPostgreSQLデータベースを必要とします。 今回は空のデータベースを作成します。
まず、最近作成したプロジェクトのディレクトリに移動して、もう一度実行しますmix
。 この mix
とき、ecto.create
というパラメータを受け取ります。これは新しいデータベースを作成するタスクです。EctoはElixirのデータベースラッパーです。
プロジェクトを作成してから最初にmix
を実行すると、ファイルはバイトコードにコンパイルされ、Erlang VMで解釈されます。
以下のコマンドを実行して空のデータベースを作成します:
cd hello_gitlab_ci
mix ecto.create
コマンドの最後にこの出力が表示されることを期待しています:
Generated hello_gitlab_ci app
The database for HelloGitlabCi.Repo has been created
注意:Phoenixは、PostgreSQLデータベースに
postgres
正しい権限とパスワードを持つユーザーアカウントがpostgres
あることを想定しています。 もしそうでない場合は、Ectoの説明を確認してください。
Phoenixサーバの起動
さて、ここまでの作業がうまくいったかどうかを確認しましょう。mix
をもう一度呼び出します。今度はphoenix.server
パラメータを指定して、Phoenix の HTTP Server を起動します。
mix phoenix.server
これがこのコマンドの出力になります:
[info] Running HelloGitlabCi.Endpoint with Cowboy using http://localhost:4000
23 May 11:44:35 - info: compiling
23 May 11:44:37 - info: compiled 6 files into 2 files, copied 3 in 9.8 sec
これで、アプリがローカルで動作するようになりました。 ブラウザで直接プレビューすることができます。localhost:4000
を開いて、Phoenix Frameworkのウェルカムページを見てみましょう。 リンクが機能しない場合は、代わりに127.0.0.1:4000
を開き、後でlocalhost
を127.0.0.1
に向けるようにOSを設定してください。
これでローカルのPhoenix Serverでアプリが動作するようになりました。
内部では、アプリケーションはiex
セッションで実行されています。これは Interactive Elixir の略です。この対話型モードでは、任意の Elixir 式を入力し、その結果を得ることができます。iex
を終了するには、Ctrl+C
2回 Ctrl+C
押す必要がありますCtrl+C
。つまり、Phoenix サーバーを停止 Ctrl+C
するには、2回Ctrl+C
押す必要が Ctrl+C
あります。
GitLab CI/CDの紹介
GitLab CI/CDを使えば、開発ワークフローの管理、生産性の向上、イシューの追跡、コードレビューなど、様々なことが単一のプラットフォームで行えます。 GitLab CI/CDは、私たちや同僚がコードをプッシュするたびに、その変更をビルドしてテストし、何か問題があればリアルタイムで知らせてくれるので、生産性が格段に向上します。
確かに、私たちのアプリケーションが成長し始めたら、同じプロジェクトで働く開発者がもっと必要になるでしょうし、このビルドとテストのプロセスは、適切な管理がなければ簡単に混乱してしまいます。 GitLab CI/CDが私たちのアプリケーションにとってとても重要な理由もそこにあります。 誰かがコードをGitLabにプッシュするたびに、私たちは彼らの変更が何かを壊したかどうかをすぐに知ることができます。 私たちのチームが行うすべての変更を手動でローカルにテストするために、私たちが行っているすべての作業を中断する必要はありません。
実際に見てみましょう。
Phoenix設定の調整
ここで、GitLab CI/CDを設定する前にPhoenixの設定を調整する必要があります。Phoenixプロジェクトにはディレクトリ(config
)があり、実行可能な環境ごとに設定ファイルが格納されています。今回は単一の環境で作業するので、テスト用の設定ファイル(test.exs
)だけを編集します。
しかし、なぜ設定を調整する必要があるのでしょうか? GitLab CI/CDは、Dockerテクノロジーを使ってRunnerと呼ばれる1つの隔離された仮想マシンでコードのビルドとテストを行います。 このRunnerでは、GitLab CI/CDはPhoenixアプリケーションの実行に必要なすべてのものにアクセスすることができます。 このようにlocalhost
、GitLab CI localhost
/localhost
CDは.NET FrameworkでPhoenixを実行するときと同じように、Runner内にテストデータベースを作成 localhost
します。
- お好きなコードエディターで
hello_gitlab_ci/config/test.exs
を開いてください。 -
データベース・セッションを設定し、ブロックを編集して
System.get_env
を含めます:# Configure your database config :hello_gitlab_ci, HelloGitlabCi.Repo, adapter: Ecto.Adapters.Postgres, username: System.get_env("POSTGRES_USER") || "postgres", password: System.get_env("POSTGRES_PASSWORD") || "postgres", database: System.get_env("POSTGRES_DB") || "hello_gitlab_ci_test", hostname: System.get_env("POSTGRES_HOST") || "localhost", pool: Ecto.Adapters.SQL.Sandbox
これらのシステム変数は後で必要になります。
-
.gitkeep
という名前の空のファイルを作成します。hello_gitlab_ci/priv/repo/migrations
私たちのプロジェクトはまだ新しいので、データベースにデータがなく、
migrations
ディレクトリは空になります。.gitkeep
がないと、Git はこの空のディレクトリをアップロードしないので、GitLab でテストを実行するときにエラーが発生します。注:GitLab UIでフォルダを追加すると、GitLab自身が
.gitkeep
。
では、ローカルテストを実行し、私たちが行ったことが何も壊れていないか確認してみましょう。
テスト
先ほど、プロジェクトを作成したときにmix phoenix.new
を実行しました。 このタスクはPhoenixアプリケーションに必要なものすべてを作成し、いくつかのユニットテストもhello_gitlab_ci/test
ディレクトリに作成します。
これらのテストを実行するために、mix
で新しいタスクを実行してみましょう。 今回、期待されるパラメータはtest
です。 デバッグのために、--trace
パラメータを追加することができます。
ターミナルで、hello_gitlab_ci
ディレクトリに移動し、実行します:
mix test
予想される結果はこうです:
....
Finished in 0.7 seconds
4 tests, 0 failures
Randomized with seed 610000
テストは成功したので、ファイルを GitLab にプッシュしましょう。
CI/CDパイプラインの設定
最初のステップは、プロジェクトのhello_gitlab_ci
ディレクトリに.gitlab-ci.yml
という新しいファイルを作成することです。
-
これを行う最も簡単な方法は、プロジェクトのメインページでCI/CDを設定するをクリックすることです:
-
次の画面では、Elixir テストが既に含まれているテンプレートを使用します。Apply a templateをクリックし、Elixirを選択します:
このテンプレートファイルは、新しいコミットが行われるたびに GitLab CI/CD に何をしたいのかを伝えるものです。 しかし、Phoenix アプリを実行するには少しアレンジしなければなりません。
-
最初の行は、どのDockerイメージを使うかをGitLabに伝えます。
GitLab CI/CDがアプリケーションをビルドしてテストする隔離された仮想マシンであるRunnerについて学んだことを覚えていますか? この仮想マシンは、アプリケーションを実行するための全ての依存関係を持たなければなりません。 ここでDockerイメージが必要になります。 正しいイメージは、私たちのためにシステム全体を提供してくれます。
ここでは(デプロイではなく)テストに焦点を当てているので、ElixirやErlangといったPhoenixテストを実行するための依存関係が既にインストールされているelixir:latestDockerイメージを使うことができます:
image: elixir:latest
-
postgres
のみを使用するので、services
セクションからmysql
とredis
の行を削除します:services: - postgres:latest
-
ここで、
before_script
セクションの前に、variables
という新しいセクションを作ります:variables: POSTGRES_DB: hello_gitlab_ci_test POSTGRES_HOST: postgres POSTGRES_USER: postgres POSTGRES_PASSWORD: "postgres" MIX_ENV: "test"
先ほど
config/test.exs
で行ったように、GitLab CI/CD が PostgreSQL を認証するための値を設定しました。POSTGRES_USER
とPOSTGRES_PASSWORD
の値は、postgres
サービスがこれらの認証情報を持つユーザーを作成するために使用します。 -
before_script
セクションでは、テストの準備のためにいくつかのコマンドを追加します:before_script: - mix local.rebar --force - mix local.hex --force - mix deps.get --only test - mix ecto.create - mix ecto.migrate
これにより、テストの実行に必要な依存関係を取得しようとする前に、rebar3とhexの両方がインストールされていることが確認されます。 次に、
postgres
dbが作成され、ecto
、最新であることを確認するために移行されます。 -
最後に、
mix
の部分は変更しません。
変更後のファイルを見てみましょう:
image: elixir:latest
services:
- postgres:latest
variables:
POSTGRES_DB: hello_gitlab_ci_test
POSTGRES_HOST: postgres
POSTGRES_USER: postgres
POSTGRES_PASSWORD: "postgres"
MIX_ENV: "test"
before_script:
- mix local.rebar --force
- mix local.hex --force
- mix deps.get --only test
- mix ecto.create
- mix ecto.migrate
mix:
script:
- mix test
安全のため、このファイルをGitLabに提出する前に、構文エラーがないか確認することができます。.gitlab-ci.yml
の内容をコピーし、GitLab CI/CD Lintツールに貼り付けます。 このリンクはログインしているユーザーのみ機能することに注意してください。
ビルドの様子
皆さんはどうか分かりませんが、私はコンパイル出力で埋め尽くされる黒い画面を見るのが大好きです。 これによって、自分が作ったものが正しく動作する幸せを感じることができます。localhost
では、ビルドを見るのは簡単ですが、GitLab では可能でしょうか? はい!
パイプラインでGitLab がジョブを実行しているところを見てみましょう。Pipelinesをクリックすると、実際に実行されているビルドジョブが見つかります。
ビルドのIDをクリックすると、全プロセスを見ることができます。 すべてが期待通りに進んでいれば、プロセスの最後にビルドが成功したことを待つことができます! :)
$ mix test
....
Finished in 0.3 seconds
4 tests, 0 failures
Randomized with seed 206909
Build succeeded
GitLab UIでプロジェクトのメインページを見てみると、GitLab CI/CDで最後にビルドされたステータスを見ることができます。
緑色のビルドバッジを世界に示す時が来ました!プロジェクトの設定 > CI/CDに移動し、一般パイプライン設定を展開します。パイプラインステータスにスクロールダウンし、バッジ用のMarkdownコードをコピーします。 最新のコードがエラーなしで実行されているかどうかをプロジェクト内部の人に見てもらうために、README.md
ファイルの上部に貼り付けます。
このエディションが終わると、GitLab は別のビルドを開始し、ビルド実行中のバッジを表示します。 これは予想通りです。結局のところ、GitLab CI/CD はプッシュするたびにこれを実行するように設定したのですから!しかし、「README.md の編集のような単純なことのために、なぜビルドとテストを実行するのか」と思うかもしれませんし、それは良い質問です。 アプリケーションに影響を与えない変更については、コミットメッセージに[ci skip]
というキーワードを追加すれば、そのコミットに関連するビルドはスキップされます。
最終的に、緑色のビルド成功バッジを手に入れることができました!結果をREADMEファイルに出力することで、あなたのプロジェクトのページにアクセスした人に、あなたのコードが最新で適切に動作していることを示すことができます。
結論
多くの開発者が作業している成長中のアプリケーションや、コミュニティによって監視され貢献されているオープンソースプロジェクトでは、コードを永続的に動作させることが本当に重要です。 GitLab CI/CDは、コードを整理して動作するように維持するための時間節約に役立つ強力なツールです。
この投稿でわかるように、GitLab CI/CDは本当に簡単に設定し、使うことができます。 GitLab CI/CDを使い続ける理由は他にもたくさんあります。 私たちのチームにもたらされるメリットは非常に大きいでしょう!