継続的デリバリーとSitecore：実装

私たちの会社が開発しているメインのCMSであるSitecoreに適用されるContinuous Delivery（以下CD）のコンセプトを紹介したいと思います。 CDのコンセプトは、3つの柱に基づいています。

• バージョン管理システムはGitです（原則として、他のシステムにも適用できますが、Gitのブランチは非常にシンプルで高速で安価であるため、Gitが最も便利です）
• CIサーバー-TeamCity
• 実際にすべての配信、インストール、および処理を実行するコード（スクリプトおよび追加の実行可能ファイル）

この記事では、関連するすべての側面を説明しようとします。

Git

このバージョン管理システムの選択は、CDの概念によるもので、各リポジトリにはdev、acceptance、masterの3つの主要なブランチがあります。 名前に従って、各ブランチは3つのサーバーのいずれかのコードの状態を反映します。

• Dev = QA、ネットワークでのみ利用可能な内部サーバー。 基本的なテストが行​​われます。
• 受け入れ=受け入れサーバー。ネットワークと顧客の両方からアクセスできますが、他のインターネットユーザーは利用できません。
• マスター=本番サーバー、誰でもアクセス可能。

すべての開発は開始され、ルートがマスターである別のブランチで行われます。 開発が完了すると、devでマージが行われ、テスト用のタスクが提供されます。

バグが見つかった場合-ブランチで修正し、マージして再テストします。

テスターがタスクを完了したと見なした後、承認、配信、および検証のためにタスクがテスターと顧客に渡されます。 問題が見つかった場合、上記のプロセスが再度繰り返されます。

顧客に従ってタスクが完了すると、ブランチのマージが行われ、そこでは開発がマスターで行われ、本番環境に配信されます。

したがって、Gitは、そのシンプルで高速なブランチと管理の容易さにより、開発および配信プロセスの非常に重要な部分です。

TeamCityおよび関連するスクリプト/アプリケーションを使用した配信プロセス

セットアップが簡単で、小規模プロジェクト（20ビルド構成以下）で無料、ほとんどの一般的なバージョン管理システム（選択したGitを含む）を理解し、MSBuild、nANT、Visual Studioの組み込みランナーがあり、そのアクセスも提供しますデータを受信し、構成を管理するためのrestAPI。 私の意見では、このクラスで最も便利なビルドサーバーの1つ（および他のJetBrains製品）。 また、TeamCityの非常に便利な機能の1つは、プロジェクトレベルで、またはWebインターフェイスを介してビルドレベルでパラメーターを直接構成できることです。 サーバーレベルでパラメーターを構成したり、ホストシステムパラメーター（PATHなど）にアクセスしたりすることができます。

プロジェクトの典型的なビルドは、自動配信を提供し、配信後のWebアプリケーションが稼働していることを検証します（サイトページはコード200を返します）。次の構成要素が含まれます。

一般設定 ：各ビルドの結果に基づいて、アーティファクトを収集します-Webアプリケーションを含むアーカイブ、パッケージを含むアーカイブ（Sitecoreは、パッケージと呼ばれる環境間の配信に特別に作成およびアーカイブされたxmlファイルを使用します）およびSQLスクリプトを含むアーカイブソリューションは追加のデータベースを使用します。 TeamCity AssemblyInfoに組み込まれたパッチャーで使用される自動インクリメントビルドカウンターと同様に、ビルドバージョンをインクリメントします。

バージョン管理システムの設定 ：TeamCityは、不名誉で構成が簡単です。 ここで唯一興味深い点は、ビルドの結果に基づいてタグを配置できることです。これにより、理論的には、問題が発生した/発生したコードに正確に戻ることができます。 ビルドを高速化し、トラフィックを削減するために、可能な限りここでインクリメンタルチェックアウトが使用されます。

実際には、ビルド自体 ：

