Continuous-integration-reducing-risks

継続的な統合-リスクの低減

プロジェクトで問題が発生する可能性があります。 CIを効果的に実践することにより、プロジェクトが開発サイクルに入った後ではなく、途中のすべてのステップで何が起こるかを知ることができます。 CIを使用すると、リスクが発生した場合にリスクを特定および軽減できるため、具体的な証拠に基づいてプロジェクトの健全性を評価および報告することが容易になります。

このセクションでは、継続的インテグレーションを使用することで回避できるリスクに焦点を当てます。

どのプロジェクトでも、管理する必要のある多くのリスクがあります。 開発ライフサイクルの早い段階でリスクを排除することにより、システムが実際に稼働するときに、これらのリスクが後で問題に発展する可能性が低くなります。

リスク1 –展開可能なソフトウェアの欠如

「私のマシンでは動作しますが、別のマシンでは動作しません」 –これは、おそらくソフトウェア組織で見られる最も一般的なフレーズの1つです。 毎日ソフトウェアビルドに加えられる変更の数のため、ソフトウェアのビルドが実際に機能するかどうかについてほとんど自信がない場合があります。 この懸念には、次の3つの副作用があります。

• ソフトウェアを構築できるかどうかについては、ほとんどまたはまったく自信がありません。
• ソフトウェアを社内（テストチームなど）または社外（顧客など）に提供するまでの長い統合フェーズ。その間は何も行われません。
• テスト可能なビルドを作成および再現できない。

溶液

IDEとビルドプロセス間の密結合を排除します。 ソフトウェアを統合するためだけに別のマシンを使用してください。 ソフトウェアのビルドに必要なものがすべてバージョン管理リポジトリに含まれていることを確認してください。 最後に、継続的インテグレーションシステムを作成します。

Continuous Integrationサーバーは、バージョン管理リポジトリの変更を監視し、リポジトリへの変更を検出するとプロジェクトビルドスクリプトを実行できます。 継続的インテグレーションシステムの機能を強化して、ビルドをテストで実行し、検査を実行し、開発およびテスト環境でソフトウェアを展開することができます。これにより、常に機能するソフトウェアを使用できます。

「データベースと同期できない」-開発者は、開発中にデータベースをすばやく再作成できないため、変更が難しい場合があります。 多くの場合、これはデータベースチームと開発チームの分離によるものです。 各チームは自分の責任に集中し、相互のコラボレーションはほとんどありません。 この懸念は、次の3つの副作用があります-

• データベースまたはソースコードを変更またはリファクタリングすることへの恐怖。
• さまざまなテストデータのセットをデータベースに追加するのが難しい。
• 開発およびテスト環境の維持が難しい（開発、統合、QA、テストなど）。

溶液

上記の問題の解決策は、バージョン管理リポジトリ内のすべてのデータベース成果物の配置が確実に実行されるようにすることです。 これは、データベーススキーマとデータの再作成に必要なすべてのものを意味します。データベース作成スクリプト、データ操作スクリプト、ストアドプロシージャ、トリガー、およびその他のデータベース資産が必要です。

データベースとテーブルを削除して再作成することにより、ビルドスクリプトからデータベースとデータを再構築します。 次に、ストアドプロシージャとトリガーを適用し、最後にテストデータを挿入します。

データベースをテスト（および検査）します。 通常、コンポーネントテストを使用して、データベースとデータをテストします。 場合によっては、データベース固有のテストを作成する必要があります。

リスク2 –ライフサイクルの後半で欠陥を発見

複数の開発者がソースコードに対して頻繁に発生する変更が非常に多いため、後の段階でしか検出できない欠陥がコードに導入される可能性が常にあります。 このような場合、ソフトウェアで後で欠陥が検出されるほど、欠陥を除去するのに費用がかかるため、これは大きな影響を与える可能性があります。

溶液

回帰テスト-これは、ソフトウェア開発サイクルの最も重要な側面であり、テストとテストを繰り返します。 ソフトウェアコードに大きな変更がある場合は、すべてのテストが実行されるようにすることが絶対に必須です。 そして、これは継続的インテグレーションサーバーの助けを借りて自動化できます。

テストカバレッジ-テストケースがコードの機能全体をカバーしていない場合、テストしても意味がありません。 アプリケーションをテストするために作成されたテストケースが完全であり、すべてのコードパスがテストされていることを確認することが重要です。

たとえば、テストが必要なログイン画面がある場合、ログインが成功するというシナリオのテストケースを作成することはできません。 ユーザーがユーザー名とパスワードの異なる組み合わせを入力するネガティブテストケースが必要であり、そのようなシナリオで何が起こるかを確認する必要があります。

リスク3 –プロジェクトの可視性の欠如

手動のコミュニケーションメカニズムでは、プロジェクト情報を適切な人にタイムリーに伝達するために、多くの調整が必要です。 隣の開発者に頼って、最新のビルドが共有ドライブ上にあることを彼らに知らせることは、かなり効果的ですが、あまりうまくスケールしません。

この情報を必要とする他の開発者がいて、休憩中または他の方法で利用できない場合はどうなりますか？ サーバーがダウンした場合、どのように通知されますか？ 電子メールを手動で送信することにより、このリスクを軽減できると考える人もいます。 ただし、これにより、情報が適切な人に適切なタイミングで伝達されることを保証できません。なぜなら、あなたが誤って関係者を除外し、一部の人がその時点で電子メールにアクセスできない可能性があるためです

溶液

この問題の解決策は、継続的インテグレーションサーバーです。 すべてのCIサーバーには、ビルドが失敗したときにトリガーされる自動メールを送信する機能があります。 すべての主要な利害関係者へのこの自動通知により、ソフトウェアの現在の状態を全員が確実に把握できます。

リスク4 –低品質のソフトウェア

欠陥があり、潜在的な欠陥があります。 ソフトウェアが適切に設計されていない場合、またはプロジェクトの標準に従っていない場合、または保守が複雑な場合、潜在的な欠陥が発生する可能性があります。 これをコードやデザインの匂いと呼ぶこともあります-「何かが間違っているかもしれないという症状」。

低品質のソフトウェアは、プロジェクトの延期された費用（納入後）のみであると考える人もいます。 プロジェクトの延期費用になる可能性がありますが、ユーザーにソフトウェアを提供する前に、他の多くの問題も発生します。 過度に複雑なコード、アーキテクチャに従わないコード、および複製されたコード-すべては通常、ソフトウェアの欠陥につながります。 これらのコードやデザインの匂いを発見してから欠陥を発見することで、時間と費用の両方を節約でき、より高品質のソフトウェアにつながる可能性があります。

溶液

CIソフトウェアと統合できるコード品質チェックを実行するソフトウェアコンポーネントがあります。 これは、コードが実際に適切なコーディングガイドラインに準拠していることを確認するために、コードのビルド後に実行できます。