DevOpsを活用した本格的な自社開発の構築方法 - VTB体験

DevOps プラクティスは機能します。 リリースのインストール時間を 10 分の 90 に短縮したときに、私たち自身もこれを確信しました。 VTB で使用している FIS プロファイル システムでは、インストールにかかる時間は 10 分ではなく XNUMX 分になりました。リリースのビルド時間は XNUMX 週間から XNUMX 日に短縮されました。 永続的な実装上の欠陥の数は、ほぼ最小限にまで減少しました。 「肉体労働」から抜け出し、ベンダーへの依存を排除​​するために、私たちは松葉杖をつきながら、予想外の解決策を見つける必要がありました。 カットの下には、本格的な社内開発をどのように構築したかについての詳細なストーリーが記載されています。

 

プロローグ: DevOps は哲学です

過去 XNUMX 年間、私たちは VTB での DevOps プラクティスの内部開発と実装を組織するために多くの作業を行ってきました。

• 私たちは 12 のシステムの内部開発プロセスを構築しました。
• 私たちは 15 のパイプラインを立ち上げ、そのうち XNUMX つは本番稼働しました。
• 自動化された 1445 のテスト シナリオ。
• 私たちは社内チームが準備した多数のリリースを無事に実装できました。

DevSecOps 実践の社内開発と実装を組織化するのが最も難しいものの XNUMX つは、非リレーショナル DBMS 上の小売製品プロセッサである FIS プロファイル システムであることが判明しました。 それにもかかわらず、私たちは開発を構築し、パイプラインを起動し、製品に個別の非リリース パッケージをインストールし、リリースを組み立てる方法を学ぶことができました。 このタスクは簡単ではありませんでしたが、興味深いもので、実装に明らかな制限はありませんでした。システムは次のとおりです。社内開発を構築する必要があります。 唯一の条件は、本稼働環境の前に CD を使用することです。

最初は、実装アルゴリズムは単純かつ明確に見えました。

• 私たちは初期開発の専門知識を開発し、重大な欠陥のないコードチームから許容可能なレベルの品質を達成します。
• 私たちは可能な限り既存のプロセスに統合します。
• 明らかなステージ間でコードを転送するには、パイプラインを切断し、その端の XNUMX つを継続にプッシュします。

この期間中に、必要な規模の開発チームはスキルを開発し、リリースへの貢献の割合を許容可能なレベルまで増やす必要があります。 それで、タスクは完了したと考えることができます。

これは、必要な結果に至るまでの完全にエネルギー効率の高い方法であるように思われるでしょう。ここに DevOps があり、ここにチームのパフォーマンス指標があり、ここに蓄積された専門知識があります...しかし、実際には、DevOps は依然として哲学に関するものであるという別の確認を受け取りました。であり、「gitlab プロセス、ansible、nexus、およびリストのさらに下位に関連付けられている」ものではありません。

改めてアクションプランを分析したところ、自分たちの中に一種のアウトソーシングベンダーを構築していることに気づきました。 したがって、プロセスのリエンジニアリングが上記のアルゴリズムに追加され、また、このプロセスで主導的な役割を果たすための開発ルート全体に沿った専門知識の開発が追加されました。 最も簡単な選択肢ではありませんが、これがイデオロギー的に正しい発展の道です。
 

社内開発はどこから始まるのでしょうか? 

あまり使いやすいシステムではありませんでした。 アーキテクチャ的には、これは XNUMX つの大規模な非リレーショナル DBMS であり、必要に応じて呼び出される多くの個別の実行可能オブジェクト (スクリプト、プロシージャ、バッチなど) で構成され、ブラック ボックスの原則に基づいて動作します。つまり、リクエストを受信して​​発行します。応答。 注目に値するその他の問題としては、次のようなものがあります。

• 外来言語 (MUMPS);
• コンソールインターフェース。
• 一般的な自動化ツールやフレームワークとの統合が欠如している。
• データ量は数十テラバイト。
• 2 時間あたり XNUMX 万回を超える操作の負荷。
• 重要性 - ビジネスクリティカル。

