自動化で革命を
産業革命。
イギリスに始まる機械制工場と蒸気力の利用を中心とした技術革新とそれに伴う社会の変化。
https://www.y-history.net/appendix/wh1101-000.html
激変とまでは行きませんが、CI/CDの導入によって、時間や開発手法が変わったりと多くの恩恵を受けることができました。
まさにチーム内の革命です。
今回は、約1年前に導入したCI/CDについてのお話をさせていただきます。
導入背景
導入以前は２つの問題を抱えていました。
１つ目は手動デプロイの手間が多いこと。
1スプリント2週間のなかで多いときは6つのアプリケーションをデプロイする必要があり、それぞれのEC2サーバー内に入ってデプロイコマンドを実行する必要がありました。
使っている言語やフレームワークが違う関係上、それぞれデプロイ手順が異なりドキュメントはあるもののそれなりに手間でした。
２つ目はstaging環境へのデプロイが手間になってしまっていた。
エンジニアの人数が少ないときはリリースするコードの量もそれほど多くなかったため、まとめて確認すれば問題なかったのですが、人数が増えるにつれ改修内容も増えていき本番相当の環境で確認しなければならない頻度が増えていきました。
当時もstaging環境はあったものの、確認のためにstaging環境へデプロイする必要があり、その手順は本番と同様のもので確認作業の度にデプロイすることが手間であったため大きな時間ロスとなっていました。
デプロイが自動化されたstaging環境を整えるためにも導入が必要だろうとCI/CDの導入をはじめました。
CI/CDとは
そもそもCI/CDとはなんなのか？詳細については、いろんな記事があるので引用させていただきます。
下記の記事にはこのようにあります。
CI/CDとは「Continuous Integration／Continuous Delivery」の略で、日本語では継続的インティグレーション／継続的デリバリーといいます。CI/CDは1つの技術を指すものでなく、ソフトウェアの変更を常にテストして自動で本番環境にリリース可能な状態にしておく、ソフトウェア開発の手法を意味します。CI/CDを取り入れると、バグを素早く発見したり、変更を自動でリリースしたりできるようになります。
https://codezine.jp/article/detail/11083
フクロウラボのブランチ運用について
フクロウラボでのCI/CDの説明に移る前にフクロウラボのブランチ運用についてお話します。
git flowに近い形で運用していますが、少しだけ変えて運用しています。
git flowと異なる点は、release branchesが存在しないことです。
developブランチへはリリースしないコードをマージしないようにしているので、バグフィックスなどもfeatureブランチとして扱えるためです。
常にリリース可能な状態を保っているので、developが存在しないとも言えるかもしれません。
こうしたブランチ運用を元に、
developへのマージをトリガーに、staging環境へデプロイを実行し、
masterへのマージをトリガーに、production環境へのデプロイを実行するようにしています。
CI/CDで使っているサービス
次にCI/CDの導入に伴い、フクロウラボで使っているサービスの一覧です。
CircleCI、AWS系のサービスを併用しています。
CI..ビルドテストをCircleCIに担当させ、
CD..ビルド・デプロイはAWS系のサービスに寄せています。
デプロイフロー
ここからのフローはデプロイ先が異なるだけで、production,staging共に同様のフローになっています。
画像のようなフローでデプロイを行っています。
フクロウラボではマージ前にCircleCIによるビルドテストを行います。
このビルドテストが通らない限り、マージできないようにgithub上で設定してあります。
masterもしくはdevelopへマージしたのをトリガーとし、CodePipelineを動かします。
sorceコードはgithub上にあるものを使用し、CodeBuildでビルドを行います。
ビルドが終わったらCodeDeployを使用して、保存したビルド結果をサーバー上にアップロードします。
その後、アプリケーションサーバの再起動など、必要な処理を行ってデプロイを終えます。
その他のデプロイ方法
プロジェクトによっては、AWS Code三兄弟を使わず、CircleCIのみで完結しているものもあります。
例えば、LambdaへのデプロイやAWS ECSのFargate 起動タイプモデルについてはAWS CLIやCloudFormationなどを利用し、CircleCI上からコマンドを実行し、特定ブランチ(master,develop)へのマージをトリガーにデプロイを完結させています。
通知設定について
slackを使って通知の設定を行っています。
AWS CloudWatchEventsとAWS Lambdaを使用して、開始、失敗、成功を検知し、slackにポストします。
受けられた恩恵
- hotfix対応が楽になり、簡単な対応は即リリース可能に。
- リリース作業のミス等なくなった。
- ビルド作業で詰まることがなくなった。
- リリースに使う時間が短縮
一番の恩恵はhotfix対応が楽になり、簡単な対応は即リリースできるようになったことでしょう。
viewや社内向けの改修など、影響度が少ないと見られるものについては即時リリースするように変更となりました。
また、デプロイ作業で発生していた対応工数もなくなり、リリースに関して感じる重さみたいなものは軽減された様に思います。
終わりに
産業革命が起こしたような社会的な現象。。。とまでは行きませんが、自動化によってチームに良い影響を与えました。
フクロウラボでは、更に良い革命を起こせるよう精進してまいります。
実装編を書きました！
https://developers.fukurou-labo.co.jp/ci-cd実装編/
こちらもご参考ください
/assets/images/4387760/original/efe3ba5d-4c9f-4873-b521-1738e80ecedc?1581036553)
コメントを残す