フロントエンドのCIの実行する時間を減らす方法について

フロントエンドのCIでよくあるフロー

• 1. CI動くの準備
• 1. Lint
• 1. フロントエンドのテスト
• 1. ビルド

今までの経験だと、⓵と⓸は一番時間がかかりました。
⓷はテスト数による時間が異なります。

---

時間がかかった理由

• フロントエンド動くためのアプリ、nodejs, npm などのインストール時間 →　これはCIのイメージの定義に設定入れれば、解決できます。
• ライブラリーのダウンロードの時間
• フロントエンドのビルド時間

---

今回にライブラリーのダウンロードの時間を減らす方法を紹介します。

---

時間を減らす方法方法

• キャッシュ方法
• 一回だけライブラリーをダウンロードして、CIでライブラリーをダウンロードしないようにします。

---

実際のコード

---

CIイメージの定義

• キャッシュがないDockerfile

FROM node:18.16-buster-slim

RUN apt-get update && apt-get -y install \
  bash \
  make \
  python \
  g++ \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
RUN mkdir /app
WORKDIR /app

---

• キャッシュがあるのDockerfile

FROM node:18.16-buster-slim

RUN apt-get update && apt-get -y install \
  bash \
  make \
  python \
  g++ \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*

# キャッシュのため
RUN mkdir /tmp_app
WORKDIR /tmp_app
COPY package.json package.json
COPY package-lock.json package-lock.json
RUN npm install

# ライブラリーフォルダーPATHを指定します。
ENV NODE_PATH=/tmp_app/node_modules

# 実際フォルダーのため
RUN mkdir /app
WORKDIR /app

---

メリット

• ライブラリーダウンロード時間は大分減らします。
• シンプル
• Docker Imageを使うCIなら、Ruby, Rust, PHPなどの言語は同じ方法で実装できます。

---

デメリット

• ライブラリーのファイルはイメージに入りますので、ファイルサイズは大きくになります。
• ライブラリーが変わったら、イメージを再ビルドしないとキャッシュが効かないです。
• ライブラリーが少ないプロジェクトはあまり改善されないです。

---

外部サビースのキャッシュの仕組み

• Circleci: Caching Dependencies
  https://circleci.com/docs/caching/

• Gitlab CI: Caching in GitLab CI/CD
  https://docs.gitlab.com/ee/ci/caching/

• Github Action: Caching dependencies
  https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows

---

以上です。