MS Dynamics CRMに基づくシステムのチーム開発

今日は、MS Dynamics CRMプラットフォームでチーム開発をどのように構築したかについて説明します。 このプラットフォームは、ソースコードのないほとんどのプロプライエタリシステムと同様に、開発者にとって多くの制限と追加の困難を伴います。 システム構成、内部エンティティの作成、UIの作成-これらはすべてプラットフォームの内部ツールによって実装されますが、内部言語はありませんが、設定を転送する機能は文書化されていない内部形式でのアップロードに限定されます。



技術的な観点から見ると、MS Dynamics CRMは、ほとんどの場合、中小企業向けのCRMおよびフロントエンドソリューションを開発するための基盤として使用されるプラットフォームです。 MS Dynamics CRMは、そのようなシステムの典型的なブロックの実装を標準で提供し、それに基づいた開発を大幅にスピードアップします。 Webサービス、ワークフロー、独自のプラグインの作成、クライアント拡張機能、既に実装およびデバッグされたデータモデル、ロールモデル、ロギングなどのコンパートメント内のMS Dynamics CRMに基づくレポートを使用して、実装から実装までこれらのブロックを再生する時間を無駄にしない。 ビジネス機能の実装にすぐに集中できます。



ただし、これらの機能には価格があります（ライセンスのコストを除く）。 そして、この価格は、いつものように、箱入りソリューションの不透明度です。 古典的なソフトウェア開発で育った開発者は、開発対象を完全に制御できるという事実に慣れています。 つまり 製品の完全なソースコードと、クリーンな回路（システムボックスからインストール）に展開するためのインストールパッケージ（プロジェクトビルドスクリプト）に変換する機能が必要です。



10人以上の開発者から成るチームが、MS Dynamics CRMに基づいて構築されたエンタープライズ規模のシステムの機能を開発するために必要なオプションを考えてみましょう。 開発では、システムの動作を変更する機能だけでなく、このタスクは非常に明白であり、独自のMS Dynamics CRMシステムでも問題を引き起こしません。 私たちは、チーム開発、すべてのコンポーネントの観点からシステムの動作を人々の作業の速度と品質を損なうことなく同時に変更する能力、継続的インテグレーションの構築、自動アセンブリの実装、そして最終的な継続的展開の機械化に関心があります。



まず、MS Dynamics CRMの開発の概念に含まれるものの検討から始めましょう。

開発者の観点から見たMS Dynamics CRMに基づくシステムの主要部分：



1）設定（以下、カスタマイズと呼びます）

a。 プラグイン

b。 ディレクトリ

c。 Webリソース

d。 報告書

2）補助データベースオブジェクト



私たちが個別に検討するプラグイン、ディレクトリ、Webリソース、およびレポートは、基本的にカスタマイズの一部であり、物理的に含まれていることをすぐに予約します。 しかし、開発の観点から、それらを個別に検討します。 開発プロセスのライフサイクルは大きく異なります。



プラグイン-任意のイベントによってトリガーされるC＃ロジックで実装されます。 開発の観点から見ると、これはIPluginを実装し、DLLにコンパイルされたネイティブクラスです。



システムでのトリガーの登録と調整は、MS Dynamics CRMによって実行され、カスタマイズの一部です。







参考書。 MS Dynamics CRMでは、多くの参照データがよく使用されます。多くの場合、システムのビジネスロジックはそれに関連付けられています。 ディレクトリは、参照データのセットを持つ不変のエンティティと呼ばれます。 これらは通常のシステムエンティティであり、作業プロセス中に変化するのではなく、開発プロセス中に変化します。 ディレクトリ内のデータが間違っていると、予期しない結果が生じます。 コンテンツの一貫性を制御できることが重要です。 ここでの主なツールは、コンテンツのバージョン管理の変更かもしれません。



Webリソースは、MS Dynamics CRMフォームを展開するために使用できる仮想ファイル（JScript、CSS、XML、XSL、HTML、JPGなど）です。 これらはWebサーバーディレクトリに保存されるのではなく、MS Dynamics CRMデータベースに仮想ファイルとして保存されます。 各Webリソースには、対応するファイルを取得するためにURLで使用できる一意の名前があります。 それらの使用はブラウザへの戻りに限定され、サーバー処理は提供されません。 開発中に、MS Dynamics CRMツールを使用して読み込まれ、カスタマイズの一部になります。



