タスクの作業が開始された瞬間から、行われた変更が実行されるまでのプロセス全体を記述するのが最善だと思います。 そして、ストーリーの過程で、前回の記事で未回答のままであったすべての質問に答えようとします。
私たちの開発チームはプロセスの構築において完全な自由を享受しているため、すべてのチームが以下の説明に厳密に従って作業しているとは言えません。 もちろん、ツールボックスには特定の制限があります。 要するに。
銀行では、主なエラー追跡システムはJIRAです。 すべての改善、変更などのタスクを登録します。 開発者は、タスクを開始して、メインリポジトリからブランチを「カット」し、そのブランチで既に開発します。 以下は、かなり典型的なタスクの例です。
タスクを完了した後、開発者はBitbucketにpullbucket pullリクエストを開始して、メインブランチに変更を加えます。 そして、ここで彼は最初にパイプラインの現れに遭遇します：プルリクエストは自動コード修正のプロセスを開始します。
監査はSonarQubeを使用して実行され、BambooのSonarプラグインとBitbucketのSonarプラグインを介してパイプラインに統合されています。 Bambooでプルリクエストを登録すると、追加するブランチを分析するビルドプランが自動的に起動します。 分析の結果は、このフォームのプルリクエストに直接表示されます。
プルリクエストフォームでは、コードに含まれる新しいコメント、その重要度、カテゴリなどをすぐに確認できます。 コメント自体は、プルリクエストフォームから直接表示できます。Diffタブに移動してください。
したがって、コードの改訂プロセスが大幅に加速および促進され、さらにかなり多数の設定により、監査中のパイプラインの動作とその結果を非常に柔軟に制御できます。 監査が成功したとしましょう。次に進みます。
次の段階は、コードから必要かつ有用なものを組み立てることです。 Bambooではさまざまな方法でビルドが開始されます。 手動で可能です。リポジトリでのマージまたはコミット、スケジュール、またはBamboo Rest APIの呼び出しによっても自動的に可能です。 簡単でわかりやすいように、最も一般的なオプション-手でアセンブリを開始することを検討します。 これを行うには、Bambooに移動し、目的のプランを選択して、スタートを押します。
開始後、計画に示された依存関係に従って、アセンブリが実行される適切なエージェントが選択されます。 現在、30個のWindowsエージェント、20個のLinux、2個のiOSエージェント、さらに5個の実験とパイロット用のエージェントがあります。 エージェントの半分は内部クラウドにデプロイされますが、それについては後で詳しく説明します。 この量により、500を超えるアクティブアセンブリプランと約200の展開プロジェクトを継続的にサービスすることができます。
しかし、組み立て計画に戻ります。 パイプラインはすべての一般的なビルドツールをサポートし、そのリストはプラグインを使用して拡張できます。
アセンブリ自体は標準です。コードはエージェントに保存され、同じ場所でバイナリにコンパイルされ、適切なパッケージにパックされます。 モジュラーおよび統合まで、テストはオプションで接続されます。 アセンブリの最後に、アセンブリに含まれるコミット、実行されたテスト、結果、アセンブリに含まれるタスクなどに関する多くの有用な情報を含む美しいレポートを取得します。
アセンブリによって生成されたアーティファクトは、自動的にArtifactoryに配置されます。
一方では、このシステムは収集したアーティファクトの集中リポジトリとして使用され、他方では、Artifactoryを介して外部リポジトリのほとんどをプロキシします。これにより、アセンブリプロセスが大幅に高速化され、ネットワークの負荷が軽減されます。 組み立てるとき、外部リポジトリから依存関係をポンピングするのではなく、すべての依存関係についてArtifactoryを使用します。これは、組み立て計画の速度と安定性に非常によく影響します。
パッケージをArtifactoryに配置すると、必要な環境にインストールするなど、パッケージで何でもできます。 通常、チームは3つの環境を使用してソフトウェアを作成します。 開発環境-開発およびデバッグに使用される開発環境。 テスト環境-アプリケーションの機能および統合テストに使用されます。 プレビュー環境-顧客による機能の受け入れと負荷テストに使用。 原則として、運用上の使用条件に最も近い。 一部のチームは、実稼働環境にインストールする前に、昨日の作業環境のコピーにインストールすることを決定しました。これは、問題の特定にも役立ちます。
チームは、サポートとともに、誰がどの環境にインストールするかを決定します。ここでは、ほとんどすべてのオプションを使用します。 開発者のみが展開を担当するチームがあります（hello、DevOps！）。 開発者が開発とテスト、およびサポートのみを更新するチームがあります-プレビューと製品版。 通常、一部のチームには、すべての環境にインストールする専任のスタッフがいます。
デプロイ可能なプロジェクトは、特定のビルド計画に関連付けられた一連の環境です。
環境には、環境ごとに個別に構成された環境固有の変数が含まれています。 前回の記事へのコメントには、パスワードの保存方法に関する質問がありました。 スクリーンショットでわかるように、それらをアセンブリおよび展開計画のパラメーターに保存します。 Bambooにはパスワード暗号化メカニズムがあります。変数名にpasswordという単語を使用すると、暗号化されます。 保存した後、そのような変数の値はインターフェースから表示したり、実行ログで表示したりすることはできなくなり、常にアスタリスクで「マスク」されます。
この環境には、変数に加えて、ターゲットホストにアプリケーションをインストールするために必要な一連のアクションを記述するタスクの形式で実装された実行可能部分が含まれています。 リストはすべての標準ツールをサポートし、プラグインを使用して拡張できます。
実行結果に応じて、タスク、コミット、アセンブリなどのネストレベルと相互参照レベルを含む詳細な実行ログも取得します。
本番環境でのインストールについては、おそらく個別に話す必要があります。 銀行には変更登録プロセス（CM）があり、それに応じて、生産のすべての変更を事前に発表して同意する必要があります。 変更を登録するために、チームはインストールの少なくとも3日前に変更管理要求（CRQ）を開始します。 さまざまなテストレポートがこのCRQに適用され、承認者の印象的なリストが生成されます。 プロセスは非常に遅くて面倒です...しかし、私たちは銀行のITに関する神話を払拭します
私たちには、ビジネスとサポートとともに、すべてを非常にうまく行っており、いつでも生産に変更を加える準備ができていると判断したチームがあり、これは悲惨な結果につながりません。 特にそのようなチームでは、生産システムの変更の登録と承認を簡素化するプロセスが考案されました。このプロセスでは、いつでも生産を変更し、実行された作業の事実に基づいてCRQを登録することができます。 ただし、一部のアプリケーションを手動で作成する必要がある場合は、どのようなCI / CDです...したがって、Bamboo用の独自のプラグインを作成しました。これにより、展開計画に組み込まれたCRQを自動的に登録できます。
現在、変更の登録および承認のプロセス全体には数分かかり、手動の介入は不要です。 ところで、この新しいプロセスに取り組んでいるチームはすでに12を超えており、その数は着実に増加しています。 そのため、銀行のようなかさばる保守的な組織では、IT分野のベストプラクティスをうまく実装できます。
展開プロセスについて話す現代の現実では、クラウドなどを無視することはできません。 すでに書いたように、VMWare vRealizeに基づく内部クラウドがあります。 これは、非産業環境と本番環境の両方で使用されます。 また、独自の別のプラグインを使用して、クラウドをパイプラインに統合しました。 Bambooを使用して、クラウドでサーバーを作成または削除できます。
たとえば、必要な数のサーバーを作成し、必要なソフトウェアをすべてインストールし、監視システムに登録する展開計画を実行するだけで、クラウドでBambooエージェント用の上記のサーバーを2週間ごとに再作成します。 この操作には約100時間以上のアプリケーションがインストールされているため、約2時間かかります。
したがって、ボックス化された統合と少しのカスタマイズのおかげで、すべてのタスクを解決できるCI / CDパイプラインを構築することができました。 しかし、何も静止していません。 現在、私たちは（すべての進歩的な人類と同様に）パイプラインとchatopsツールの統合、コンテナーの使用、パイプライン自体に関連するプロセスの自動化に積極的に取り組んでいます。
前回の記事へのコメントでは、CI / CDまたはパイプラインのいずれにも関連しない多くの質問が寄せられました。 そのため、質問と回答の形式で回答します。 おそらく、答えは単調に見えるでしょう。 しかし、銀行には、さまざまなOS向けにさまざまなテクノロジーを使用して、さまざまな時点で記述された700を超えるアプリケーションがあるため、明確な答えを出すことはできません。ほとんどの場合、すべてはアプリケーションとそのチームによって決定されます。
どの展開スキームが使用されていますか？ （緑/青、ローリング、カナリアなど）。 そして、あなたがロールバックする必要がある場合は？
特定のアプリケーションに依存します。 私の知る限り、間違いなく緑/青とローリングがあり、残りについてはわかりません。 チーム自身が最適な展開オプションを選択します。 ロールバックする必要があり、これが可能な場合は、ロールバックします。
展開の成功に関する決定はどのようにして誰によって行われますか？ どのパラメーターに基づいていますか？
これが何であるかは明らかではありません。 展開プロセス自体の場合、Bambooプランがエラーなしで機能する-うまく機能しなかった-エラーなしで決定されます。 質問がインストールされる変更の機能コンポーネントに関するものである場合、ビジネス顧客はインストール後の煙テスト中に決定を下します。
負荷が増加した場合はどうなりますか？ サーバーを追加して負荷を保持するのは簡単ですか？ 自動スケーリングはありますか？
ワークロードに関しては、いつものように、アプリケーションと多くの多くの多くの要因に依存します。 自動スケーリングは使用されません。
新しい展開はそれぞれ、新しく作成されたサーバーで実行されますか、それとも同じサーバーで実行されますか？
アプリケーションに依存します。 私たちのチームは2週間ごとにサーバーを再作成し、新しいサーバーにのみ展開します。 他のチームは常に同じサーバーに展開します。 チーム自身がアプローチを選択します。
オペレーティングシステムのパッチはどうですか？
アプリケーション、OS、アップデートに依存します。 しかし、最終的に、すべての重要な修正プログラムをインストールし、脆弱性はありません。
監視とアプリケーションおよびシステムメトリック（OS）についてはどうですか？
監視のトピックは、監視の専門家が作成する別の大きな記事に値します。 監視、警告作業、インシデントの記録と処理があり、処理の一部が自動化されていると言えます。
アプリケーションコピー間で負荷を分散するために何を使用しますか？ nginx / haproxy / etc？
アプリケーションによって異なりますnginx、haproxy、NLB、およびCiscoがあります。