• 導入
  • フェニックスとは？
  • Elixirとは何ですか？
• 要件
  • Phoenixプロジェクトの新規作成
  • PostgreSQLデータベースの初期化
  • Phoenixサーバの起動
• GitLab CI/CDの紹介
• Phoenix設定の調整
• テスト
• CI/CDパイプラインの設定
• ビルドの様子
• 結論
• リファレンス

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/localhostCDは.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を使い続ける理由は他にもたくさんあります。 私たちのチームにもたらされるメリットは非常に大きいでしょう！

リファレンス

• GitLab CI/CD入門ガイド
• GitLab CI/CDフルドキュメント
• GitLab Runner ドキュメント
• Dockerイメージの使用に関するドキュメント