AWS CodePipelineへ移行した時の失敗から得た学び

こんにちは、新卒2年目のバックエンドエンジニアの伊藤です。

ラボルでは先日、デプロイツールをJenkinsからAWSのCodePipelineに変更しました。

今回の記事では、その移行の際に自分が起こしてしまった不具合について体験談について書いていきます。

起きた不具合

発生した不具合はデプロイしても一部変更が反映されないというものです。

この不具合は、ブラウザがトランスパイル後のjsを使用する際に、サーバーから取得したものを使用せずブラウザキャッシュにあるものを利用していたため発生しました。

下記の画像のように、クエリパラメータが同じ場合サーバからは304が返されブラウザにあるキャッシュが利用されます。

このクエリパラメータの値が更新されていないと、デプロイしてもブラウザがキャッシュにあるデプロイ前のjsを使用してしまいます。

ちなみに、クエリパラメータの値が違う場合はサーバから200が返されブラウザのキャッシュが使われません。

どうして起きたのか

結論から言うと、
JenkinsからCodePoplineに移行する際に、Jenkinsで行っていた一部分だけの移行しか行っておらず、style.jsやapp.jsを取得時にクエリーパラメータに付けていたハッシュ値を更新する処理を忘れていたからです

Jenkinsを使用していた際は、タグの更新(バージョンの更新)とデプロイの2stepに分けてデプロイ作業を行っていましたが、CodePipelineではデプロイだけを実装していました。

当時、タグの更新についてはバージョンを管理するための作業で、クエリーパラメータの更新まで行っていることを知らずに作業を始めてたんですよね。。。

加えて、クエリパラメータが更新されていることを知らなかったため、移行後の確認項目に含んでおらず、発見することができませんでした。

再発させないために

今回の失敗を経て、2つの学びを得ました。

1つ目は、普段意識していない何気ない作業も大きな影響を持つことです。
Jenkinsではタグを更新する際に、クエリパラメータの値も更新されており、更新されていないとキャッシュが効いてしまうという不具合に繋がるが、そんなに大事な意味を持っていることを私は知らずにこの作業を行ってました。
そのことが今回の不具合の発端なため、自分の作業の一つ一つの影響を理解してその作業を行うべきです。

2つ目は、移行する際は全ての機能を網羅させることです。
先輩エンジニアの皆様に見せたら「当たり前」と言われてしまいそうですが、当時の私はデプロイさえできればOKだと思っていたので、Jenkinsで行っているタグの更新について軽視しており、ここで行っていることが全て移行できていることを確認していませんでした。
もし、全ての機能を網羅することを意識していれば、Jenkinsの機能調査でクエリパラメータの更新について気付けたはずだし、移行後に更新できていないことに気づいて修正できたはずです。

今回のこの失敗を記事に起こすことで、私と同年代の新人エンジニアの方々が少しでも同じ轍を踏まないことを願っています。