同時に、私たちの側にはソースコードリポジトリがありませんでした。 まったく。 文書はありましたが、主要な知識と能力はすべて外部組織の側にありました。
私たちは、その機能と低分散性を考慮して、ほぼゼロからシステムの開発をマスターし始めました。 2018 年 XNUMX 月に開始:

• コード生成のドキュメントと基本を学習しました。
• 私たちはベンダーから受けた開発に関する短期コースを学びました。
• 初期開発スキルを習得。
• 私たちは新しいチームメンバーのためのトレーニングマニュアルを作成しました。
• 私たちはチームを「戦闘」モードに含めることに同意しました。
• コードの品質管理に関する問題を解決しました。
• 開発ブースを開催しました。

私たちは 2019 か月かけて専門知識を開発し、システムに没頭しました。XNUMX 年の初めから、社内開発は、時には困難を伴いながらも、自信を持って目的を持って明るい未来に向けて動き始めました。

リポジトリの移行と自動テスト

最初の DevOps タスクはリポジトリです。 アクセスの提供についてはすぐに合意しましたが、トランク ブランチが 2 つある現在の SVN から、複数のブランチのモデルへの移行と Git Flow の開発を伴うターゲット Git に移行する必要がありました。 また、独自のインフラストラクチャを持つ XNUMX つのチームと、海外のベンダー チームの一部もいます。 XNUMX つの Git を使用して同期を確保する必要がありました。 このような状況では、それは XNUMX つの悪のうち小さい方でした。

リポジトリの移行は何度も延期されましたが、最前線の同僚の協力を得て XNUMX 月にようやく完了しました。 Git Flow では、まず物事をシンプルにすることに決め、ホットフィックス、開発、リリースを伴う古典的なスキームに落ち着きました。 彼らはマスター (別名 prod-like) を放棄することにしました。 以下では、このオプションが最適であることが判明した理由を説明します。 ベンダーに属する外部リポジトリ (XNUMX つのチームに共通) がワーカーとして使用されました。 スケジュールに従って内部リポジトリと同期します。 Git と Gitlab を使用すると、プロセスを自動化できるようになりました。

自動テストの問題は驚くほど簡単に解決されました。既製のフレームワークが提供されていました。 システムの特殊性を考慮すると、別のオペレーションを呼び出すことはビジネス プロセスの理解可能な部分であり、同時に単体テストとしても機能しました。 残っているのは、テスト データを準備し、スクリプトの呼び出しと結果の評価の順序を設定することだけです。 運用統計、プロセスの重要性、既存の回帰手法に基づいて作成されたシナリオのリストが記入されると、自動テストが登場し始めました。 これでパイプラインの構築を開始できるようになりました。

どうだった: 自動化前のモデル

導入プロセスの既存のモデルは別の話です。 各変更は、個別の増分インストール パッケージとして手動で転送されました。 次に、Jira への手動登録と環境への手動インストールが行われました。 個々のパッケージについては、すべてが明確に見えましたが、リリースの準備では、事態はさらに複雑になりました。

組み立ては、独立したオブジェクトである個々の納品レベルで実行されました。 いかなる変更も新たな配信となります。 とりわけ、メイン リリース構成の 60 ～ 70 のパッケージに 10 ～ 15 の技術バージョンが追加されました。これらのバージョンは、リリースに何かを追加または除外し、リリース以外の売上の変化を反映するときに取得されます。

配信内のオブジェクトは互いに重複しており、特に実行可能コードでは重複しており、固有性は半分以下でした。 すでにインストールされているコードと、インストールが計画されているコードの両方に多くの依存関係がありました。 

必要なバージョンのコードを入手するには、インストール順序に厳密に従う必要があり、その間にオブジェクトが物理的に何度も (10 ～ 12 回ほど) 書き直されました。

一連のパッケージをインストールした後、手動で指示に従って設定を初期化する必要がありました。 このリリースはベンダーによってアセンブルおよびインストールされました。 リリースの構成は、実装のほぼ直前に明確になり、「分離」パッケージの作成が必要になりました。 その結果、供給品のかなりの部分が「デカップリング」という独自の尾部を伴ってリリースからリリースへと移動しました。