1. Visual Studioによるビルドおよびパブリッシャーソリューション（VS目的のバージョンをサーバーにインストールする必要があります）。 slnファイルへのパスを示し、変数はこのslnファイルのどのビルド構成を呼び出すかを示します（各プロジェクトには、関連する環境ごとに複数のビルド構成があります）。 公開は、MSパブリッシュツールを使用して目的のサーバーへの配信を直接整理することができなかったため、サーバー上のローカルフォルダーで実行されます。 私がつまずいた最初と最後の問題は、私たちが異なる領域にいるということでした。 MSBuildエラーが発生すると、ビルドが停止し、次の人々に情報メッセージが送信されます。コミットに参加した人々、ビルドエンジニア、テスター。
2. パッケージ（スクリプト）をインストールするための保存ファイルとターゲットアプリケーションの準備。 Sitecoreは、特別な言語の文字と予約文字を含むノードをデータベースにデフォルトで作成することを禁止されているため、開発中にそれらなしでは実行できない場合があります。このステップでは、これらの文字の使用を許可する特別なパッチがターゲットアプリケーションに配信されます。 同じ手順で、アプリケーションを再起動する構成パッチを配信した後、wgetを使用してサイトのメインページを取得します。 これにより、アプリケーションが起動し、次のステップの準備が整います。
3. Sitecoreデータベースへのノードの配信。 WCFサービスがWebアプリケーションにデプロイされ、パッケージを受け入れてインストールします（サイト特派員は、特別に作成およびアーカイブされたxmlファイルを使用して、パッケージと呼ばれる特別な方法で環境間を配信します）。これにより、この手順を次のように自動化できます。コースコントロールにも保存されている特別に指定されたフォルダーにあるターゲットアプリケーションへの配信に必要なパッケージ。 TeamCityは、このビルドに関連する変更に関するデータを独自に収集し、restAPIを介してそれらへのアクセスを提供します。 配信を担当するアプリケーションは、restAPIからxmlを読み取り、ビルドに含まれるパッケージを選択してWCFサービスに渡します。その後、WCFサービスはそれらをインストールします。 コレクターアプリケーションに必要なすべてのデータは、リポジトリ全体で同じであるため、プロジェクトレベルで設定されたパラメーターを介して送信されます。 残念ながら、WCFサービスとターゲットアプリケーションの設定に関連する問題が1つあります。パケットのサイズが大きすぎる場合、またはインストールに20分以上かかる場合、サービスは切断されます。 エラーが発生した場合-サービスはエラーを返し、ビルドは停止し、通知は最初のステップと同じ人に送信されます。 WCFサービスは、Sitecoreに配信するものがある場合にのみ呼び出されます。これは、ビルドの高速化にも役立ちます。
4. ノードをコンテンツデータベースに公開します。 Sitecoreは2つのデータベース（コンテンツを作成するマスターとコンテンツをエンドユーザーに配信するWeb）で動作するため、マスターからSitecoreに組み込まれたWebベースにデータを転送するプロセスを実装する別のアプリケーションが作成されました。これは発行と呼ばれます。 このアプリケーションは、手順3のアプリケーションと同じ原理で動作します。開発者は、格納するノードが行単位であるファイルをコミットし、アプリケーションはrestAPIを介してこれらのファイルを取得します（ファイルはリポジトリ内の特定のフォルダーからのコミットから選択され、制限はファイルには特定の拡張子が必要です）、ファイルの内容を読み取り、WCFサービスに渡します。WCFサービスは、子を持つノードを発行します。 前のステップとは異なり、このステップでエラーが発生しても、ビルドは停止しません。 WCFサービスは、Sitecoreで公開するものがある場合にのみ呼び出されます。これはスピードアップにも役立ちます。
5. コードの準備とターゲットサーバーへの配信。 この手順では、通常のcmdスクリプトが保存されたソリューションをパックし、SSHトンネルを介して結果のアーカイブを一時ディレクトリのターゲットサーバーに配信し、そこでアーカイブを解凍します。 その後、App_Offline.htmがWebアプリケーションフォルダーに配置され、Webアプリケーションが停止され、ユーザーがアプリケーションが現在更新されているというメッセージを表示できるようになります。
6. サードパーティデータベースの更新（オプションの手順）。 アプリケーションが標準のSitecoreデータベースだけでなく追加のデータベースも使用する場合-このステップでは、これらのデータベースは、ステップ3および4のファイルと同様に、特別なフォルダーのコントロールに保存されたスクリプトを使用して更新されますその適用は、特別なファイル名形式（バージョン名）を使用して実行されます。 ファイルのバージョンがデータベースのバージョン（[拡張プロパティ]フィールドに格納されている）よりも高い場合、データベースはファイルのスクリプトによって更新されます。 すぐに、データベースを更新するためのファイルは、ステップ3および4と同様に、コレクタアプリケーションによって配信されます。また、近い将来、このステップをホストサーバービルドでの実行からWCFサービスでの実行に切り替える予定です（ただし、この場合は拒否する必要があります） App_Oflline.htmから）、セキュリティを強化する必要があります。
7. アプリケーションへのコード配信。 スクリプトは、アプリケーション内の構成とバイナリを含むフォルダーをクリアし、ステップ5で解凍したフォルダーからコードと関連ファイルをWebアプリケーションのフォルダーに配信します。 スクリプトの最後のステップで、App_offline.htmが削除されます。
8. wgetを使用して、サイトのページ（通常はメインページ）を取得し、アプリケーションが動作していることを確認します（コード200）。 コードが200と異なる場合、ビルドは失敗したと見なされます。

これが、Sitecore CMSに基づくWebアプリケーションの自動配信が我が国で機能する方法です。

このアプローチの長所/短所/未実現のパン

実際のところ、多くの利点がありますが、強調したい主なことは、通常の物忘れと怠で、配達プロセスから人を削除したことです。 また、自動化により、配信が大幅に加速しました。 もちろん、人（開発者）はまだソースにいます。 彼が何かをコミットしないと-配信されず、正しくコミットされません-正しく配信されません。 しかし、そのような純粋に人為的なエラーは、原則として、内部テストでも捕捉されます。

ただし、未実現のパンと同様に短所でも十分です。 私はいくつかを強調したいと思います：

1. ビルド全体を通して、インターネットが接続されている必要があります。 インターネット接続に問題がある場合、ビルドは失敗します。 これは、5番目までの手順では問題になりません。 ただし、5番目のステップでインターネットが落ちた場合、アプリケーションはリリースされないままになり、手動でのみ修正できます。
2. 2番目以降の手順でビルドが失敗した場合、以前のバージョンに自動的にロールバックする可能性はありません：データベースのバックアップは自動的に行われますが、復元はかなり長いプロセスであり、サードパーティ（およびかなり高価なアプリケーション）なしですべてのWebサイトデータベースをバージョン管理することは不可能です データベースだけでなく、自動コードロールバックの可能性も想像できません。
3. 配信が成功したという100％の基準はありません。テストページがコード200を返す場合と、エラーで失敗する場合があります。
4. SSHによる配信は安定性と速度の点では非常に優れていますが、MS Publish Toolとは異なり、ソリューションから除外されたファイルをターゲットWebアプリケーションに残します。 それは大きな問題ではなかったが、ただ見苦しいだけではない。