2

バックグラウンド

そのため、先月の大部分を、MSDeploy、SSDT、およびTeamCityを使用してWebとDBの展開を自動化することに費やしました。唯一の問題は、デモンストレーションの目的で、私はトランクブランチからしか作業していないということです。言うまでもなく、このアプローチは、並行して開発作業を行う必要があると考えるとすぐに失敗します（SVNのブランチによって分離されます）。これは私が立ち往生していて、いくつかの助けを見つけることを望んでいるところです。

私たちの状況

  • ソフトウェアの複数の同時バージョンをサポートする必要はありません
  • 顧客は常に現在のバージョンを使用しています

私が思いついたもの（これまでのところ）

私が見ているように、ソース管理には実際には2つのブランチしか必要ありません。

  1. 現在：トランク-展開元
  2. 次へ：現在のイテレーションの開発ブランチ

新しい反復の開始時に、Currentは分岐します（その分岐をNextと呼びます）。そのイテレーションのすべての開発はNextにコミットされ、同時に、現在のバージョンに必要なバグ修正はCurrentにコミットされます。ある時点で、Nextは「完了」し、したがってCurrentにマージされます。

展開

デプロイメントに関する限り、Nextはどの環境にもデプロイされません。ただし、 Currentは、定期的な間隔（コミットごと、夜間など）でTeamCityによって内部環境に自動的にパッケージ化/デプロイされます。ある時点で、これらのパッケージの1つは「十分に優れている」と見なされ、したがって、（ステージング、本番環境を通じて）デプロイメントストリームをプッシュダウンします。

警告

前述のプロセスを考えると、NextをCurrentにマージすると、 Currentでの「コードのフリーズ」が保証されます。その間、新しいバグ修正をクライアントにリリースすることはできません。このバグフリーズは、 Currentがクライアントにリリースするのに「十分」であると見なされるまで続き、その時点でCurrentにタグが付けられ、プロセス全体が最初からやり直されます。

質問

  1. このアプローチ/考え方は合理的ですか？
  2. このアプローチはどこに当てはまりますか？
  3. これについてもっと良い方法はありますか？

洞察/文書化は大歓迎です。

4

2 に答える 2

2

ソフトウェアのバージョンは1つしかないため、顧客にリリースするときにトランクにタグを付けて、トランクで開発を続ける方が簡単です。

開発中にソフトウェアを修正する必要がある場合を除いて、分岐する必要はありません。

開発用の分岐が、本番環境のバグ修正用の分岐よりも、自分と開発グループにとって適切かどうかを判断する必要があります。

于 2012-12-20T18:40:17.763 に答える
1

これらのシナリオの主な指示は、非本番コードをデプロイすることなく、本番バグを常に迅速に修正できるようにする必要があるということだと思います。「コードフリーズ中にバグ修正がない」という警告は、問題が（必然的に）発生したときに柔軟に対応する能力を損なうように感じます。

私たちのプロセスはあなたのプロセスと非常に密接に連携しています。次のような戦略で成功を収めています。

トランクはトランクです。
製品はトランクから分岐しています。製品リビジョンにはタグが付けられており、それらのタグからデプロイします。バグは修正され、このブランチからデプロイされます。これらの修正はトランクにマージされます。
次は、完了時にトランクに再統合される1つ以上の機能開発ブランチです。

出荷の準備ができたら、新しいProdを作成し、サイクルを最初からやり直します。

このモデルが気に入っている理由は次のとおりです。

  • 未開発のコードを組み込むことを恐れることなく、いつでも本番環境のバグ修正をデプロイできます。
  • これらの本番環境のバグ修正をメインラインに戻すのは簡単です。
  • 私たちのトランクは本質的にマージのログであり、かなりクリーンなままです。どの時点でも、トランクは合理的にProdに分岐できます。
  • 再統合後に機能ブランチを削除します。これは、カタルシス的で満足のいくものです。

私たちの経営陣は、問題に迅速に対応でき、回帰の可能性が低いため、このモデルを気に入っています。

于 2012-12-20T19:49:18.877 に答える