奇妙な会社のリリースサイクル：分散ソース管理に行きますか？

この長い投稿については申し訳ありませんが、価値があると思います。

私は小さな.NETショップから始めたばかりで、私が働いていた他の場所とはかなり異なった動作をします。私の以前の職務とは異なり、ここで書かれたソフトウェアは複数の顧客を対象としており、すべての顧客がソフトウェアの最新リリースを同時に入手できるわけではありません。そのため、「現在の製品バージョン」はありません。顧客が更新プログラムを入手すると、最後の更新以降にソフトウェアに追加されたすべての機能も入手しますが、これはかなり前のことです。ソフトウェアは高度に設定可能であり、機能のオンとオフを切り替えることができます。いわゆる「機能切り替え」です。ここではリリースサイクルが非常に厳しく、実際にはスケジュールどおりではありません。機能が完了すると、ソフトウェアが関連する顧客に展開されます。

チームは昨年だけVisual Source SafeからTeam Foundation Serverに移行しました。問題は、VSSのようにTFSを使用し続け、単一のコードブランチでチェックアウトロックを強制することです。バグ修正がフィールドに公開されるたびに（単一の顧客であっても）、TFSにあるものをすべてビルドし、バグが修正されたことをテストして顧客に展開します！（私自身は製薬および医療機器のソフトウェアのバックグラウンドから来ており、これは信じられないほどです！）。その結果、テストが行​​われなくても、半分焼き付けられた開発コードが本番環境に入ります。バグは常にリリースビルドに滑り込んでいますが、多くの場合、ビルドを取得したばかりの顧客は、バグが含まれている機能を使用しない場合、これらのバグを見ることはありません。突然、いくつかの大きなクライアントが参加し、さらに小さなクライアントが参加しました。

バグのあるコードや未完成のコードのデプロイを排除するためにソース管理オプションを検討するように頼まれましたが、チームリリースのやや非同期な性質を犠牲にしないでください。私は自分のキャリアでVSS、TFS、SVN、Bazaarを使用しましたが、TFSは私の経験のほとんどがあった場所です。

以前、私が働いていたほとんどのチームは、1か月間、開発者が直接Devで作業し、その後変更をTest then Prodにマージするか、または「ではなく」固定サイクル。Cruise ControlまたはTeam Buildのいずれかを使用して、自動ビルドが使用されました。私の以前の仕事では、BazaarはSVNの上に座って使用されていました。開発者は独自の小さな機能ブランチで作業し、変更をSVN（TeamCityに関連付けられていました）にプッシュしました。これは、変更を簡単に分離し、他の人のブランチと共有するのが簡単だったという点で便利でした。

これらのモデルの両方には、コードがプッシュされる中央のdevおよびprod（および場合によってはテスト）ブランチがありました（そしてラベルはリリースが行われたprodのビルドをマークするために使用されました...そしてこれらはバグ修正のためにブランチにされました）リリースし、devにマージします）。これはここでの作業方法にはあまり適していませんが、さまざまな機能がいつリリースされるかは決まっておらず、完了するとプッシュされます。

この要件により、「継続的インテグレーション」アプローチが崩れます。継続的インテグレーションで新しい機能を使用するには、dev-test-prodを介してプッシュする必要があり、devで未完成の作業をキャプチャします。

これを克服するには、dev-test-prodブランチを持たない機能の多い分岐モデルを使用する必要があります。むしろ、開発作業が完了するとロック、テスト、修正、ロックされる一連の機能ブランチとしてソースが存在する必要があります、テストしてからリリースしました。他の機能ブランチは、必要な場合や必要な場合に他のブランチから変更を取得できるため、最終的にすべての変更が他のすべてのユーザーに吸収されます。これは、前回の仕事で経験した純粋なバザールモデルに非常に当てはまります。

これは柔軟に聞こえますが、開発用トランクやprodブランチがどこにもないのは奇妙に思えます。災害を統合...

これについての人々の考えは何ですか？

2番目の最後の質問：分散ソース管理の正確な定義について多少混乱しています：一部の人々は、TFSやSVNのような中央リポジトリがないことを示唆しているようです。 TFSには完全に機能するオフラインモードがあります）、他の人は、機能分岐と親子関係のないブランチ間のマージの容易さについてだと言います（TFSにはベースレスマージもあります！）おそらくこれは2番目の質問です！

DVCSの定義は何ですか？

分散リポジトリのすべてのクローンは、すべての情報を持っていることDVCSに手段が今までに触れることなく、更新、ブランチ、マージをコミットするか、そのリポジトリ内の任意のリビジョンを検索するために必要なサーバーを。オフラインでできる唯一のことsvnは、実際にファイルを編集することですsvn -grepping anのような簡単なことを含め、ほとんどすべてのコマンドに対してサーバーアクセスが必要なsvn logので、実際には90％よりも0％に近くなります！

