CircleCIを導入してシンプルなワークフローを実現！デプロイの効率化にチャレンジ

さぁ、久しぶりの素人のブログDIYの時間。 今回は、Circle CIの導入です。

いきなり謎なんだけど、CIってなんなの？ {.chaosboy .peapleicon}

継続的インテグレーション、CI（英: continuous integration）とは、主にプログラマーのアプリケーション作成時の品質改善や納期の短縮のための習慣のことである。

継続的インテグレーション - Wikipedia

ちょwww難しすぎだろ {.chaosboy .peapleicon}

・・・た確かに😫 と、とりあえず、やってみましょう😅

自動化したいワークフローを明確にする

僕が実現したいことは、下記のワークフロー。

1. Next.jsを使ってブログ記事を書く
2. 記事が書けたら、作業ブランチをgithubにpush
3. （ここは手作業）Githubのmaster branchに作業ブランチをmerge
4. masterへのmergeを検知して自動でnuxt generateする
5. generateで生成された静的なhtmlファイル類を、firebaseにデプロイ（アップ）する

要約すると、 githubへpushしたら、自動的にyarn run generateして、出来上がったファイルをfirebaseに公開する、 という、一連の流れを自動化すると言うものです。

これまでは、ローカルでコマンド叩いてやっていたんですね。 それでも、Nuxt.jsもfirebaseも、本当によくできているおかげで、素人でも不便さはほとんど無いんですよ。

でも、どうしても導入したかった。 もはや意識の問題なんですが、generateもfirebase deployもgit push origin masterも、それぞれ単体でコマンドを叩くので、なんとなく気持ち悪いというか・・・必然性が無いんですよね、流れに。

そのせいで、githubへのプッシュを忘れちゃったりが頻発したりしちゃって、ちぐはぐな気持ちだったわけです。

しばらくはごまかしつつやって来たわけですが、そいつを解消して「気持ちよくブログを更新しようぜ！」

そう思い立ったというわけです。

GitHubとNuxt generate

まずは、

1. githubのmasterにプッシュされたら、
2. circleCIが検知して、
3. next generateを叩いて静的サイトを生成

この3つを成功させます。 セッティングはとても簡単ですぐに動いてくれたので拍子抜けしました。 config.ymlの作成はググった内容で、ほとんどコピペで完了！

しかし、動いたけどエラーが。。。

nuxt generateでエラー・・・😓

ローカルでは成功しているgenerateが、circleCI上でエラーになってしまっていました。 エラーも最初よくわからなくて、しばらく唸ってました。

結論。

ファイル名の英語の大文字が、小文字になっていました😅

componentsディレクトリのなかのコンポーネントのファイル名を、サンプルに従って頭文字を大文字にしていたのですが、一ファイルだけ小文字になってたんですね。 おそらく小文字からリネームして大文字にしたんでしょうが、gitの設定で頭文字の違いは無視されていたようです。

それに気づかずに今まで来てしまっていた。 痛恨の凡ミス😆

無事にエラーを改修できたので、良しとしましょう。

FIREBASEにデプロイする

ここではfirebaseにデプロイして、更新されたブログ記事が公開されるという部分。

5. generateが終わったら、生成された静的なhtmlファイル類をfirebaseにデプロイ（アップ）する

これを成功させます。

Firebase deploy用にトークンを発行します。 こちらの方がとっても詳しく書いてくれてます。

Circle CIでFirebaseにデプロイする方法

すでにfirebaseを利用している前提です。 $ firebase login:ci

config.yamlに以下のリファレンスの内容をコピー。

Configuring Deploys - CircleCI

Workflowを利用することで、文字通り動く順を指定することができます。

エラーが出た

  - run:
    command: ./node_modules/.bin/firebase deploy --token=$FIREBASE_TOKEN
    name: Deploy Master to Firebase

has incorrect indentation, it should be formatted like:

  - step:
      option1: value
      option2: value

インデントミスってるじゃんwww {.chaosboy .peapleicon}

/bin/bash: ./node_modules/.bin/firebase: No such file or directory

ん？これなどうなんだ？ ファイルがない？

グオオ {.chaosboy .peapleicon}

buildのstep

      - persist_to_workspace:
            root: .
            paths:
                - .

deployのstep

      - attach_workspace:
          at: .

これでいける！

キャッシュが効いていたせいで出ていたエラーにハマる

キャッシュのところをいじってる時に、なんか間違った処理がキャッシュされてしまって、config.yamlをいくら直してもエラーが出続けた。 キャッシュをクリアしなくてはいけない！

Caching Dependencies - CircleCI

これを回避するために、キャッシュのキーを変更する。 circleCIのキャッシュについてはこちらの方を参考にしました。

CircleCIのキャッシュ(cache_directories)の挙動を解説するよ · tehepero note(・ω<) 2.0

まとめ：シンプルで一直線なフローを実現する！

CIを導入することで、ワークフローを一直線にすることができるのが良いと思いました。

今までは何にも考えずに、generate -> firebase deploy -> git push masterしてました。 良くも悪くも、直接デプロイできてしまうんです。 作業が並列になってしまって、いつも適当な順番になってしまう。

すると、「Githubへのプッシュが忘れがち」になってしまい、「pushの存在意義が薄まっている」ということにきづきました😅

というわけで、CircleCIを導入すると、必然性のあるシンプルなフローに変わります。 フローを直列にすることによって、無駄な気遣いが減るんですね。

理路整然となっていると、気持ちがいいものです。