当社の Web サイトでは、継続的展開と最も正確に呼ばれるスタイルで開発しています (http://toni.org/2010/05/19/in-praise-of-continuous-deployment-the-wordpress-com-story/ )
Web ファームがあり、すべてのサイトはフェイルオーバーのために 2 台のサーバーに配置されています。開発サーバー、テスト サーバー、本番サーバーへのデプロイ プロセスを自動化したいと考えています。Web サイトは ASP.Net Web サイト (Web アプリケーションではない) であるため、ビルドは行わず、ページをプッシュするだけです。多くの変数に応じて、通常、メイン サイトを 1 日に 2 ～ 20 回変更します。これらの変更は、新しいページ/機能を追加するための単純なテキスト/html の変更です。
現在、ソース管理に TFS を使用しており、各サイトは独自のリポジトリです。ブランチはありません。変更を確認する必要がある場合は、手動で変更を dev (ローカル マシンで開発) にプッシュし、サインオフ後に変更をチェックインして手動で prod にプッシュします (これにより、ソース ファイルが確実には実際に本番環境にあり、マージはすぐに行われます）。明らかに、ここには多くのエラーの余地があり、まれに、開発者が重要なファイルを忘れてサイト全体をダウンさせることが発生します.
ほとんどの展開ツールはビルド プロセスに基づいて構築されているようですが、ビジネス ニーズを満たすために非常に機敏である必要があるため、このプロセスに移行する可能性は低いです。私たちが本当に望んでいるのは、次のようなものだと思います。
- 開発者はソース管理からウェブサイトの最新バージョンを取得します。これは基本的に本番環境のコピーです
- Dev は自分のボックスで作業を行います。
- タスク所有者がレビューする準備ができたら、彼はなんらかの形式の変更セット (変更をチェックインするか、その他のもの) を作成し、ツールがその変更を dev にプッシュします。
- レビュー (およびさらに可能な変更) の後、開発者はツールにこのタスクのすべての変更をテスト (UAT) にプッシュさせることができます
- このサインオフの後、変更は自動的に本番にプッシュされ、本番ブランチなどにチェックインされ、他のユーザーが取得できるようになります
TFS にコードの 3 つのブランチを用意するというアイデアをいじくり回しましたが、1 つのブランチ (prod) からプルして dev ブランチにチェックインする方法はわかりません (私たちの誰も TFS の専門家ではありません)。
では、他の人々はこのシナリオをどのように処理したのでしょうか? 私たちが望んでいたことを行う何かがそこにある場合、または垂直ソリューションを必要としない場合、ソース管理プロバイダーとして TFS に固執することはありません。プラグインできる限り、さまざまなコンポーネントを喜んでプラグインします。 、または必要に応じて独自に開発することさえできます。
前もって感謝します。