メインコンテンツにスキップ
  1. TOP
  2. ALL
  3. CI/CDの経験:開発者の視点から見る変化

CI/CDの経験:開発者の視点から見る変化

この記事を書いた人
H.ソンヒ

こんにちは!
システム開発課のソンヒです。

今回のブログではCI/CDとは何か、私たちのプロジェクトでCI/CDをどのように導入したか、CI/CDを入れた結果どうだったかについて話したいと思います。

そもそもCI/CDって何

CI/CDはソフトウェアを開発する際にコードの変更を自動でビルド、テスト、デプロイするプロセスのことです。

大きくCI(Continuous Integration, 継続的インテグレーション)と CD(Continuous Deployment/Delivery, 継続的デプロイ/デリバリー)で分けます。

CI(継続的インテグレーション)

開発者が作成したコードをリポジトリにプッシュすると、自動でコードチェックとテスト、ビルドが実行されるプロセスです。

テストに問題がなければ次の開発プロセス(レビューやデプロイなど)に進むことができます。

CD(継続的デプロイ/デリバリー)

ビルドとテストを通ったコードが自動でデプロイされるプロセスです。

自動でデプロイされることをContinuous Deployment、人の承認があればデプロイすることをContinuous Deliveryといいます。

CI/CD を導入した理由

当初は「本当に役に立つのか」と疑いましたが、CI/CDを活用することで問題を解決できました。

新しいプロジェクトでは、最終的なレビューをステージ環境で行うことをルールとして定めました。

そのため、1つのPRが終わるたびにステージ環境にデプロイをする必要がありました。

プロジェクトには複数のリポジトリが存在し、サーバ環境もまた複数存在していました。

これまでのプロジェクトでは、デプロイをするためにソースコードを圧縮し、決められた環境にデプロイを実行する必要がありましたが、そのプロセスを利用するとヒューマンエラーが起こる可能性がありました。

このような状況において、CI/CDを導入することによって適切な環境に自動でデプロイされるようになり、ヒューマンエラーの防止と手間の軽減が期待できました。

また、PRを生成した時、マージした時、デプロイする時にテストが自動で走り、成功しないとデプロイされないため、自動テストさえ正しくコードが書ければより安全だと考えました。

PRを出す時もテストが強制されるので、レビューするコードの品質が向上するという利点もあったので導入を決定しました。

CI/CD導入方法

いざ、導入しようとするとなると、CI/CDをサポートするツールが数多く存在していたため、どのツールが最適か検討する必要がありました。

当初はJenkinsやGitLab CI/CDなどのツールも検討していましたが、Jenkinsの場合、初期設定やメンテナンスには多くの時間がかかり、GitLab CI/CDはGitHubとの統合性が不足していることを確認しました。

私たちのチームはすでにGitHubとAWSを使用していたので、新しいツールを導入するのではなく、簡単かつ素早く適用できるGitHub ActionsAWS CodePipelineを活用することにしました。

GitHub Actionsの場合、簡単なコードをリポジトリ内に追加するだけで、コードのプッシュ時に自動テストを実行することができましたし、AWS CodePipelineも追加のインフラ構成なしですぐ適用できたので早く導入できました。

※作成したPRのレビューが終わって、指定のブランチにマージするとテストとビルド、デプロイまで自動で行われます。

CI/CDを導入した結果

「PRマージ → ビルドgulp実行→zipアップロード→デプロイ実行」の工程が「PRマージ」のみでステージ環境にデプロイすることができました!

本番環境のリリースの際にも、ボタン一回でリリースできる状態になりました!

期待した通りの結果を得ることができました。以下に簡単にまとめます。

1.コード変更時に自動でテストを実行し、レビュー前に基本的なエラーを検出できる

phpstanによる静的分析、lintを使ったコードスタイル検査も行うため、レビュー前のコードの品質が上がる

2.人が行う作業で発生するデプロイ時のミスを防ぎ、デプロイの速度も向上する

既存の方法では古いバージョンのデプロイや、別の環境でのデプロイなどのリス3. POやデザイナーなど開発者以外のメンバーが、迅速に確認・フィードバックできる。

3.POやデザイナーなど開発者以外のメンバーが、迅速に確認・フィードバックできる

別にデプロイを要求しなくても常に最新状態のステージ環境を確認できるため、コミュニケーションコストが減る。

4. 開発者のデプロイ関連の作業負担が減り、機能開発に集中できる

実装内容がブランチにマージされていることだけ確認できればCodePipelineでボタンをオスだけでリリースが可能になった。

まとめ

CI/CDを経験する前には今までのデプロイで十分だと考えていましたが、いざ経験してみたらコードの変更も早く反映できますし、デプロイのストレスも減って非常に便利でした。

正直、もっと早く使えばよかったなと思いました(笑)

もちろんプロジェクトごとに必要性が違うかもしれませんが、開発の速度と安定性を一緒に上げたい方には検討してみる価値が十分あると思います。

以上、システム開発課のソンヒでした。

私たちの仲間に
なりませんか?

何かを成し遂げたい人、何者かになりたい人、
毎日の仕事にわくわく取り組みたい人。
そんな方にとって最高の環境が待っています。