どれ権威中央レポジトリされたワークフローあなたはDVCSで設定可能性があることをちょうど別のクローン、およびあなただけの時間を必要とするあなたが他の人々の更新をプルダウンするときまたはあなたが他の人がそれらを見ることができるように、独自の変更をプッシュするとき、それと対話することがあります、他のほとんどすべてをオフラインで実行できます。

どの分岐モデルが適切ですか？

私はあなたが今いる状況にありました。そのようなシステムは本当に痛いことがありますが、あなたは彼らがこのようになった実際的な理由を理解し、それらが償還を超えていないことを認識しなければなりません。この種の複雑さの管理に役立つ多くのツールが開発されています。

まず第一に、あなたが何をしても、成功したgit分岐モデルを人々に見せないでください。それは単にそれらを混乱させ、それらをオフにします。代わりに、独自のモデル開発、既存のワークフローを反映して、まだ既存のワークフローの問題を解決します。

検討する必要のあるリソースには、Git サブモジュールなどがあります。これにより、さまざまな顧客リリースが顧客構成、アプリケーションモジュール、ライブラリのさまざまな組み合わせを指定できるようになります。別のオプションは、パッチ管理システムを使用して、顧客/製品固有のパッチキューを適用することです。

これらのオプションは両方とも、現在のワークフローよりもはるかに高い柔軟性、透明性、安全性を提供し、さらに複雑なブランチのみの戦略よりも使いやすい可能性があります。私があなたの状況にあったときに、これらのツールにアクセスできることを望みます。

これらのオプションの詳細については、モジュラーシステムでバージョン管理を使用する戦略への回答を参照してください。Gitリポジトリ内でSubversionリポジトリを使用するには？そして複数の企業で使用されるアプリケーションのソース/バージョン管理。

最終的に、これは本当にチームの他のメンバーと一緒に開発する必要があるものです。すでに持っているものよりも優れたものを提案し、仲間の開発者の賛同を得られるようなビジョンを持っているなら、それをはるかに簡単に過ごすことができるでしょう。

最も重要なことは、あなたの提案があなたの生活を楽にする方法を同僚に示すことです。いったん納得すると、経営陣にTFS への投資を捨てさせ、作業方法により適したモデルを使い始める可能性が高くなります。

第一に、DVCSはあなたが抱えている問題の真相です-使用中のバージョン管理ツールは、解決しなければならない問題の根源ではありません。DVCSソリューションには、TFSよりも「優れた」側面があるかもしれませんが、この時点で修正する必要があるものではありません。

組織に合った実行可能な分岐構造が必要であることを確認しました。機能が完了すると、トランクにマージされて閉じられるトランクがまだあると思います。一般的な依存関係をどのように実装するかについて、いくつかの良い考えがあります。

また、継続的なインテグレーションが機能する必要があります（アクティブなブランチごとにビルドを自動化しないことで、そのブランチをビルドでき、関連するテストに合格するという自信が得られます）。コミット（または少なくとも「プッシュ」）によってビルドがトリガーされない場合は不快です。

そして、すべてのレベルで自動テストを開始する必要があります。特に、単体テストと統合テストは、新しいバグが野生に逃げる可能性を減らすために開始する必要があります。この最後は巨大で、私はまだ苦労していますが、一度物事を構築できるとわかったら、これが最も価値があることは明らかです。

これを組み合わせて、展開パッケージがビルドサーバーから取得され、展開が可能な限り自動化されていることを確認する必要があります（最小限の労力と最小限のストレスで、ビルドサーバーアーティファクトからライブ展開されたコードに移行できるはずです）。

うーん、うまく整理された問題追跡セットアップがあると思いました...あなたもそれを必要とし、それが適切に使用されていることを確信するために。理想的には、ライブアプリケーションがこのシステムに（またはトリアージのために）エラーを自動的にフィードバックすることを望みます。

最後に、すべての問題を一度に解決しようとしないでください。ビルドとテストは、あなたが最初に集中すべき場所であるように思えます。

2番目の質問は簡単で短いので、そこから始めようとします

DVCSはシステムであり、「権限のある」コードソース（使用時の「同意」を除く）はなく、追加の層（個人的な非正規の定義）なしでデータのP2P交換が可能です。

トピックの最初の質問

「どうにかして管理された予測可能なコード」を得るために、会社はワークフローを再構築し、スタイルについて再考する必要があるのではないかと心配しています。TFSについては言えません（個人的な意見と感情、バージョン管理部のシステムが弱いということ/ baseless merge is evil /）が、あなたの状況のVCSについては（「製品」は独立した「モジュール」のセットです、各「顧客」は異なる「製品」を取得します-この仮定は正しいですか？）モジュールの開発を別々のブランチに分割し、製品を「スーパーモジュール」（またブランチ？）として、各モジュールがモジュールの特定のリビジョンに関連付けられていることを好みます-ブランチ、モジュール開発では、タスクごとのブランチパラダイムを使用します（モジュールブランチはマージセットのみで構成されます）。

