私たちのチームは、大企業向け製品の運用と開発を担当しています。

2017年の初めに、主要な実装から休憩を取り、「学んだ教訓」を読み直し、アプリケーションの開発と配信を再検討することにしました。 配送の速度と品質が心配で、顧客が期待するレベルのサービスを提供することができませんでした。

言葉から行為に移行する時でした-プロセスを変えるために。

この記事では、どこから始めたのか、何をしたのか、現在の状況、どのような困難に直面したか、かっこを残さなければならないこと、他に何をする予定かについて簡単に説明します。

開始する

システムについて少し

このアプリケーションは、「2000年代の建築物流出」のモノリシックなエンタープライズアプリケーションの典型的な例です。

• 15年以上にわたって運用および開発されました。
• これは、単一のMS SQLデータベースに関連付けられた1ダースのWinForm、Windowsサービス、およびASP .Netアプリケーションのセットです。
• コードベースのサイズ：C＃で〜1MLOC、〜9000のデータベースオブジェクト。 ビジネスロジックの大部分はデータベース側で実行されます。
• アプリケーションは、win / webクライアントを作成するための約250以上のソリューションで構成されています（関連するフォームのグループごとに1つのソリューション）。 これは、以前の開発プロセスとクライアントアーキテクチャの遺産です。
• アプリケーションは、内部構成を変更することにより、いくつかのタイプのプロセス（クライアント）をサポートします。システムデータベース構成テーブルでプロセス、権限、フレキシブルフィールドなどを設定します。 同時に、アプリケーションコードベースはすべてのクライアントで同じです。
• アプリケーションは25以上のサイトに展開およびサポートされ（各サイトはシステムの独立したインスタンスです）、異なるタイムゾーンで合計数千のエンドユーザーにサービスを提供します。

変換前の配信プロセス

1. 完成したアプリケーションとそのコンポーネントの開発とアセンブリは、請負業者によって実行されます。
2. コードは請負業者の側に保存されました（MS TFSのローカルバージョン）。 コードは、メインリポジトリブランチの現在のバージョンのアーカイブの形式で、毎月顧客に送信されます。
3. 配信は、「デルタ更新」の配信によって実行されました。アプリケーション（dll、exeなどのセット）およびデータベースコンポーネント（sqlスクリプトのセットの作成/変更）用です。 アプリケーションが構築され、デルタパッケージが請負業者によって準備されました。
4. 展開プロセスはトランスポートシステムによってサポートされ、変更は自動的に適用されました。

配信は毎月のリリースの一部として実行されます（私がそれを整理したので、私は以前にここであなたに言った ）。

既存の問題

コントロールの欠如

• コードの正式な所有権にもかかわらず、顧客によるアプリケーションの実際のアセンブリは不可能でした。
• その結果、顧客に送信されたコードの操作性を検証することはできません。
• コードの変更-顧客には見えません。 製品の要求された変更と実際の変更を一致させることはできません。
• コード分​​析はSQLでは難しく、C＃コンポーネントでは不可能です

労働投入とエラー

• 「デルタパッケージ」の準備は、開発のための時間のかかる手順であり、エラーの原因と特定のプロジェクトコストです。
• Delta Packetアプリケーションを展開するには、パッケージの順序を追跡する必要があります。 パケット異常エラーは、重大な展開の問題であり、重大なインシデントの原因です。
• 回帰が定期的に発生します。修復されたと思われるエラーが修正され、製品の修正がロールアウトされました。

制限事項

• 過去のある時点でシステムの状態を復元する機能（変更をロールバックする機能）は実質的にありません。
• 顧客の従業員を引き付けることにより、開発と初期のテストリソースを効果的に拡張する機能は実質的にありません。

期待される結果

プロジェクトの開始時に、上記の問題を解決するための明確な目標を設定しました。

• コードリポジトリを顧客管理に転送する
• アプリケーションビルドプロセスを顧客側に移動する
• 変更の配布プロセスを変更し、完全な更新を優先して「変更のデルタ」を放棄する

さらに、最初の2つの目標が達成されたときに得られたソリューションを使用して、以下を計算しました。