カスタマイズ-1つのコンテナーに統合されたMS Dynamics CRMシステムのさまざまなコンポーネントの設定。 システムの機能の開発と調整は、システムの内部エディターで「マウスを使用したプログラミング」によって実行されます。 エンティティとそのフィールドを作成し、ワークフロー（オンデマンドまたは自動で起動される一連のルール）を構成し、ユーザーがシステムエンティティとビュー（ビュー）を操作するためのフォーム（フォーム）を作成できます。 これらをまとめてカスタマイズと呼びます。 カスタマイズは、編集された組織からエクスポートして、1つのシステムインスタンスまたは別のサーバー内の別の組織にインポートできます。



（MS Dynamics CRMの組織は、システム内の一種の「サンドボックス」です。複数の組織が1つのサーバーで同時に作業でき、互いに独立していますが、それぞれに独自のベースがあります）。



補助データベースオブジェクト。 システムを設計するとき、多くの場合、MS Dynamics CRMデータベースまたは別のデータベースの隣に独自のオブジェクト（テーブル、ビュー、ストアドプロシージャなど）が必要です。 これは、未知のMS Dynamics CRMデータを保存および処理し、APIを使用してMS Dynamics CRMデータベースにインポートするか、データベースに直接インポートするためによく行われます（これは歓迎されません）。



レポート。 MS Dynamics CRMは、MS SQLおよびReporting Servicesと統合されています。 開発の観点からのMS Dynamics CRMレポートは、デザインテンプレートとレポートテンプレートファイルにパックされたデータソースに関する情報です。



上記で強調表示されたコンポーネントは、開発者の観点からの主要なコンポーネントです。MSDynamics CRMプラットフォームで新しいシステムを作成することで、彼が修正するのはコンポーネントです。

明らかに、上記のコンポーネントから、「問題」はカスタマイズです。 これは、明示的に「ソースコード」を持たないシステムのコンポーネントです。



MS Dynamics CRMの開発プロセスを整理するためのマイクロソフトの推奨事項を見てみましょう。 Microsoft は 3つのオプションを提供しています。



•1つの組織：1つのマスターソリューション

•1つの組織：マスターソリューション+複数の変更ソリューション

•開発者ごとに個別の組織



最初の2つのアプローチの本質は、共通の組織での開発に帰着します（MS Dynamics CRMの単一インスタンス内にいくつかの独立した組織を展開できます）。 組織はすべてのカスタムコンポーネントを含む単一のCRMソリューション（マスターソリューション）を作成し、開発者はこのソリューションの一部としてカスタマイズを行います（2番目のバージョンでは、開発者は割り当てられたコンポーネントを編集するための個別のソリューションを作成できます）。 最終的に、最終的なソリューションに対するすべての変更は、すべての開発者がタスクの作業を完了した後に責任者によってエクスポートされます。 この非常に簡単でシンプルなアプローチには、多くの問題が伴います。



-開発者は互いの編集を上書きできます（たとえば、開発者は同じフォームを開いて変更し、最後のフォームは最初のフォームの変更オーバーライドを公開しました）。

-何らかのカスタマイズにエラーが含まれている場合、パッケージの準備時に、これらの変更をインストールパッケージに反映しないように、これらの変更をロールバック（またはスタブを作成）する必要があります。

-テストでは、アセンブリ/エクスポートの責任者が解決したタスクのパッケージのみを転送できます。 つまり タスクのコード変更は仮想コンテナにまとめられ、互いに分離不可能になります。これにより、テスト時間が長くなり、パッケージからタスクが除外されます。 さらに、開発者間でソリューションコンポーネントを分離する際に困難が発生します。多くの場合、異なるタスク内で同じコンポーネントを編集する必要があります。



3番目のアプローチである「開発者ごとに独立した組織」は、チーム開発の従来の要件に最も近いものです。



各開発者は、それぞれ独自の組織に「住んでいる」と想定されています。 タスクを完了するために、開発者は最新バージョンのカスタマイズ（マスター組織から事前エクスポート）を組織にインポートします。 次に、彼は組織内のタスクに必要な変更を加えます。 次に、変更されたソリューションを組織からアンロードし、最終スプリント/リリースパッケージが既に形成されているマスター組織にインポートします。

しかし、このアプローチでもすべての問題を解決できるわけではありません。 同時に、開発者は同じサーバー上で「生きている」ため、変更を完全にデバッグする能力に悪影響を及ぼし、競合を解決する方法は明確ではありません。



私たちは何をしましたか