このアプローチ (パッケージ レベルでリリース パズルを組み立てる) では、単一のマスター ブランチには実際的な意味がなかったことが明らかです。 本番環境へのインストールには、手作業で XNUMX 時間半から XNUMX 時間かかりました。 少なくともインストーラー レベルでオブジェクト処理の順序が指定されていたのは良いことです。フィールドと構造体は、それらのデータとプロシージャの前に入力されました。 ただし、これは別のパッケージ内でのみ機能しました。

このアプローチの論理的な結果は、オブジェクトの不正なバージョン、不要なコード、命令の欠落、およびオブジェクトの相互影響が考慮されていないという形での必須のインストール上の欠陥であり、リリース後に熱心に排除されました。 

最初の更新: アセンブリと配信のコミット

自動化は、次のルートに沿ってパイプを介してコードを送信することから始まりました。

• 完成した納品物を保管場所から受け取ります。
• 専用の環境にインストールします。
• 自動テストを実行します。
• インストール結果を評価します。
• テスト コマンド側で次のパイプラインを呼び出します。

次のパイプラインは、Jira にタスクを登録し、選択されたテスト ループにコマンドが配布されるのを待機する必要があります。これは、タスクの実装のタイミングによって異なります。 トリガー - 指定された住所への配達の準備ができていることに関する手紙。 もちろん、これは明らかな要点でしたが、どこかから始めなければなりませんでした。 2019 年 XNUMX 月に、コードの転送は環境のチェックから始まりました。 プロセスは始まりました。残っているのは、それを適切な形にすることだけです。

• 各変更は、インストール パッケージに対応する個別のブランチで実行され、ターゲットの master ブランチにマージされます。
• パイプラインの起動トリガーは、マージ リクエストを通じてマスター ブランチに新しいコミットが出現することですが、これは社内チームのメンテナによって閉じられます。
• リポジトリは XNUMX 分ごとに同期されます。
• ベンダーから受け取ったアセンブラを使用して、インストール パッケージのアセンブリが開始されます。

この後、コードをチェックして転送し、パイプを起動してこちら側で組み立てる既存の手順がすでにありました。

このオプションは XNUMX 月に開始されました。 移行の難しさにより、ベンダーと現場の間で多少の不満が生じましたが、翌 XNUMX か月間かけてすべての荒削りな点を取り除き、チーム間でプロセスを確立することができました。 これで、コミットと配信によるアセンブリが可能になりました。
40 月には、パイプラインを使用して本番環境への個別のパッケージの最初のインストールをなんとか完了しました。XNUMX 月以降、例外なく、個別の非リリース パッケージのすべてのインストールは CD ツールを通じて実行されました。 さらに、ベンダーよりも小規模なチームで、リリース構成の XNUMX% で社内タスクのシェアを達成することができました。これは明らかな成功です。 最も重要な作業は、リリースを組み立ててインストールすることです。

最終的な解決策: 累積インストール パッケージ 

私たちは、ベンダーの指示をスクリプト化するのはまあまあの自動化であることを十分に理解しており、プロセス自体を再考する必要がありました。 解決策は明白で、必要なバージョンのすべてのオブジェクトを含む累積供給をリリース ブランチから収集することでした。

私たちは概念実証から始めました。過去の実装の内容に従ってリリース パッケージを手作業で組み立て、環境にインストールしました。 すべてがうまくいき、コンセプトは実現可能であることがわかりました。 次に、初期化設定をスクリプト化してコミットに含めるという問題を解決しました。 輪郭更新の一環として、新しいパッケージを準備し、テスト環境でテストしました。 実装チームからはさまざまなコメントがありましたが、インストールは成功しました。 しかし重要なことは、XNUMX 月のリリースでアセンブリとともに実稼働を開始する許可が与えられたということです。

