0

ASP.NET (Webforms と MVC) を扱う小さな Web 開発ショップを経営しています。私たちはさまざまなクライアントと仕事をしているため、いつでも多くのプロジェクトがアクティブになる可能性があります (メンテナンスの更新やバグ修正を待っているプロジェクトもあります)。

現在、非常に手動の方法で展開しています (FTP ファイルをサーバーに、リモートをサーバーに、ライブ サイトをバックアップ フォルダーにコピーし、新しいファイルをライブ サイトにコピーします)。明らかに、これには多くの要望が残され、間違いが発生します。

CI と自動化されたビルドおよびデプロイ ツールについて多くのことを読んできましたが、それらはすべてセットアップがかなり困難に見えるため、頭を悩ませることはできません。

私はこの展開プロセスを自動化することを検討しており、学習して使い始めるのに最適なツールを見つけようとしています。

  1. 開発者はコードをローカル マシン上の Mercurial にチェックインし、ネットワークに接続されたビルド サーバー上のマスター リポジトリと同期します。
  2. ビルド サーバーがビルドを開始し、単体テストが適切であることを確認します。すすいで繰り返します。
  3. 開発者は、FTP 経由でリモート Windows サーバーへの展開を手動で選択します (別の方法はありますか?) zip ファイル (理想的には、以前に展開されたバージョンから変更されたファイルのみを含む)。
  4. リモート サーバーは、FTP で転送されたファイルが格納されるフォルダーをポーリングし、それらを解凍してテスト フォルダーにコピーし、テスト データベースをバックアップして、テスト データベースに対してアップグレード スクリプトを実行します (または、migratordotnet や rikmigrations などの移行アプリを使用します)。構成変換も実行する必要があります。
  5. クライアントは変更をレビューして受け入れるか、フィードバックを提供します。
  6. クライアントが受け入れた場合、開発者はリモート サーバーの Web インターフェイスの [Deploy to staging] ボタンを押して、ライブ データベースをバックアップし、ステージング データベースに復元し、ライブ サイトのファイルをステージング サイト フォルダーにコピーします (実質的にライブ サイトのクローンを作成します)。テスト サイトの変更されたファイルがステージング サイトにコピーされ (テスト イメージのアップロードなどの特定のフォルダーを除く)、移行スクリプトが再度実行されます。
  7. 開発者は、変更がステージング サイトを壊していないことを確認します。
  8. 開発者がリモート サーバーの Web インターフェイスで [Deploy to live] ボタンを押すと、ライブ サイトがバックアップ フォルダーにコピーされ、ステージング サイトのファイルがその場所にコピーされます (ユーザーがアップロードした画像などを除く)。ライブ データベースがバックアップされ、移行スクリプトが実行されます。
  9. 何か問題が発生した場合、開発者は、バックアップ ファイルをライブ サイトのフォルダーにコピーして戻し、以前のデータベースを復元することで、ライブ サイトを以前のバージョンに戻すことができます。

何百もの設定可能なオプションに苦労する必要はありません。新しいプロジェクトのセットアップが迅速 (5 分以内) で、繰り返し可能である必要があります。

私たちはエンタープライズではありませんが、これを実現するためにいくらかのお金を費やさなければならない場合は、ライセンス料を支払う準備ができています.

4

1 に答える 1

3

私はBuildMasterの開発者です。これは、基本的にここにリストされているすべてのことを実行するツールです。それがどのようにあなたを助けることができるかについて、私はあなたの箇条書きのいくつかに触れようとします：

  1. BuildMasterはMercurialを（他のいくつかのVCSとともに）サポートしているため、自動展開中にコードにラベルを付けたり、ラベル付き（または最新の）コードを取得したりできます
  2. BuildMasterでデプロイメントプランを作成しているときに、単体テストに合格しなかった場合、ビルドを「迅速に失敗」させることができます。
  3. BuildMasterは、自己ホスト型またはIISホスト型のエージェントを使用します。これらのエージェントは、ビルド元または展開先の任意のサーバーにインストールできます。BuildMasterは、ビルド出力を組み込みの「ビルドアーティファクト」に圧縮することに関してさらに一歩進んでいます。これは、既存のWebサイトの上部に全体としてデプロイするか、一時ディレクトリにデプロイしてから、に転送することができます。変更されたファイルのみが転送されるようにWebサーバー-ファイル/ディレクトリを除外することもできます（たとえば、\ Uploads、\ Logsなどを除くすべてを同期します）
  4. デプロイする変更されたファイルについてディレクトリをポーリングするための外部ツールは必要ありません。デプロイプランの一部として「バックアップデータベース」を含むBuildMasterの「PromotetoTesting」をクリックするだけです。BuildMasterのデータベースは、各環境が独自の「インスタンス」を持つように処理され、環境のデプロイメントプランに追加されたときに、環境ごとに1回だけ実行されることが保証される変更スクリプトを設定できます。
  5. BuildMasterのアーキテクチャ（基本的には、作業を行うサービス/データベースバックエンドを備えたWebアプリケーション）を使用すると、Webアプリケーションの必要な部分をクライアントに公開して、テストビルドを次のようにプロモートする前に「承認」することができます。次のテスト環境。
  6. ステージング展開計画にデータベースのバックアップと本番ファイルのコピーが含まれている場合は、[ステージングに展開]ボタンをクリックすると、計画に含めるすべてのことが実行されます。
  7. 私たちの承認システムはこれを処理できます（たとえば、1人の開発者と1人のマネージャーが本番環境に移行する前にビルドを承認する必要があります）
  8. ＃7と同じ
  9. このステップは主にBuildMasterで実行できます...ソフトウェアに組み込まれている「復元」機能はありません。ただし、BuildMasterに組み込まれているアーティファクトストレージを使用すると、古いプロモーションを本番環境に再実行でき、古いzip形式のアーティファクトファイルをワンクリックで元に戻すことができます。データベースの場合、少し注意が必要です。手動でDBを復元する必要があります。

通常、インストールプロセスは数回クリックするだけで、SQL Server Express（インストールの一部）またはSQLServerの独自のインスタンスを使用してBuildMasterをホストするWebサーバーにASP.NET2.0がインストールされたIISのみが必要です。

初期設定はかなり簡単なはずです。公開SVNリポジトリのソースコードから「アプリケーション」を作成してビルドするソフトウェアの例があります。

あなたが好きかもしれない他の主な機能は、構成ファイルの管理です。ASP.NETについて言及しているので、BuildMasterでweb.configファイルをテンプレートとして作成し、環境に基づいてさまざまな値を使用して展開計画の一部として展開できます。このように、開発バージョンをソース管理に保持し、残りのテスト環境用に1つのテンプレートバージョンをBuildMasterに保持するだけで済みます。

無料トライアルから始めてチュートリアルを読んで、基本的なアプリケーションを起動して実行することをお勧めします。ご不明な点がございましたら、当社のWebサイトに統合されたヘルプがあり、インストールするとアプリケーションに組み込まれます。この投稿に追加できないものがたくさんあるので、役立つかもしれません（手動の変更管理の追跡、通知、レポート、拡張性など）。興味のある方は、機能の完全なリストをチェックしてください！

于 2011-05-04T00:32:07.033 に答える