開発者が最初に必要とするのは、ローカルで完全にデバッグできることです。 つまり 言い換えれば、開発者は生産性が低く、インフラストラクチャと環境との統合の点で簡素化されていますが、生産的なサーバーのコピーにアクセスできる必要がありますが、論理的にはシステムのすべてのコンポーネントが存在し、ローカル回線は同僚の仕事から可能な限り独立している必要があります。 これがなければ、生産的な仕事はあり得ません。 残念ながら、MSの勧告でさえ、そのような自由を完全には与えていません。



各開発者に、サーバーOS（はい、MS Dynamics CRM、サーバーOSのみにインストール）、MS Dynamics CRM、MS SQL、Reporting Services、および開発に必要な製品（MS VS、MS Dynamics CRM SDK、Gitクライアント、MS SQL Management Studioなど）） 各開発者に個別の組織を割り当てるために提案されたMSオプションよりも少し進んで、各開発者にMS Dynamics CRMの個別のインスタンスを割り当てました。 そしてこれは理解できる、なぜなら カスタマイズに加えて、他のコンポーネントはMS Dynamics CRMの隣で機能します。MSDynamics CRMは開発者が変更することもできます。 最終的には遅かれ早かれ、同じMS Dynamics CRMサーバーで「エルボープッシュ」が行われます。 ボーナスとして、仮想マスターマシンを複製することにより、1時間以内に新しい開発者に開発のための準備済みの事前構成済みの概要を提供する機会が与えられます。



今では誰もがローカル開発のためのすべてを持っています。 プラグインコードの編集、カスタマイズ、データベース内のオブジェクトの作成と削除、ローカルでのコンポーネントの収集とインストール、および排他的なデバッグが可能です。 最後に、変更をGITブランチに送信します（このバージョン管理システムを使用しているため、以降GITと呼びますが、他のSCMシステムについてはすべて書かれています）。 変更をどのようにバージョン管理しますか？ 自動ビルドソリューションをビルドするには何が必要ですか？ 開発プロセス中に変更されるシステムの主要部分のリストに戻ります。



プラグイン-それらに問題はありません。 C＃にはコードがあります。 GITにコミットし、競合を解析する可能性があります。 DLLでのプロジェクトのビルドは、C＃コードのビルドです。 組み立てられたプラグインのインストールの自動化-また、解決可能なタスク-は、MS Dynamics CRM APIを通じて実装されます。



ディレクトリは、コンマ区切りファイルの形式でGITのコードと同様に格納することを決定しました。 問題を分析するには、Excelを使用して編集すると便利です。 実際、フォーマットはテキストのままでした。 ディレクトリの内容の自動インポートおよびエクスポートのメカニズムを作成しました。 システムAPIは柔軟性があり、エンティティを使用した操作を自動化できます。 特に複雑なのは、関連ディレクトリ、マルチレベルディレクトリです。 個別の同期とリンクのために、各ディレクトリにサロゲートキーを入力する必要がありました。



Webリソースは、カスタマイズの一部であるため、一方でカスタマイズ内に存在する必要があり、他方では、デバッグおよびバージョン管理の目的でGITに明示的に存在する必要があります。 WebリソースはGITの別のディレクトリでバージョン管理され、これらの同じファイルは、パッケージをコミットまたは準備する前にカスタマイズにインポートする必要があります。 現在の段階では、これは定期的に驚きをもたらす管理上の決定です-開発者はGITに変更を加えましたが、変更されたファイルをカスタマイズにインポートするのを忘れました。 変更の履歴は失われます。



これはこのように機能しますが、これらのファイルをVisual Studio csprojのリンクとして追加できるという前提があります。 物理的には、アンパックされたカスタマイズになります。 これにより、重複とそれに伴う問題を回避できます。



カスタマイズは、開発者にとって頭痛の種の主な原因です。 MS Dynamics CRM SDKで使用するために、SolutionPackagerという有用なユーティリティが発見されました。 基本的に、MS Dynamics CRMからソリューションをエクスポートするときに取得するソリューションファイルの解凍（カスタマイズ）を実行します。 ソリューションファイルを見ると、これは文書化されていない形式の巨大なxmlファイルです。 出力では、SolutionPackagerを処理した後、ファイル構造によって分解されたxmlファイルを取得します。これらは、エンティティタイプごとに論理的に分割されます。 同じツールで逆変換を実行できます。 解凍したソリューションを単一のファイルにパックします。 ロジックに従って破損した小さなxmlファイルを使用することは既に可能です（文書化されていませんが）。



ソリューションの開梱も解決するタスクになります。 さらに、カスタマイズの各要素に誰が、何を、いつ、どのタスクを適用したか、それが行われたタスクのフレームワーク内で、履歴を確認する機会があります。



チーム開発中にカスタマイズを変更するプロセスは次のとおりです。