残り XNUMX か月強という状況で、厳選された物資は明らかに時間がなくなっていることを示唆していました。 彼らはリリース ブランチからビルドを作成することにしましたが、なぜ分離する必要があるのでしょうか? Prod のようなものはなく、既存のブランチは役に立ちません。不要なコードがたくさんあります。 緊急にプロッドのようなものを削減する必要がありますが、これは XNUMX 件を超えるコミットです。 手作業で組み立てるという選択肢はまったくありません。 製品のインストール ログを実行し、ブランチへのコミットを収集するスクリプトを作成しました。 XNUMX 回目は正しく動作し、「ファイルで終了」するとブランチの準備が整いました。 

私たちはインストール パッケージ用に独自のビルダーを作成し、XNUMX 週間で完成させました。 次に、インストーラーはオープンソースであるため、システムのコア機能からインストーラーを変更する必要がありました。 一連のチェックと修正を経て、結果は成功したと見なされます。 その間に、リリースの構成が形になり、正しくインストールするにはテスト回路を製品版と調整する必要があり、そのために別のスクリプトが作成されました。

当然のことながら、最初のインストールについては多くのコメントがありましたが、全体的にはコードは機能しました。 そして、XNUMX 回目のインストール後、すべてがうまくいくようになりました。 オブジェクトの構成管理とバージョン管理は手動モードで個別に監視されましたが、この段階ではこれは非常に正当でした。

さらなる課題は、多数の未リリースを考慮する必要があることでした。 しかし、Prod のようなブランチとリベースを使用すると、タスクが透明になりました。

初めてでも、迅速かつエラーなしで

私たちは楽観的な姿勢でリリースに取り組み、さまざまなサーキットで十数件のインストールを成功させました。 しかし、文字通り締め切りの XNUMX 日前に、ベンダーが受け入れられた方法でリリースのインストールを準備する作業を完了していないことが判明しました。 何らかの理由でビルドが機能しない場合、リリースは中断されます。 さらに、私たちの努力を通じて、これは特に不快なことです。 我々には退却する術がなかった。 したがって、私たちは代替オプションを検討し、アクションプランを作成し、設置を開始しました。

驚くべきことに、800 を超えるオブジェクトで構成されるリリース全体が、初めて、わずか 10 分で正しく開始されました。 XNUMX 時間かけてログをチェックしてエラーを探しましたが、何も見つかりませんでした。

翌日はリリースチャットがずっと沈黙していました。実装の問題、不正なバージョン、または「不適切な」コードはありませんでした。 それはどこか気まずいものでさえありました。 その後、いくつかのコメントが出てきましたが、他のシステムや以前の経験と比較すると、その数と優先度は著しく低かったです。

累積的な効果によるさらなる効果は、組み立てとテストの品質の向上でした。 完全リリースを複数回インストールしたため、ビルドの欠陥と展開エラーがタイムリーに特定されました。 フルリリース構成でのテストにより、増分インストール中には現れなかったオブジェクトの相互影響における欠陥をさらに特定することが可能になりました。 特にリリースに対する 57% の貢献を考えると、これは間違いなく成功でした。

結果と結論

XNUMX 年も経たないうちに、私たちは次のことを達成することができました。

• エキゾチックなシステムを使用して本格的な社内開発を構築します。
• 重要なベンダーへの依存を排除​​します。
• 非常に不親切なレガシーのために CI/CD を起動します。
• 実装プロセスを新しい技術レベルに引き上げます。
• 導入時間を大幅に短縮します。
• 実装エラーの数が大幅に減少します。
• 自分を開発の第一人者であると自信を持って宣言してください。

もちろん、説明されている内容の多くは全くのくだらないように見えますが、これらはシステムの機能とそこに存在するプロセスの制限です。 現時点では、この変更は IS プロファイルの製品とサービス (マスター アカウント、プラスチック カード、普通預金口座、エスクロー、現金ローン) に影響を与えていますが、このアプローチは DevOps プラクティスの実装タスクが設定されているあらゆる IS に適用できる可能性があります。 累積モデルは、多くの配信からの後続の実装 (非リリースのものを含む) に対して安全に複製できます。

出所： habr.com