ハンズラボエンジニアブログAWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。TakahashiPocketCRMチームのyktakaha4です。Actionsを導入した話についてお伝えします。Frameworkを用いてLambda関数を定義しています。Frameworkには、定義ファイルからLambdaをパッケージングしてAWS環境にデプロイしてくれるdeployというコマンドがあり、こいつは大変便利ですごいやつなのですが、deployコマンドを実行する環境そのものまで用意してくれる訳ではないので、利用者各自で運用方法を考える必要があります。荷札生成APIはリプレースで作成した新規プログラムで、開発者は基本的に私ひとり(RVはしてもらってましたが)という状況だったこともあり、今までは以下の図で示すようにローカル環境からデプロイをおこなっていましたが、システムが本格運用に差し掛かる中で、デプロイ手順や環境が個人に紐づいている状況は望ましくないと思い、リポジトリ上のソースコードが更新されたら自動的にデプロイが行われる仕組みを構築する必要があると考えていました。従来のデプロイフロー(もとい手作業)また、システムを長期稼働させる上で、実行環境やライブラリのバージョンアップ時の動作保証をどのように担保するか、という課題がありました。LTSでEOLも年末に迫っているため、準備が整い次第バージョンアップを進めていく必要があります。前回のブログにも書いたとおり、本APIは内部処理にてHTML帳票をPuppeteerを用いてPDF化していますが、実行環境がMacBookだった場合とLinuxだった場合で出力されるPDFに微差が生じることがわかっていました。ダンボールに貼る印刷物を作っているという性質上、ちょっとした表示不具合でもデータリカバリだけでは済まされないような障害・事故に繋がりかねないため、プログラムやライブラリ、実行環境を更新した際に、最終的な出力結果にどのような変更差分が生じたか検知できる仕組みをデプロイフローの中に組み込めるとよさそうです。いうことで、消費増税対応のためのプログラム修正がひととおり済んだところで、前述の課題を解決するため、荷札生成APIへのCI/CD導入に取り組むこととしました。Actionsで実現することとしました。Actions導入後は以下のようになりました。Actionsは、2019年11月よりGAとなる予定の新機能で、プルリクエストやブランチへのプッシュといった操作に対して、Dockerイメージを用いた任意のワークフローを定義・実行できます。CRMチームでも、thimi0412くんがECRにDockerイメージをプッシュするワークフローを作成したりなど、hcl形式で記述していた頃から積極的な利用をおこなっています。今年CRMチームに新卒配属となったhomines22くんが拾ってくれて、デプロイ用のワークフローをささっと作ってくれました!(具体的な定義内容は、こちらの記事にしっかりとまとめられています。)彼らに限らず、ラボの若手エンジニアは本当に優秀な人物ばかりで、アラサーの自分としては助かる反面末恐ろしいです...超ありがたいテストについてはいくつかのアプローチが考えられましたが、前述したライブラリのバージョンアップ等に伴うデグレードを確実に検知できるようにするため、スナップショットテスト(ビジュアルリグレッションテスト)のケースを重点的に作成し、一部カバレッジが低くかつ業務重要度の高い箇所に対しては単体レベルのテストを書く...という方針としました。具体的なテスト方法としては、RDSに接続して注文データを取得する箇所のコードをスタブに置き換えて、テストパターン毎に用意したJSONファイルの値を返却するようにした上で、それらのテストデータを使ってmasterブランチの内容で荷札出力したPDFも合わせてリポジトリに格納しておき、JSONから作成したPDFと前述のPDFの内容をGraphicsMagickでPNG画像化&比較するようにしています。逆に、ライブラリの更新などで生じた差分だった場合は、原因を調査...という感じになります。スナップショットテストのイメージテストフレームワークとしては、デファクトスタンダードでありCRMチームでも実績のあったJestを使用することにしました。テスト実施にあたって実際の環境との差異を少なくするため、docker-lambdaというLambdaの実行環境を模したDockerイメージを利用しています。実際に動作イメージを交えながらデプロイフローを見ていきましょう。CheckとTestのワークフローが自動的に実行されます。リポジトリのBranchesの設定により、各ワークフローが正常終了した場合のみマージを許可するようにしています。アクションの実行リポジトリのActionsタブを選択すると、各ワークフローの実行状況が確認できます。ワークフローの大まかな流れは、ブランチをチェックアウト→パッケージのビルド・インストール→やりたいこと(構文解析やテストの実行、デプロイなど)→成功/失敗を通知...という感じになっています。ワークフローの実行ログの確認スナップショットテストについては、もしもリポジトリに登録されている比較用PDFとテストデータのJSON&プログラムから出力したPDFが異なっていた場合は、以下のように差分を赤色化した画像ファイルを作成してくれます。テストデータについては住所・氏名などの個人情報をダミーデータに置き換えたものを登録しています。ふたつのPDFがこんな感じだったら...こんな感じの比較画像が生成されます本当はテスト失敗時に比較画像をプルリクエストのコメントに投稿したいのですが、時間が足らず実装できていません...今後の課題です。代わりと言ってはなんですが、テスト成功時にはIstanbulのテストカバレッジを投稿します。テストカバレッジ構文チェックとテストの結果に問題なければ、AWS上へデプロイします。トピックブランチをdevelopブランチへマージすると、今度はDeployのワークフローが実行されます。Frameworkのコマンドが実行できています。デプロイが成功(または失敗)したら、LintやTestの時と同様にSlackへ通知されて完了となります。ActionsのMeetupで登壇した際の発表資料が公開されていますので、こちらもぜひご覧ください。Actionsは導入にかかるコストも低く、CI/CDを手軽に始めるには非常に良い選択肢だと思いました。今後の機能拡充にも大いに期待しつつ、どんどん使っていきたいですね!Pocket。