Deploy Previewが使いたくて使いたくてたまらなかったのでやってみた話

概要

今回の記事は、CI/CD弱者がdeploy preview欲しさに色々粘ってみた話です。deploy previewって何？という人にはぜひそういうものがあると知って欲しいし、知っているけど手が出ていない人には、状況によってはものすごく簡単に導入できるのでぜひやってみて欲しいです。実はまだ課題が残っているので強い人からは助言をいただけると嬉しいです。

一言でDeploy Previewとは

PR/MRごとにその修正内容のみを反映した環境を立ててデプロイしてくれるハイパー便利機能

Deploy Previewを使いたい理由

　最近仕事で自分が管理しているレポジトリ(Angularアプリケーション)にMRをもらうことが増えました。もちろん差分もきちんと確認しますが、やはりフロントのMRとなると実際に起動してビューを確認したいですよね。とはいえ、ローカルのブランチ無駄に増やしたくないし、やっぱりいちいちそのためだけにpullするのは面倒くさい
　また、自分がレビューするだけでなく、例えばデザインチームのメンバーなどレポジトリの管理メンバー以外の方にも見た目や動きを確認してもらいたいとなってくると、そのためだけにレポジトリのcloneからやってもらうのは気が引けるし相手も面倒という状況が結構多くなってきました。
　こう書くと個人開発で使うメリットがあまり感じられないかもしれませんが、私は自分個人のレポジトリにも欲しいなと思っています。というのは、レスポンシブな作りで設計した場合に、ChromeDevtoolのモバイルビューで確認するのと、実際デプロイされたものを携帯で確認するのとではやはり見え方が違う場合が多いからです。その点、deploy previewなら携帯からMR/PRを開けばマージ前に変更内容のモバイルでの確認ができます。
　ここまで考えて、「自宅で個人開発するにもdeploy preview欲しいし、そのやり方をマスターすれば仕事でも導入できるのは…！？」という野望が高まってきたので実際に導入に挑戦してみました。

Deploy Previewを導入する一番簡単な方法

　Netlifyを使う。以上です。本当にこれだけなのですがこれだけなのは何なので申し訳程度に説明すると、Netlifyにサインアップしてデプロイの設定をするだけです。デプロイ設定をすると、デフォルトでdeploy previewがオンになっていることがわかります。

とても簡単でした。個人利用であればこれで必要なものは全部揃う気がします。

ですが、私の場合deploy previewを導入したい仕事のレポジトリは、既にAWSで運用が決まっています。なので、私がしたいことはdeploy previewだけを導入する、またはAWSでdeploy previewを導入することです。そして前者はnetlifyでは無理そうだったので後者に挑むことになります。

Deploy PreviewをAWS amplify + gitLabで導入する

　というわけで、AWS amplifyのブランチごとに分けて環境を構築できる機能とgitLabのCI/CD機能に目をつけ、「gitLabでブランチがpushされた時だけ走るパイプラインを作成する→パイプラインのjobではaws cliを使って対象MRのブランチに接続しビルドをさせる」という流れで実行してみました。

前準備

　今回deploy previewを試すレポジトリを作成します。私はテスト用にgitHubにある自分のポートフォリオサイトのレポジトリをgitLabにimportしました。

gitLab Runnersを導入する

(0. 私はdockerいれてなかったのでdocker desktop for macを入れました)
1. 公式ドキュメントを見ながらgitLab Runnersのインストール
2. 更にそのまま書いてある通りにRunnerの登録 　
この時gitlab-ci tokenとは？となりましたが、その点は後にもご紹介するこちらの記事を参考にするとわかりやすいです。
3. .gitlab-cli.ymlをプロジェクトのルートディレクトリに作成　とりあえず中身は空で大丈夫です。gitLabから直接編集してファイルを足すと楽です。

aws amplifyの設定をする

こちらもプロダクションブランチのデプロイはnetlifyと同レベルで簡単です。
1. awsにログインしてaws amplifyにアクセス　(現在ウェブからだと東京リージョンがないので適当なところを選ぶ)(私はシドニー)
2. 新しく作成、でgitLabを選んで対象レポジトリを選ぶ
3. ビルド情報を入力する

gitlab-ci.ymlを編集する

aws amplifyでマスターブランチのデプロイ成功を確認したら、jobの編集にうつります。
1. aws amplifyの操作に必要な認証情報の設定　
　先ほども紹介したこちらの記事の通りに、プロジェクトのレポジトリ>Settings>CI/CD>VariablesにAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYを設定します。この情報はawsコンソールのIAMを開き、使用するIAMユーザーの認証情報から発行することができます。
2. gitlab-ci.ymlの編集
まず最初に、完成形がこちらです。

gitlab-ci.yml

image: python:3.6.5
variables:
    AWS_DEFAULT_REGION: ap-southeast-2
    APP_ID: d1tsllqkbkq626
stages:
    - deploy
deploy_job:
    stage: deploy
    only: 
        - branches
    except: 
        - master
    script:
        - pip install awscli
        - aws amplify create-branch --app-id ${APP_ID} --branch-name ${CI_BUILD_REF_NAME}
        - aws amplify start-job --app-id ${APP_ID} --branch-name ${CI_BUILD_REF_NAME} --job-type RELEASE

• variablesは実行する処理で使う環境変数を定義します。APP_IDはAWSコンソール> AWS Amplify>対象のプロジェクトのページ>全般>App Arnの末尾の記号です。
• stagesには実行する処理を順番に記載します。今回はdeploy previewの生成しかしないので一つだけです。
• deploy_jobではstagesで指定したdeployの内容を記述します。stageがstagesで記載した名前と対応しています。
• onlyでブランチにpushがあった時のみ実行するという条件をつけ、exceptでmasterブランチは除くと指定しました。
• scriptでまずはawscliをインストールし、次の２行のコマンドでMRのブランチを接続させています。

確認する

　そしてついにMRを作成するとパイプラインが走り出します。ジョブが成功したということを確認したら、早速レビュー環境にアクセスしましょう。AWSコンソールで確認できる本番環境用URLがhttps://master.{app_id}.amplifyapp.comだとすると、https://{ブランチ名}.{app_id}.amplifyapp.comでアクセス可能です。また、少し時間がかかっていましたがAWSコンソール上でも接続ブランチが増えていることを確認できました。

最後に

これで完成です
今まで本当にCI/CD周りを触ったことがないのでやり切れるか不安でしたが、半日くらいでここまでこぎつけることができて嬉しかったです。これを機に自分でも色々CI/CDの設定に触れてみようと思いました。残課題としては、このままだと元ブランチがなくなった時に自動でブランチが消えてくれないので何とか消えるようにしないといけないことと、MRから簡単にレビュー環境にアクセスできないことです。MRにURLを記載したコメントを投稿してくれるbotでも用意しないとダメなのかな…と思っています。(ちなみにnetlify経由でやった時はどっちも勝手にやってくれるので心配いりません)

ちなみに

　調べたところ、gitLab自体にそもそもReview　Appsの機能があるようなのですが、nginxとかを立てておかないとダメそうな感を受けたのと、ちょっととっつきにくそうだったので今回はやりませんでした。

最後まで目を通していただきありがとうございました