継続的インテグレーションの最初の一歩のために調べたこと、考えたこと

システムを作っていると、当然、バグが発生する。
これまで、プログラミング技術は重点的に勉強してきたが、実際のビジネスではプログラムをするだけではなく、バグをどの程度少なくするか、それをどのように運用するか、といった運用管理についても考えなくてはいけない。

継続的インテグレーションについて

CI/CDという言葉がある。
継続的インテグレーション、継続的デリバリーの略で、いかに効率的に運用管理を行うかといった手法や考え方のこと。
範囲は広範なため、詳細は書けないが、概念として、どういった範囲をカバーしているのか、を以下に記載する。

テスト自動化

そのまま、テストを自動化していくこと。
テストにもユニットテスト、インテグレーションテスト、UIテスト、など、細分化され、それぞれのテスト自動化の手法、ツールもいろいろある。
プログラムのバグの発見が目的。

インフラ構築

インフラの構築にもCI/CDの概念がある。
最近はIaC(Infrastructure as Code)というインフラの構築をコード化する概念が流行しているらしい。
インフラの構築は、手動で実施している部分が多くドキュメント管理が主流だったことから、職人技になりやすかったことから脱却を目指した。
コードで管理していくことで、ナレッジの蓄積にもなっていく。

自動デプロイ

テスト後、本番環境に向けて自動でビルドとデプロイをしてくれる仕組み。
あまり、それ以上のことは調べられていない。

自分ができることは?

CI/CDで調べてみると、たくさんの概念やツールが出てくる。
ツールは自動化を実行してくれるものであって、何を自動化するのか、については、事前に自分で検討する必要がある。
また、途中で仕様が変更になれば、自動化の内容にも見直しが必要になってくるので、自動化のツールや手法自体を運用管理していく必要がある。

自分が関わっているシステム制作については、そもそも、サービスがほとんど成熟していない、関係者も少人数、という立ち上げたばかりの状態なので、まだ、手動テストでも対応できる状態にある。
ツール導入やテストコードを書いていくのは工数の観点からすると、時期は今ではないと思う。
ただし、自動化=核となる機能で変更になりづらい、ということであると思うので、将来のために、どこが核になるのか?を、今のうちから明確化し、継続に困らない仕組みを想定し始めることは大事だと思った。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です