DevOps 実装の核心と 13 の経験のまとめ

前回の記事では、Devops の概念と、Devops を適用することで企業がもたらすメリットについて紹介しました。以下の記事を参照してください:

DevOps は企業のどのような問題を解決できますか?

次に、DevOps を実装するために解決する必要がある問題を紹介します。製品要件、開発、テスト、運用保守の観点からDevOpsを実装した実践経験を共有します。

コア

デプロイメント パイプラインのコア ソフトウェア開発プロセスは、顧客またはユーザーのアイデアを実際の使用可能な機能に変えるプロセスです。デプロイメント パイプラインはこのプロセスの一部であり、バージョン管理リポジトリからユーザーの手元にソフトウェアを自動的に提示することを指します。このプロセスには、コンパイルとビルド、コード チェック、アーティファクト ライブラリのアップロード、テストとデプロイメントなどが含まれ、これらのステージの実行は自動的に行われる必要があります。自動化の利点は、プロセスがより高速になり、繰り返し実行可能になり、信頼性が高まることです。パイプラインのデプロイの核心は、各ノードの直列接続として Jenkins を使用し、各プロセスノードで一連のツールを使用してパイプラインの自動化を実現することです。次の図に示すように:

13 体験

製品要件

1. 製品定義、マイルストーン計画、ユーザーニーズ分析

インパクトマップ、ユーザーストーリー、カンバンボードなどの方法を使用できます。

発達

2. コードの事前チェック

コードの事前チェックとは、静的チェック、コードレビュー、テスト、コンパイルなどの方法を含め、コードをコードリポジトリに送信する前にチェックすることです。

3. 技術的負債の管理

技術的負債の主な種類は次のとおりです。

ドキュメントがないか、バージョンと同期していません。

時代遅れの建築デザイン。

リファクタリングが必要なコード。

レガシー コードにはドキュメントとユニット テストが不足しており、誰もそれを変更できません。

注: 実装されていない機能要件は技術的負債としてカウントされません。

技術的負債管理の中核は、技術的負債が発生する前にそれを回避すること、回避できない場合はツールを使用して事前にそれを発見すること、そして発見された技術的負債をできるだけ早く返済することです。

4. サードパーティコンポーネントの管理

サードパーティのコンポーネントを使用すると、「車輪の再発明」をする必要がなくなり、時間と労力を節約し、ソフトウェア開発プロセスをスピードアップできます。サードパーティ コンポーネントはソフトウェア開発に不可欠な要素となっています。ただし、サードパーティのコンポーネントを使用するのは簡単ではありません。主な問題は次のとおりです。

コンポーネントに欠陥やセキュリティ上の脆弱性が含まれている可能性があります。

コンポーネントのバージョンが古くなる可能性があります。

コンポーネントには追加のメンテナンスコストが必要です。

一般に、サードパーティ コンポーネントを管理する場合は、次の 2 つの側面を考慮する必要があります。

依存関係のスキャン: セキュリティ上の脆弱性があるかどうか、バージョンが古くなっているかどうかなど、依存関係に関する問題をスキャンできます。

依存関係管理: ブラックリストとホワイトリストを作成し、ポリシーを制御し、影響範囲を決定します。ブラックリストとは、使用が許可されていないコンポーネントを指します。ホワイトリストは使用できるコンポーネントです。制御戦略とは、ブロックや警告など、コンポーネントの問題が発見されたときに講じられる対策を指します。影響範囲とは、現在のシステム、すべてのシステムなど、制御戦略の適用範囲を指します。依存コンポーネントにブラックリスト内のコンポーネントが含まれていることが検出された場合、コンパイル失敗、担当者へのメール通知など、設定された制御戦略に従ってコンポーネントの処理が行われます。

5. 非機能要件の管理

非機能要件は実装にコストがかかり、相互に排他的である可能性があるため、長所と短所を比較検討する必要があります。たとえば、セキュリティ要件が高いシステムは、使いにくいことがよくあります。実際の開発では、システムの納期とシステムの総コストを考慮し、非機能要件の実装難易度でトレードオフが行われることが多いです。

6. API管理

API 管理とは、企業内のさまざまなサービスが提供する API インターフェースや外部に公開される共有インターフェースを効果的に管理し、API インターフェースの作成、テスト、リリースなどのライフサイクルや API インターフェースのバージョンを管理し、開発者が閲覧できる API 開発者ポータルを提供することです。サービスの API インターフェースは、構築時に API 管理プラットフォームの API ゲートウェイに自動的に登録されます。他の呼び出し元は、API ゲートウェイを介してこれらのインターフェースによって提供されるサービスにアクセスし、API ゲートウェイに基づいて API の自動テストを実行して、API の正確性と堅牢性を確認できます。

7. 構成管理

構成管理とは、プロジェクトに関連するすべての成果物とそれらの関係を一意に定義、変更、保存、および取得するプロセスを指します。たとえば、Git に基づいて、アプリケーションをデプロイするときに環境固有の構成ファイルを提供し、コードを構成から分離して、コードの一意性を確保できます。

8. 継続的インテグレーション

ここでの「継続的に」という言葉は、「常に、ずっと」という意味ではなく、「いつでも」という意味です。より適切な頻度は、誰かがコードを送信するたびに、それが 1 回統合されることです。通常、即時統合とスケジュール統合に分けられます。

ジャストインタイム統合: チームメンバーがコードを送信するたびに統合が実行され、コンパイル、ビルド、自動テストなどのタスクが実行され、個人が送信したコードが利用可能かどうかが確認されます。この統合方法では実行時間が短く、結果のフィードバックが迅速である必要があるため、いくつかの簡単なテストしか実行できません。

スケジュールされた統合: デイリービルドと同様に、統合プロセスが 1 日に 1 回 (通常は夜間) 自動的に実行され、実行結果が翌日に関係者に送信されます。この統合方法は、検出の包括性と徹底性に重点を置いており、実行時間が長く必要ありません。

テスト

9. テストデータ管理

テスト データ管理とは、テスト データの自動作成と破棄を指します。主に、基本的な業務機能を検証するための少量のテストデータと、コア業務のパフォーマンスを検証するために必要な大規模なテストデータが含まれます。

10. 自動テスト

製品のUIテスト、サービスのインターフェーステスト、テストコードを通じて実装されたコードの単体テストを指します。

オペレーション

11. リアルタイム監視

すべてのホストを監視に追加して、そのステータスを常に追跡します。インジケーターが異常になると、トリガーによってアラームがトリガーされ、WeChat、DingTalk、または電子メールで送信されます。

12 ログ収集

クラスタ環境が拡大すると、モジュールが複数のノードにデプロイされる可能性があり、マシンにログインしてモジュールのログを表示することが困難になります。通常、elk を通じて集中型のログ収集システムを確立し、すべてのノード上のログを均一に収集、管理、アクセスすることができます。

13 環境管理

環境管理とは、展開環境を準備し、展開後に環境を制御するプロセスです。準備環境のスピードと一貫性を確保し、展開された環境を効果的に活用できるようになります。一般的な環境は、統合環境、テスト環境、準本番環境、本番環境に分かれています。さまざまな環境を効率的に管理したい場合は、スクリプトを使用して環境を作成および展開する、つまりワンクリック展開を使用する必要があります。