• コード管理により、結果として生じるソリューションの技術的品質を向上させます
• セルフサービス展開を提供することにより、テストの関与と使いやすさを向上させます。

長い道のりの段階

開発プロセスの現状の分析

最初のステップ：既存の請負業者の開発プロセスを分析します。 これは、可能であれば作業を中断しないように、変更を計画するのに役立ちました。

残念ながら、開発プロセスに精通しているため、現在のIT業界の理解では、プロセスは存在しませんでした。

1. データベースコードとそのビジネスロジックは、現在の状態のリポジトリではサポートされていませんでした。 主な理由：リポジトリ内のコードからアセンブリを実装するツールの欠如と結果の展開。 したがって、リポジトリ内のコードは単なるドキュメントです。
2. データベースコードの「実際の」バージョンは、多くの開発者が作業する共通の「開発データベース」にあります。
3. クライアントアプリケーションコード（C＃、ASP.NET）はリポジトリで維持されましたが、コミットの品質と適時性は保証されませんでした。
4. （アプリケーション全体ではなく）コンポーネントのアセンブリは、開発者のステーションで実行されました。 アセンブリの前にコードがどのように更新されたかは完全には明らかではありません。 組み立てられたコンポーネントは、共有共有フォルダーに配置されました。 そこから、顧客のために「デルタパッケージ」が形成されました。
5. 開発ブランチを維持するための実践の完全な欠如。 間接的な兆候によって、私たちはこれを長い間疑っていました-しかし、プロセスに飛び込んだ後、すべてが明らかになりました。

新しいリポジトリとバージョン管理システムへの切り替え

MSプラットフォームおよび企業標準への依存により、開発環境の選択が決定されました-Team Foundation Server。

ただし、プロジェクトを直接開始するまで（2017年4月）、Visual Studio Team Servicesのバージョンがリリースされました。 この製品は非常に興味深いようで、MSの戦略的方向として指定され、オンプレミスとクラウドのgitリポジトリ、アセンブリ、展開を提供しました。

企業のオンプレミスTFSはVSTSのバージョンと機能に遅れをとっていたため、新しいバージョンへの移行は議論の過程にありました。 待ちたくありませんでした。 プラットフォームをサポートするためのオーバーヘッドコストを削減し、方法と操作を完全に制御できるため、すぐにVSTSに切り替えることにしました。

変更の開始時、開発チームはTFSVCの経験があり、アプリケーションコードはそのようなリポジトリに保存されていました。 一方、GITは長い間ITコミュニティの標準になっています。顧客とサードパーティのコンサルタントは、このシステムへの切り替えを推奨しています。

開発チームが新しいバージョン管理システムの決定に関与し、情報に基づいた選択をすることを望んでいました。

VSSVCに異なるリポジトリを持つ2つのプロジェクト-TFSVCとGITをデプロイしました。 各システムのユーザビリティをテストおよび評価するために提案された一連のシナリオが定義されました。

評価されたシナリオには次のものがあります。

• ブランチを作成してマージする
• 共同作業の組織（1つまたは異なるブランチで）
• チェーン操作の変更（コミット、取り消し）
• サードパーティの統合
• サーバーが利用できない場合でも機能し続ける機能。

その結果、予想どおり、GITが選択されましたが、これまで誰も後悔していません。

プロセスとして、GitFlowの使用を開始しました。 このプロセスにより、従来どおり、変更を十分に制御でき、リリースの配信が可能になりました。

1. 開発ブランチは、すべての変更がプルリクエストを通過することを要求するポリシーで保護されました。
2. 「1つのチケット-1つのプル要求」の慣行を厳守しようとします。 異なるチケットからの変更が1つの変更に結合されることはありません。 後続のプルリクエイクでの修正による状況を回避するために、機能ブランチでテストするために最善を尽くします。
3. 開発にマージすると、すべての変更が単一のコミット（スカッシュ）にマージされます。
4. リリースブランチは、developから作成されます。
5. 必要に応じて、リリースブランチで、最新の変更を選択的に追加（チェリーピック）またはすべて（リベース）できます。 リリースブランチで修正を直接実行することはありません。
6. 製品に最新リリースを展開した後、プッシュフォースを介してマスターになります（この権利を持っているのは少数の人だけです）

