ブログ | 株式会社ジーニー Geniee,Inc.

2022 11.01

社内システム開発フローへのCI/CD導入とその活用

: ジーニー

技術トピック

Share

こんにちは、コーポレート本部の経営情報システム開発部でリーダーをしている近藤です。
ジーニーには新卒で入社して４年目になります。
私が所属しているチームでは社内システムの運用・保守を担当しているのですが、昨年にこのシステムへCI/CDを導入するプロジェクトを進めていました。
今回はこのプロジェクトについて書きたいと思います。

Contents
・CI/CD導入の経緯
・社内システムの問題点
・CI/CD導入の結果
・まとめ

１　CI/CD導入の経緯

まず私のチームで開発と運用・保守を担当している社内システムについて簡単に説明します。
このシステムの主な機能は、弊社のプロダクトであるGENIEE SSPやGENIEE DSP、GENIEE SFA/CRMなどの請求金額や支払金額を集計し、経理部が使用する財務会計システムへ連携することです。これにより計上業務の工数を削減することがこのシステムの大きな目的の1つとなっています。また支払先や請求先の情報を管理したり、反社チェック※1を自動で行う機能も持っています。
弊社の他プロダクトと比較するとそれほど大規模なプロダクトではないのですが、このシステムが停止すると月次の計上業務がほぼ停止してしまうため、とても重要なシステムです。
^{※1 反社チェックとは、弊社と新しく契約を結ぼうとしている個人や企業が反社会的勢力に関係していないかチェックをすること}

２　社内システムの問題点

この社内システムですが、様々な要因から開発をスムーズに進められない状態が続いていました。

■テストに膨大な工数がかかる
新しく機能を追加する際、テストにかなりの工数が必要となる状態になっていました。そもそも複雑なビジネスロジックが実装されていたり、外部の複数のシステムと連携する機能が存在するためどうしても大規模なテストが必要にはなるのですが、単体テストやE2Eテストが適切に実装されていれば手動で行うテストの工数を減らすことができます。ところがどちらのテストもメンテナンスされず動作しない状態であったため、小さいhotfixやリファクタリングであっても手動でのテストが必要でした。フレームワークのバージョンを上げる際はあらゆる機能に対して動作確認を行うテストが必要となり、定期的に膨大な工数を割いて作業に当たる必要がありました。

■DBのスキーマ管理が手動
DBのマイグレーションが導入されておらず、DB定義の管理を手動で行う必要がありました。これは自動テストを行う際に問題となり、本番環境で更新されたDBの定義を自動テストの環境へ手動で反映するというような作業が必要となっていました。
また、大規模な開発を複数人で進める場合には、最新のテーブル定義がどれなのか分からなくなるといった問題が起きていました。
実は、以前は自動テストが開発に活用されていました。しかしユニットテストの記述方法や自動テスト環境のメンテナンス方法などの情報が引き継がれないままメンバーが入れ替わってしまったため、辛うじて動作しているものの開発には全く活用されていない状態でした。
そこで改めてCI/CD環境を整備し、メンバー内で継続的に活用していける状態にしたいと考え、このプロジェクトを進めることになりました。

３　CI/CD導入の結果

このプロジェクトでは、主に以下の改善を行いました。これらについて順に詳細を書いていきたいと思います。
■自動テスト導入によりテストの工数を削減
■DBマイグレーションを導入し、スキーマの管理を自動化
■デプロイ時に発生する手作業を可能な限り削減

■自動テスト導入によりテストの工数を削減
私のチームではGitlabを使用しているため、CI/CDの環境はGitlabのCI/CDパイプライン機能を使って実現しました。作業中のブランチに対してコミットをpushすると自動でユニットテストが実行されるように設定しています。これにより実行されたユニットテストに通過していなければ、そのMRをマージできないようにもなっています。
ユニットテストは以前動いていたものを整備しました。具体的には使われなくなった機能のユニットテストを削除したり、メンテナンスされず壊れてしまったユニットテストを修正し、カバレッジは低いもののテスト全体が正常に通過する状態になりました。

■DBマイグレーションを導入し、スキーマの管理を自動化
DBマイグレーションを行うライブラリの導入と設定を行い、マイグレーションに用いるクラスファイルの配置と記述方法についてドキュメント化しチームに共有しました。
DB変更を伴う機能の開発は、DB変更が不要な開発に比べてかなり手間がかかる状態でしたが、これにより、ある程度解決できました。

■デプロイ時に発生する手作業を可能な限り削減
以前の開発フローでは、まず作業中のブランチをステージング環境にデプロイしたのち手動でテストを行い、通過した場合はマネージャーの承認を得てMRをマージし、本番環境へデプロイしたのち機能追加のお知らせをSlackで送るという流れになっていました。
これらが全てGitlab上で完結するよう、開発フローの変更とGitlab PipeLinesの設定を行いました。新しい開発フローでは、ステージング環境へのデプロイも、本番環境へのデプロイもGitlab上でジョブを実行するだけで完了します。機能追加のお知らせはMRから自動生成され、自動でSlackに投稿されます。
これらの変更は、一度リリース作業を行うだけならそれほど大きくない変更ですが、何度もリリース作業を行う場合には無視できない改善点になってきます。

４　まとめ

このプロジェクトを進めていて、たとえ小さな作業であっても、それを何度も繰り返す場合の負担は意外と大きくなるという気づきが得られました。逆に言えば何度も繰り返す作業であれば、細かい時間短縮であっても行ってみるべきで、実際の作業時間があまり変わらなかったとしても精神的に楽になったりすることはあると思います。
また、新しい開発フローをGitlab Pipelinesの設定に落とし込むところで時間がかかってしまったというのが反省点になります。ドキュメントを読むだけだと見落としている点に気づけなかったりもするため、実際に触ってみるのは重要だと感じました。

一緒に働く仲間募集中！
【ジーニーのリクルートサイトはこちら】
https://geniee.co.jp/recruit/