私は両方を調べました。複数のサーバーでの自動Web展開にどちらが適しているかについての提案をお願いします。
3 に答える
TeamCityとOctopusをぜひお試しください。TeamCityを使用してOctopus(NuGet)パッケージを作成し、Octoツールを使用して、ビルドが成功するたびにテスト環境への展開を自動的にトリガーします。その後、Octopusポータルを使用して、他の環境への展開を促進します。
次のOctoコマンドラインを使用して、TeamCityからの展開をトリガーします。
Octo.exe create-release --apiKey=YourOctopusAPIKey --server=http://YourOctopusServer:9015/api --project=YourOctopusProjectName --deployto=YourOctopusEnvironment
Octoの作成-リリースステップは、別のTeamCityプロジェクトに含める必要があります。そうしないと、ビルドの結果のパッケージでNuGetが更新されません。
MSDeployを使用して、Webアプリケーションからデータベースまですべてを展開でき、Web Farm Frameworkを使用して、メインサーバーからセカンダリサーバーに同期できます(必要に応じて、さまざまなセットのパラメーターを使用して手動で行うこともできます)。
あなたが説明しているのは「デプロイメントパイプライン」です。チームシティに統合する方法はわかりませんが、基本的な前提は次のとおりです。
- アプリケーションをビルドし、テストしてパッケージ化します(設定する必要のあるパラメーターを宣言します)。パッケージ(および将来の手順で必要なファイル)をアーティファクトリポジトリ(サポートされている場合はTeam City)にプッシュします
- (自動的にトリガーされます)アーティファクトリポジトリからパッケージを取得し、を呼び出してdevにデプロイします
msdeploy -verb:sync -source:package.zip -dest:auto,computerName=http://server:8172/msdeploy.axd -setParamFile:dev.xml
- (手動でトリガー)パッケージをステージにデプロイします
- (手動でトリガー)パッケージをライブにデプロイします
MSDeployは、Windowsクレデンシャルマネージャーへのクレデンシャルの保存や、展開のほぼすべての側面のパラメーター化など、驚くほど多くの機能をサポートしています。ぜひチェックしてみてください。(Windows Serverライセンスとは別に、無料です)
場合によります。(この質問にはまだフラグが付けられていないことに気づきました)。しかしとにかく、それはおそらくあなた自身にこれらを自問する価値があります:
- QAがサインオフして宣伝する必要があるウェブサイトを開発していますか、それとも各ビルドを検証するために自動テストスイートを用意していますか?
- 複数の環境(QA、UAT、デモ、本番)にデプロイしていて、どのバージョンがどこにあるかを示す優れたダッシュボードを見たいですか?
- 特定のユーザーに本番環境にプッシュする権限が必要ですか?
- 他の種類のコンポーネント(Windowsサービス、データベースなど)を展開する必要がありますか
- 展開を開始する前に、各サーバーで追加のセットアップが必要ですか(たとえば、chocolateyを呼び出してMongoをインストールおよびセットアップします)。別名限定サーバープロビジョニング。
- プロモーションのライフサイクルを管理する必要がありますか(たとえば、QAを通過した場合にのみ本番環境に移行します)。
上記のほとんどに「はい」と答えた場合、OctopusDeployが展開に勝ちます。そして、何を推測するか、それは最大5つのプロジェクトと簡単に立ち上げて実行するために無料です。
エンドユーザーによる単純なCMS管理を必要とする単純なWebサイト、または開発者が保守する必要のないWebサイトの場合、すべてのAzureとMSDeployはその仕事に最適なツールだと思います。Richard Szalayが述べたように、最近は定期的に公開するための優れたコマンドラインツールがあります。
ビルドサーバーに関しては、アーティファクトを作成するためだけに使用する必要があるため、実際には問題ではありません。Team Cityは、Octopusとの統合が優れているため、私にとっては勝者です。IMO、それは別の議論です。