メニュー

DevOpsでの継続的インテグレーション

continuous integration devops

問題を排除するために楽器を試してください

DevOpsの継続的インテグレーションとは何ですか？

これまで、このトピックのパート1とパート2については、以前のセッションと現在はパート3で説明してきました。

soapuiテスト面接の質問と回答

パート2まで、DevOpsの人とプロセスの側面について説明しました。これは、コラボレーションであり、DevOpsの目的の達成に役立つチームの共通の目標、共通の考え方、共通の考え方に焦点を当てています。

開発における継続的インテグレーション

前回のチュートリアルでは、 DevOpsでコラボレーションを開発する方法 。

チェックアウト=> DevOpsに関する究極のガイド

継続的インテグレーション、継続的テスト、継続的デプロイ、継続的デリバリーは、DevOpsの主要な技術的側面です。

ビデオパート3ブロック1：継続的インテグレーション–12分20秒

トランスクリプト：

最後に一部では、アジャイル原則のどの部分がDevOpsプラクティスによって採用されているかを学ぶために、DevOpsのプラクティスを学びました。

これらの原則を通じて、DevOpsの目的はどのように達成されますか？

私たちは、バージョン管理、自動化、および顧客への小さな増分の価値の提供の重要性とその利点を研究しました。

DevOpsのコンテキストでのコラボレーションとは何ですか？それをどのように実現しますか？

これまで、DevOpsの人とプロセスの側面、つまりコラボレーションであり、DevOpsの目的を達成するのに役立つチーム内の共通の目標と共通の考え方と共通の考え方に焦点を当てることについて説明しましたが、今度はDevOpsのいくつかの技術的な側面について学びましょう。 、DevOpsリリースを可能にします。

それらは、継続的インテグレーション、継続的デリバリーとデプロイメント、および継続的テストです。

パート3のブロック1の一部として、最初に勉強しましょう '継続的インテグレーション'。

継続的インテグレーションとは何ですか？

継続的インテグレーション-> CI->一連のプロセス->ビルドパイプライン/ CIパイプライン

DevOpsで略して「CI」と呼ばれる継続的インテグレーションは、「BuildPipeline」または「CIPipeline」と呼ばれるパイプラインの一部として定義および実行される重要なプロセスまたは一連のプロセスです。

DevOpsの実践では、開発チームと運用チームの両方に単一のバージョン管理ツールがあり、全員のコードがマスターコードベースとして保管されるため、チームは並行して作業できます。

したがって、DevOpsでの継続的インテグレーションは、個々の開発者コードを、バージョン管理が維持されているメインブランチへのコードのマスターコピーにマージすることに他なりません。 1日に発生する必要のあるコードマージの回数に制限はありません。

開発者がコードをバージョン管理にチェックインすると、すぐにCIキックのプロセスが開始されます。

品質保証と品質管理の違いは何ですか

CIプロセスには以下が含まれます。

  1. すべての開発者コードをメインラインにマージし、
  2. ビルドをトリガーし、
  3. コードをコンパイルしてビルドを作成し、最後に…
  4. ユニットテストの実行。

したがって、継続的インテグレーションは、すべての開発者のコ​​ードを中央の場所にマージし、自動化されたビルドとテストを使用して各マージを検証するプロセスです。

CI中に何が起こるかを技術的に説明すると、

継続的インテグレーションのためのサーバーがあり、 CIツール 、コードチェックインのバージョン管理ツールを監視し続け、チェックインが見つかるとすぐに、自動コンパイルをトリガーし、静的コード分析と基本レベルの自動セキュリティテストとともに単体テストを構築して実行します。

Jenkins、TestNG、ユニットテストを実行するNUnit、静的コード分析を実行するSonar、セキュリティテストを実行する強化など、自動テストを実行するためのさまざまなツール。これらのツールはすべてCIパイプラインと統合されます。 。

したがって、完全なCIパイプラインは、手動による介入なしの自動化されたプロセスであり、数秒または数分以内に実行されます。

したがって、CIの主な利点は、開発者がすぐに受け取る迅速なフィードバックです。

  1. CIは、開発者がコードをチェックインした後に実行され、結果を数秒でスローします。そのため、開発者は自分のコードが正常にビルドされたか壊れたかをすぐに知ることができます。
  2. また、開発者は、自分のコードが他のコードと正常に統合されたか、壊れているか、別のチームメンバーがコードベースの別の部分に対して行ったことを知ることができます。したがって、CIはより迅速なコード分析を行い、後のマージをより簡単でエラーのないものにします。

つまり、CIは自動化されたプロセスであり、コードのチェックインごとにビルドがトリガーされ、コンパイルされ、ビルドが作成され、ビルドで自動化された単体テストが実行されます。

CIは、チーム内の全員のコードが適切または有効なコードであるかどうかを確認するCOPまたはプロセスと呼ぶこともできます。これは、CIプロセスがチェックインごとにすぐにコンパイルおよびビルドされ、不正なコードの場合はエラーをスローするためです。または、コンパイルできないか、自動化された単体テストケースを通過できません。

CIのメリットは何ですか？

まず第一に、CIプロセス全体が自動化されたプロセスであるため、バグを引き起こす長い手動マージを減らすことで、人的エラーを最小限に抑えます。

他の人がコーディングを完了するのを待たずに、1日に何度でもコードをチェックインでき、チェックインとその後のチェックインが完了するまで待つことができます。したがって、CIは依存関係を削除するか、他のユーザーがチェックインするまでの待機時間を削除します。

したがって、チームメンバーは、他のチームメンバーがチェックインを完了するのを待つ必要がないため、並行して作業することができます。

すべてのチェックインは、バージョン管理で収集されるだけでなく、ビルドの形成と自動テストによってすぐに認定されます。したがって、各チェックインは、さらに処理するためにルート自体で検証されます。

全員のコードがタイムスタンプ付きのマスターコピーにチェックインされ、適切に記録されているため、誰かのコードを見逃すことはありません。

コンパイル、ビルド、テストのプロセス全体が数秒で実行されるため、非常に高速かつ高速になり、多くの時間を節約できるため、数時間にわたってより高速に配信するというDevOpsの目標を達成するのに役立ちます。

ビルドとテストのプロセス全体が数秒から数分で実行されるため、個人のコードに関するフィードバックは非常に迅速であり、すべての場合と同様に、誰のコードがビルドを壊したか、欠陥を引き起こしたかを見つけるために走り回る必要はありません。チェックインすると、障害が発生した場合に障害の領域を示す成功または失敗の出力が表示されます。

したがって、これにより、開発者は少量のコードを断続的に（場合によっては1行のコードでも）チェックインして、エラーがないことを確認し、開発者が自分のコードが優れていること、また他のコードを壊さないことを確信できます。コード。したがって、これは全体として、コードの品質を向上させるのに役立ちます。

ここで一時停止して、今後のビデオチュートリアルで継続的デリバリーと継続的テストを取り上げましょう。

前のチュートリアル | 次のチュートリアル

推奨読書

^