製品組立の自動化

アプリケーションは多数のアセンブリ、数百のソリューションでした。 プロセス監査中に判明したように、これらはすべて個別に「手動で」収集されました。

最初の段階では、（既存の配信を停止しないように）すべてをゼロからやり直すのではなく、msbuildスクリプトのセット（コンポーネントごとに1つのスクリプト）でアセンブリを「ラップ」することにしました。

したがって、必要なすべての中間成果物を実行するスクリプトがすぐに得られ、最終的には完成品になりました。

別の話は、データベース設計です。 残念ながら、システムには、適切に構成されていないいくつかのCLRコンポーネントが含まれています。 依存関係では、コンテンツを含む単純な展開ベースは許可されません。 現時点では、これは展開前のスクリプトによって解決されています。

さらに、不均一なシステムランドスケープ（SQL Serverバージョン2008と2014は異なるポイントにインストールされていた）のため、.Netバージョン2.0および4.0のベースプロジェクトのアセンブリを整理する必要がありました。

すべてのスクリプトの準備とテストが完了した後、ビルドスクリプトVSTSで使用されました。

ビルドの直前に、すべての製品のバージョンが、ビルドスルー番号を含む共通の標準番号に更新されました。 同じ番号が展開後のスクリプトに保存されました。 したがって、すべてのコンポーネント（データベースとすべてのクライアントアプリケーション）は、一貫性があり、同じ番号が付けられています。

テストベンチへの展開

アセンブリプロセスの初期バージョンが完了した後、展開スクリプトの準備を進めました。

データベースが最も面倒だったと予想されます。

実際のベースのコピーを「上に」デプロイすると、アセンブリと実際のシステムの状態との間に多くの競合が示されました。

• GITと実際のシステムで一貫性のないバージョン
• 削除する予定のユーザーが所有するデータベーススキーマ。

開発プロセスの安定化

もちろん、これについて話すこと、さらにここで書くことは奇妙ですが、開発者にとって最も深刻な変更は、「これがgitになければ、これは存在しません」という原則の導入でした。 以前、コードは「顧客への報告用」にコミットされていました。 今-これなしでは、何も提供することは不可能です。

最も難しかったのは、データベースコードでした。 sqlpackageを使用したアセンブリおよびデプロイメントを通じて、リポジトリからデータベースをデプロイするように切り替えた後、「デルタ」アプローチは「望ましい状態」アプローチに置き換えられました。 パッケージは過去のものであり、すべてが自動的に展開されるべきでした。

しかし！ 新しい展開プロセスに完全に移行するまで、変更を配信する必要がありました。 そして、これを昔ながらの方法で行う必要がありました-「デルタ更新」。

デルタパッケージを配信する際のシステムの状態とリポジトリのコンテンツの完全かつ一定した一貫性を確保するという課題に直面しました。

これを行うために、次のプロセスを編成しました。

1. 定期的に、リポジトリからコードが収集され、空の「モデル」データベースにデプロイされました。
2. 「モデル」ベースに基づいて、特別な自動テストが準備されていました。 「モデル」データベースの各オブジェクトについて、チェックサムが計算されました。 自動テストにはこれらのチェックサムがすべて含まれており、起動時に「チェック済み」データベースの対応するオブジェクトのチェックサムが計算されます。 オブジェクトまたはそのチェックサムの構成に矛盾があると、テストが低下します。
3. 「落下」テストは、テスト環境からさらに下の場所へのパッケージの転送を自動的に禁止しました。 このような統合は、以前のトランスポートシステムで既に実装されています。

したがって、自動制御を使用して、gitの製品データベースコードを比較的迅速に最新の状態に保ち、プロジェクトチーム側の追加作業なしでそれを維持することができました。 同時に、開発者は、コードをリポジトリに正しくタイムリーにコミットする必要性に慣れ始めました。

統合テスト環境での製品展開

前のステージを完了した後、テスト環境でのアプリケーションのデプロイに直接進みました。 テストシステムへのデルタパッケージの適用を完全に停止し、VSTSを使用した自動展開に切り替えました。