1）GITから新しい「アンパック」カスタマイズを取得する

2）受け取ったカスタマイズをローカルにパックします

3）ローカルMS Dynamics CRMにインポートする

4）開発者のローカル回路でカスタマイズを修正します

5）他のコンポーネントに変更を加え（必要な場合）、それらを収集し、ローカルにインストールします

6）デバッグの変更。 必要に応じてセクション4と5に繰り返し進みます。

7）ローカルサーバーからカスタマイズをエクスポートします。

8）エクスポートしたカスタマイズを別のディレクトリに解凍します

9）GITから新しい「アンパック」カスタマイズを引き出します

10）第8項で取得した変更と新しいカスタマイズのマージを実行します。 これは非常に重要なステップです。なぜなら、 変更を行っている間、誰かが変更されたカスタマイズファイルを既にコミットしている可能性があります。 これらの変更を粉砕するべきではありません。

11）変更をコミットします。

プロセスのオーバーヘッドは大きいです。 人間の介入を必要としない手順を自動化しようとしました。 これは条項2-3、条項7-9です。



カスタマイズで一緒に作業する場合、次のシナリオが考えられます。



1.開発者はさまざまなエンティティに変更を加えます。 タスクを完了すると、全員がソリューションをアンロードし、変更をGITにコミットします。 この場合、競合は発生しないはずです。 ソリューションを解凍すると、変更は異なるxmlファイルに表示されます。

2.開発者は、1つの形式のエンティティに変更を加えます。 タスクを完了すると、全員がソリューションを組織からアンロードし、GITからソリューションの最新バージョンを取得して、GITに変更をコミットします。

a。 開発者Aは最初にタスクを完了し、GITからソリューションの最新バージョン（タスクの実行中に変更がなかった）を取得し、ソリューションをアップロードして変更をコミットします。

b。 開発者Bはタスクを2番目に完了し、GIT（この間に開発者Aの変更が表示された）からソリューションの最新バージョンを取得し、ソリューションをアンロードします。変更をコミットすると、フォームのxmlファイルで競合が発生します。



競合を解決する可能な方法：



i。 開発者Bは、開発者Aによってカスタマイズが行われたフォーム変更の履歴を調べます。変更が単純な場合（たとえば、フィールドがフォームに追加される場合）、開発者Bは組織でこれらの変更を繰り返し、組織からソリューションをリロードして、フォームに変更をコミットします上書きモード。



ii。 開発者Bは、開発者Aによってカスタマイズが行われたフォーム変更の履歴を調べます。開発者Aの変更が複数で繰り返しが困難な場合、開発者Bはソリューションの最新バージョンをGITから組織に再インポートし、再度実行に必要なカスタマイズを行いますその後、彼の組織からソリューションを再アップロードし、フォームの変更をコミットします。



iii。 開発者Bは、開発者Aによってカスタマイズが行われたフォーム変更の履歴を調べ、それらが重要/オプションであると見なします（たとえば、開発者Aは1つのセクション内のフォームのフィールドを移動し、開発者Bはタスクの一部としてこのフィールドを別のタブに移動しました、または別のシステム名でフィールドを再作成し、古いシステムをフォームから削除しました）。 この場合、開発者Bはその変更を上書きモードでフォームにコミットします。



iv。 フォームのxmlコードで直接変更をマージ/マージすることができます（たとえば、開発者Aがフォームに独自のセクションを追加し、開発者Bが独自のセクションを追加した場合）。 また、この場合、開発者Bはxmlコードをマージした後、組織内のソリューション全体のインポート可能性を確認する必要があります。 その場合にのみ、彼は組織からソリューションを再アップロードし、変更をGITにコミットできます。



たとえば、最も不快なケースは、同じフォームの異なる開発者による同じタイプのコントロールの並行追加です。 開発者Aは、「変更」フィールドを「会議」フォームに追加します（図を参照）







開発者Bは、「作成日」フィールドもそこに追加します（図を参照）。







開発者Aは最初に変更をコミットします。開発者Bは、変更をコミットする前にGITからファイルの最新バージョンをプルすることを忘れずに、フォームに変更があったことを確認します。これらの変更は手動で制御する必要があります（図を参照）。







補助データベースオブジェクト-データベース構造のバージョン管理の変更-これは、別の大きな記事のトピックです。この問題を解決する方法は、入力条件に依存します。さまざまなシステム、チーム、さまざまなDBMSの1つの組織のフレームワーク内で、この問題はさまざまな方法で解決されます。MS Dynamics CRMデータベースと補助データベースのバージョン変更の場合、MSVSで別のデータベースプロジェクトを使用し、その後の.dacpacファイルの生成でパスを作成しました。データ層アプリケーションフレームワークは、ターゲットデータベース構造の説明を含む.dacpacファイルを受信すると、以前のバージョンのデータベースをターゲット構造に取り込むことができます。