このようにして、どの「コレクション」（つまり、モジュールのセットとそれに対応するリビジョン）が各「製品」を形成し、CI（完成したタスクブランチとマージされたタスクブランチ）、ユニットテスト、ビルドを実行できる可能性が常にあります

広告の主な質問：あなたが話しているのは、Gitの成功した分岐モデル（およびそれをサポートするヘルパーツールgit flow）がまさにその内容だと思います。常に展開可能な状態にあり、機能ブランチですべての作業を行うマスターブランチがあります。

git自体が使用するプロセスを使用することもできます。これは、同じ基本原則から派生しています。git-core開発では、すべての作業は機能ブランチで行われます。機能ブランチはインテグレーターに送信されます。インテグレーターはスクリプトを実行してそれらすべてをマージし、pu（提案された更新）という名前のブランチを作成します。さまざまな人々がこのブランチを使用してテストします。

インテグレーターの代わりに、ビルドの開始時に継続的統合サーバーにこのマージを実行させることができます。チームのだれかが機能ブランチとして中央リポジトリに変更をプッシュするときはいつでも（おそらく、どのブランチを選択すべきかを示すために何らかの命名規則を使用して）。

gitでは、機能ブランチはに進むかnext、ターゲットとするリリースによって異なります（メイントは現在のリリースのバグ修正、現在の準備中のリリースのマスター、その後のリリースのマスターです）が、それほど多くはありません。mastermaint

機能が入っている間pu（gitメンテナーの用語では「料理」）、それらは巻き戻され、pu毎回ブランチが破棄されて再作成されます。機能ブランチがメインラインの1つにマージされると、巻き戻しのために閉じられ、新しいコミットとしてさらなる修正が行われます。

個人的にはgitベストをお勧めします。それはより有機的に成長するため、最初に学ぶのは少し難しいですが、最終的には最も柔軟に見えます。しかし、3つの分散システム、git、mercurial、およびbazaarのいずれも役立ちます（たとえば、mercurialはgitリポジトリに対してプルおよびプッシュできるため、bazaarも可能です）。

広告の2番目の質問：「分散」とは、一般的に、オブジェクトを移動でき、そのアイデンティティを保持することを意味すると教えられました。これは、分散バージョン管理が行うこととまったく同じです。リポジトリを複製すると、同じコミットが含まれ、同じコミットを実行できます。分岐の容易さと切断された操作は、コミットを移動するという原則とそれを可能にする有向グラフレイアウトに従う原則的なユーザーレベルの機能です。

残念ながら、コードのバグに対する既知の解決策はありません:)

したがって、未完成のチェックインがメインリリースに追いつかないようにしたいだけで、それに対する唯一の答えは、各開発者のブランチワークマージです。Clearcaseを使用して以前の会社でこれを行いましたが、非常にうまく機能しました（数十人のClearcase管理者が必要でしたが）。

また、各顧客が現在持っている製品のバージョンでバグ修正を実行すると仮定します...そのため、バージョンAからバージョンZまでバグ修正をもたらすマージの問題があります。対処する簡単な方法はありません。ただし、出荷されたバージョンごとにブランチが必要です。これに対処する最善の方法は、機能ブランチを最新バージョンのみに維持し、顧客にアップグレードして新しい機能を取得すると同時に、リリースブランチでバグ修正を直接実行し、それらを他のすべてのリリースブランチにマージすることです完了したら。

あまりいいことではありませんが、非常にうまく機能します。コードを整理し、適切に分離してください。また、他の開発者にとっても理解しやすい-「コード」に直接小さなバグ修正を行い、数行を超える作業は専用のブランチで行い、完了までにかかる時間をかけることができます。（マージの問題を整理し、2人の開発者が同時に2つの機能を使用しても大丈夫だと安心させる必要があります!!）

しばらくすると、リリースブランチにも機能ブランチを導入できます。バグは修正されてからマージされますが、私見ではこれは通常、必要以上の労力です。ただし、古いリリースに機能を追加する必要がある場合は、このアプローチに従う必要があります-リリースブランチにブランチし、次にそのリリースにコードをマージし、変更を後のリリースにもマージします。これにより、複数のバージョンを繰り返しテストする必要があるためリリースが大幅に遅れ、テストチームは非常に不満になり、開発チームは新しいコードを開始する前に多くのマージを行う必要があるため不満になります（私の現在の会社では）これは主に、できるだけ早く完了する必要がある作業の量が原因です。

DVCS：

基本的にDVCSは、誰もがサーバーリポジトリの独自のコピーを持っている場所です。これにはいくつかの利点がありますが（特に限定されたコミニュケーションを持つ分散チームで）、いくつかの欠点もあるため、DVCSに切り替える前にそれらをチェックしてください。あなたがWindowsショップなら、Mercurialがあなたにとって最高のDVCSであることに気付くでしょう。