その瞬間から、チーム全体が、以前に費やした努力の最初の成果を受け取り始めました。追加の努力なしで展開が行われました。 カスタムコードは自動的に収集、展開、およびテストされました。

残念ながら、後で理解したように、「リポジトリの調整」により、「開発」の安定サポートバージョンのバージョンがありましたが、「本番」バージョンはまだ利用できませんでした。 そのため、テスト環境を超えて-QASとPRDを使用することはありませんでした。

DB側のアプリケーションコードを生産的なコードと比較し、違いを理解できます。 クライアントアプリケーションと比較するものは何もありませんでした-実行可能ファイルのセットの形で最新の本稼働バージョンのみがあり、それらがコンパイルされたのは確かに言うことはできませんでした。

自動アセンブリの結果としての製品のテスト

アセンブリのアプローチを変更した後、製品は広範囲の回帰テストを受ける必要がありました。 アプリケーションが動作しており、何も失われていないことを確認する必要がありました。

テスト中に、データベースの側面にある機能を使用すると簡単になりました。 幸いなことに、重要な領域をカバーする重要な一連の自動テストを開発しました。

しかし、C＃のテストはありませんでした。したがって、すべてが手作業でチェックされました。 これはかなりの量の作業であり、検証には時間がかかりました。

飛躍-生産的なパイロット展開

テストにもかかわらず、初めて製品に展開するのは怖かったです。

幸運なことに、新しいサイトでシステムの次の展開を計画していました。 そして、この機会をパイロット展開に使用することにしました。

ユーザーは、新しいアセンブリの考えられるエラーは簡単に修正でき、実際の生産的な作業はまだ開始されていませんでした。

システムを展開し、数週間は生産前の使用モードでした（低負荷、製品でスキップできる特定の使用パターン）。 この間に、テスト中に見逃されたいくつかの欠陥が明らかになりました。 彼らは発見されたときに修正し、新しいバージョンはすぐに検証のために公開されました。

正式なローンチとローンチ後1週間のサポートの後、これが「新しい方法で」組み立てられて配信された最初のコピーであると発表しました。

このバージョンのアセンブリは、masterブランチの最初の安定バージョンになりました。休日タグ「fisrt_deployment」でハングしました（コミットのハッシュでアイコンを並べませんでした）。

生産的なランドスケープ全体に展開を拡大

ジェームズ・ボンドが言ったように：「2回目ははるかに簡単です。」 パイロット展開が成功した後、同様のタイプのシステムの残りのインスタンスをすばやく接続しました。

しかし、システムにはいくつかのタイプの使用があります-1つの機能を1つのタイプに使用でき、他の場合には使用できません。 したがって、最初のタイプの実装でテストされた機能は、他の場合の成功を必ずしも保証しませんでした。

残りのタイプの使用の機能をテストするために、開発中のアクティブなプロジェクトの使用を開始しました。 アイデアは似ており、最初の展開-自動アセンブリの使用を開始し、プロジェクト機能とともにユーザーに「スリップ」しました。 したがって、ユーザーは、製品の「設計」バージョンを使用して、同時に古い機能をチェックしました。

スケーリング自体が予期しない技術的な問題を明らかにしました：

不均一なシステムランドスケープ

アプリケーションを直接デプロイすることに加えて、最初はすべてがどこでも同じであることに注意する必要がありました-.Netバージョン、Powershell、モジュール。 それはすべてかなりの時間がかかりました。

ネットワーク接続

一部のサイトでは、ネットワーク接続により、アセンブリのすべてのコンポーネントのポンプが許可されませんでした。 転送中にタイムアウト、損傷がありました。 私たちは多くのことをチェックして試しました-あまりうまくいきませんでした。

次の解決策を検討する必要がありました。すべての結果が1つの大きなアーカイブにまとめられ、その後小さな断片（各2 mb）に分割されるように、ビルドスクリプトが完成しました。 成果物をダウンロードする際の同時実行性を排除し、2メガバイトのすべてのフラグメントを受け入れ、それらから既に拡張可能なものを復元するために、展開シナリオを完成させました。

ウイルス対策との競合