主なことは、DDL、アセンブリclrコード、データベースプロパティ、PreDeploymentおよびPostDeploymentスクリプトの変更に必要な状態にデータベース構造を自動的に縮小するバージョン管理オプションが見つかったことです。



さらに、データベースプロジェクトでは、2つのモードで作業データベースと同期できます



。データベースと同期：データベースのすべてのオブジェクトがプロジェクトに転送されます。アップグレードプロセスは完全な同期であり、プロジェクトが主要です。

増分。データベースを更新するプロセスでは、プロジェクトに存在するオブジェクトのみが更新/変更され、残りには影響しません。インクリメンタルアプローチでは、データベースがプライマリです。この場合、データベースからのプロジェクトの更新はありません。



増分同期を選択した後、システムの背後にあるMS Dynamics CRMオブジェクトの制御を残しました。データベースプロジェクトで明示的に変更されたオブジェクトのみが追加および変更されます（すべてのMS Dynamics CRM開発者は、MS Dynamics CRMデータベースの構造を変更しないことを知っています）。



レポートとディレクトリは、GITでバージョン管理されます。 MSRSでのインストールの自動化は、レポートサーバーWebサービスエンドポイントによって非常に簡単です。レポートテンプレートを読み込むためのサンプルコードを以下に示します。







これらのアプローチと自動化メカニズムの複雑さにより、最終的にこれを目的としないシステムの開発に継続的統合を実装することができました。これにより、C＃コードだけでなく、カスタマイズやMS Dynamics CRMのその他すべてのコンポーネントでも、プロジェクトのアセンブリおよび毎日の展開段階で開発エラーをキャッチできました。



開発プロセスを自動化する最後のステップは、システムのすべてのコンポーネントをインストールするインストーラーの誕生でした（そして、MS Dynamics CRMのコンポーネントに加えて、拡張サイトに補助サイト、サービス、サービスもあるため、上記よりもかなり多くのコンポーネントがあります）。カスタマイズ、データベースの変更、レポート、4つのサイト、2つのサービスを含む完全インストールには、平均1時間かかります（テスト回線）。同時に、MS Dynamics CRMへのカスタマイズのインポートに時間の大部分が費やされます。



明らかに、完全なインストールが常に必要なわけではないため、コンポーネントの選択的なインストールの可能性が最初に設定されました。これにより、ローリングアップデートの時間を節約できます。



さらに、インストーラーは、インストールに必要なすべてのパラメーターとコンポーネントをダイアログ入力するウィザードを備えた2つのモードで動作します。このモードは、サポートスタッフがProdアカウントからパスワードを手動で入力する必要がある場合に、手動で展開、本番環境にインストールするためのものです。











構成ファイルからインストールに必要なすべての情報を受信して​​サイレント。このモードは、回線の更新のロールアップを自動化するのに便利です。







各回路のパラメーターのセットを含む構成ファイルがあると、ボタンをクリックするか、スケジュールに従って回路を更新できます。たとえば、テスト回路への更新パッケージのロールアップの実装は、TeamCityの個別のプロジェクトとして作成されます。使い慣れたTeamCity UIとログとロールバック履歴を保存する機能により、TeamCityをアセンブリだけでなく、回路への展開パッケージにも便利に使用できます。



MS Dynamics CRMのチームワークを編成する方法の概要を以下に示します。もちろん、何かが異なって行われた可能性があります。いくつかのタスクはより効果的に解決でき、他のどこかではまったく異なる方法になりました。 Webリソースの編集、xmlカスタマイズソースのマージの難しさ、MS Dynamics CRMの腸内のxmlファイルの予期しない変更など、今も未解決の問題があります。それにもかかわらず、現在のアプローチは機能し、大規模な分散開発チームを効果的に開発することができます。また、組織の難しさや「開発に近い」問題を解決することにより、システムは日々ますます散漫になります。 2年前のMS Dynamics CRMの開発プロセスを整理するための推奨事項と既製のテスト済みアプローチの検索では、顕著な結果は得られませんでした。



おそらく、誰かがカスタムシステムを使用して開発を構築しようとしているのと同じような状況にあるとしたら、私たちの経験が何かに役立つことを願っています。



アレクサンダーゴロディロフ、フロントオフィスシステム開発部長