継続的インテグレーションと継続的デリバリは、事実上、現代のプロジェクト開発の不可欠な部分です。 CIの自動化には、さまざまなベンダーの多くのプログラムがありますが、アプリケーション展開の自動化の方が控えめです。 1つの展開アシスタントはOctopus展開です。
はじめに
開発プロセス中の一般的なアプローチを見てみましょう。 開発者はコードを記述し、影響を受けるコードで単体テストを実行し、コミットします。
CIのイデオロギーによると、彼らはできるだけ頻繁にそれを行います。 次に、CIアプリケーション（TeamCity、TFS、Jenkins、Bamboo、またはチーム内の別のお気に入り）がアプリケーションを収集し、自動テストを実行します。
手動テストのためにアプリケーションを引き渡す時が来て、チームのメンバー（
DevOps ）がアプリケーションをテスターにデプロイします。
次に、次のポイントを示します。テスト（ユーザー受け入れテストまたはステージング）のために顧客に提供します。
さて、顧客からの緑色の信号の後に、最も重要な瞬間が来ます。それは、実稼働中のアプリケーションの公開です。 また、顧客は、実稼働環境で何か問題が発生した場合、チームが指のクリックですべての変更を最大30分間ロールバックできることを期待しています。
Octopus Deployは、.NETアプリケーションの展開に役立ちます。 Octopusはアプリケーションパッケージを取得し、サーバーに展開します。 通常、最初はDev Environmentサーバーです。 その後、アプリケーションをテスト、UAT /ステージング、そしてサーバーの本番環境に簡単に昇格させることができます。 しかし、まず最初に。
タコデバイス
OctopusはOctopus Serverを使用し、NuGetアプリケーションパッケージを取得します。 これらは、http / https経由でNuGetフィードCIサーバーにサブスクライブするか、サーバー上の通常のフォルダーから
NuGetリポジトリから自動的に取得できます。 原則として、NuGetパッケージには完全なアプリケーション、たとえば完全なASP.NET Webサイト、またはWindowsサービスのインストールに必要なすべてのファイルが含まれている必要があります。
Octopusに触手のある公開サーバーに到達します。
Tentacle Agentは、Windowsサービスとして実行される軽量プログラムで、Octopus ServerからNugetパッケージを取得し、アプリケーションを展開します。 通信のプルとプッシュのモードがあります。 Tentacleは定期的にサーバーに新しいパッケージがないかポーリングします。または、Tentacleはサーバーからの信号を待ってサーバーがプッシュします。 Octopus ServerはWindowsサービスとしても起動し、セキュアHTTPS（TLSおよびX.509証明書）を介して触手と通信します。 セキュリティを強化するには、Octopusをインストールするときに、サーバーが信頼するTentacleエージェントを構成する必要があります。
現在のバージョン2.0では、組み込みのRavenDBデータベースを使用してすべてのデータが格納されますが、
いくつかの理由により 、新しいバージョン3.0はMS SQL Serverに切り替わります。 ちなみに、新しいバージョンは今後数か月でリリースされますが、会社のポリシーによると、購入後の翌年に新しいバージョンにアップグレードする機会があります。
環境、役割、およびアプリケーション
うまくいく構造について詳しく見ていきましょう。
3つの環境があります（テスト、ステージング、および本番）。 Tentaclesがインストールされ、アプリケーションがインストールされる6つのサーバー。 そして、2つの役割：octo-webとocto-app。 ロールの作成は非常に便利です。たとえば、次を指定できます。octo-webロールを持つマシンにのみサイトをインストールし、octo-appロールを持つマシンにのみアプリケーションをインストールします。 テスト用に1つのサーバーが割り当てられ、その上にサイトとアプリケーションの両方が配置されることに注意してください。 実稼働環境では、3つのサーバーがあり、1つはアプリケーション用で、2つはサイト用です。 これは、サイトの2つのコピー（データベースなし）を展開し、その後にバランサーを起動する非常に現実的なシナリオです。
octo-appロールを持つOctoFXアプリケーションは次のようになります。
アプリケーションのライフサイクルは、テスト環境を通過してからステージングを行い、それを本番環境で起動することで構成されます。
設定は非常に広く、さまざまなアプリケーションに使用可能な環境を選択できます。
ステップと変数
手順
各展開は段階的に行われます。 そして、すべてのステップで機会があります：
- NuGetパッケージのコンテンツをダウンロードして、フォルダー、FTPまたはMS Azureサーバーに配置します
- Power Shellスクリプトを実行し、スクリプトに変数を渡します
- 特別な変数を使用して構成ファイルを更新する
- 構成ファイルを変換します。 原則として、アセンブリ中にconfig.Releaseが開始されますが、config.Stagingなどの別のXML変換を上に追加できます。
- メールを送る
- 展開プロセスを停止し、ユーザーアクションを要求します。
- Windowsサービスの便利な展開のための特別なステップを実行する
- バインドとポートの更新を含む、特別なステップを実行してサイトをデプロイします
変数
変数は別のブロックに配置され、環境、役割、またはサーバー名に応じて値を変更できます。
サイトのアドレスに異なる値が必要で、web config'eの変数を変更する場合は、ブロックに追加するだけで、Habrの例を考えてみましょう。
次に、構成ファイル
<appSettings> <add key="HabrahabrSiteRoot" value="testkey"/> </appSettings> <deepConfigSection> <anotherTagExample someAttribute ="Site #{HabrahabrSiteRoot}" /> <deepConfigSection>
で自動的に開発環境に変換できます
<appSettings> <add key="HabrahabrSiteRoot" value="http://dev-habrahabr.local"/> </appSettings> <deepConfigSection> <anotherTagExample someAttribute ="Site http://dev-habrahabr.local" /> <deepConfigSection>
Octopusはパスワードを暗号化し、後で変数パネルでコピーしたり表示したりできないため、変数にパスワードを保存するのが最も便利です。 ユーザーを作成し、環境へのアクセスを制限することができます。 したがって、ユーザーは可変ブロックとアクセス制限の助けを借りて、管理者またはリリースマネージャーのみが実稼働環境でアプリケーションを展開し、それに応じて構成ファイルの最終バージョンのパスワードを表示できるようにできます。
特別な
システム変数もあり
ます 。 これらは、ユーザー変数と同じ方法で使用できます。 PowerShellスクリプトまたは構成ファイル。 たとえば、顧客の1人がUmbraco Webサイトを使用しています。 もちろん、NuGetパッケージでは、ギガバイトのメディアコンテンツではなく、サイトの実行可能な部分のみを追加するのが理にかなっています。 サイトを更新すると、Octopusは新しいフォルダーを作成します。 実際、たとえば、新しいサイトは、\ Octopus \ Applications \ UmracoSite \ 1.20.0 \フォルダに置きます。 PowerShellスクリプトとOctopus.Deployment.PreviousSuccessful.Id変数を使用して、すべてのメディアコンテンツをサイトの古いバージョンから新しいバージョンにコピーします。
おわりに
これまで、アプリケーションを展開する前にデータベースの手動バックアップに遭遇し、構成ファイルを手動で変更し、ローカルに保存され、プログラマーとシステム管理者によって異なる自己記述スクリプトの多くのバリアントを使用し、さらにアプリケーションフォルダーを運用環境とテスト環境に手動でコピーしました。
このプロセスで人的要因とルーチンを最小限に抑えるようにしてください。 そして成功した配備！
便利なリンク：
プロジェクトビデオチュートリアルドキュメント