私たちが遭遇した別の奇妙な問題は、ウイルス対策ソフトウェアと展開手順の1つです。.js、.dllなど、あらゆる種類の「疑わしい」ファイルがアーティファクトアーカイブから抽出され始めると、ウイルス対策はそれらを詳しく調べ始めます。 そして、最も奇妙なことは、アンチウイルスがアンパックの終了前にファイルに急ぎ始め、アンパックプロセスが「ファイルは別のプロセスでビジーです」というメッセージとともにドロップすることです。 私たちはこれに苦労していますが、スキャンからアーティファクトのあるローカルフォルダーを除外しています-あまり良くありませんが、他には何も起こりませんでした。

プロセス改善

組み立てと展開のプロセスを安定させた後、「靴屋向けのブーツの仕立て」に進み、内部プロセスを改善しました。

• 会社のITサポートシステム（service-now.com）とVSTSの基本的な統合を構築して、ワークアイテムの形式でチケットを転送しました。 開発中のマージポリシーを修正しました-現在、接続チケットの存在が必ず必要です。
• CIをすべての機能ブランチに接続しました。 コード変更が公開されるとすぐに-バージョンは自動的に収集され、テストの準備ができます
• 契約組織の側では、テストベンチの大規模なセットを展開し、内部テスト用のアセンブリの「セルフサービス」展開を組織しました
• 顧客側では、システムの種類ごとにいくつかのテストベンチも展開しました。 部門の開発者または従業員は誰でも展開を開始できます;展開の許可は、システムのタイプと調整テストの責任者に与えられます。
• プロジェクトでの作業のためのインフラストラクチャを編成しました。プロジェクトブランチの特別な命名、開発者、アナリスト、エンドビジネスユーザーが作業するシステムの専用インスタンス用のCI / CD
• プルリクエストポリシーの形式でいくつかのチェックを修正（詳細は別の記事に記載 ）
• 自動テストのストレージを共通のリポジトリ（以前はテストは個別に保存されていました）とアセンブリおよび展開プロセスに統合しました。 現在、製品アセンブリには、開発ブランチと製品全体の両方のコードとテストが含まれています。
• 実験として、テストに関与するアナリストのローカルコンピューターにVSTSエージェントをインストールし、そこにクライアントパーツを展開して、テストのためにアセンブリを行いました。

まとめ

現在の状況

• すべてのアプリケーションコードは、クライアントが管理するMS VisualStudio Team Services（最近Azure Devopsと呼ばれる）に保存され、維持されます。 バージョン管理システム-GIT
• すべての変更は完全に透過的であり、サービスチケットに関連付けられています（インシデント/変更）
• git / GitFlowへの移行のおかげで、並列開発がずっと簡単になりました。
• 顧客担当者の参加により、コードレビュー手順が導入されました。
• アプリケーションはCIシステムによって構築されます。 メインブランチと機能ブランチの両方で完全なアセンブリが実行されるため、早期のテストを編成できます。
• すべてのターゲットノードへのアプリケーションのデプロイは、シナリオに基づいています。 次第に、基本的なコンポーネントとアプリケーションを構成する手順が、アプリケーションの展開手順に追加されます。
• 顧客のIT部門の従業員自身が、テスト環境または初期の知り合いのために、テスト環境へのアセンブリ（最終または中間）の展開を開始できます。 ビジネスユーザーもテスト環境にアクセスできます。
• 1か月のメインリリースサイクルを引き続き順守します。 先月は毎週実用的な何かを展開していますが。
• 一部のサイトへのバージョンの「実験」ロールアウトのプロセスが登場しました。

ステージごとの時間

いや	ステージの説明	期間
1	プロジェクトの最初から-コード、アセンブリ、およびテスト環境への配信プロセスの完全な制御	6ヶ月
2	最初の展開からテスト環境へ-最初のパイロットリリースから生産性へ	3ヶ月
3	パイロット展開から生産性、すべてのインスタンスの最初のリリースまで	5ヶ月

合計期間-14か月

特に最終段階での期間は、主に調整とシステムメンテナンスの合意されたカレンダーによって決定されました。

人件費

変更に関連するすべての作業の顧客および契約組織の関与する従業員の総費用は、約250人*日です。