タグ付けされた質問 「team-foundation-server」

Team Foundation Server（一般にTFSと略されます）は、ソース管理、データ収集、レポート作成、およびプロジェクト追跡を提供するマイクロソフト製品であり、共同ソフトウェア開発プロジェクトを対象としています。

15
カウボーイプログラマーにソース管理を使用するよう説得するにはどうすればよいですか？
更新 私は4人の開発者の小さなチームで働いています。それらはすべてソース管理を使用しています。それらのほとんどはソース管理に耐えられず、代わりに使用しないことを選択します。ソース管理は専門能力開発の必要な部分だと強く信じています。いくつかの問題により、ソース管理を使用するように説得することが非常に困難になります。 チームはTFSの使用に慣れていません。2回のトレーニングセッションを行いましたが、1時間しか割り当てられていませんでした。 チームメンバーは、サーバー上のコードを直接変更します。これにより、コードが同期しなくなります。最新のコードで作業していることを確認するためだけに比較が必要です。そして、複雑なマージの問題が発生します 開発者が提供する時間の見積もりには、これらの問題の修正に必要な時間は含まれていません。ですから、nonoと言うと10倍時間がかかります...これらの問題を絶えず説明し、自分自身を危険にさらす必要があります。 サーバー上の物理ファイルは、〜100ファイルにわたって未知の点で異なります。マージには、当面のプロジェクトの知識が必要であり、したがって、開発者の協力を得ることはできません。 他のプロジェクトは同期していません。開発者はソース管理に不信感を持ち続けているため、ソース管理を使用しないことで問題を悪化させています。 開発者は、マージはエラーが発生しやすく、難しいため、ソース管理の使用は無駄だと主張します。これは議論するのが難しいポイントです。なぜなら、ソース管理がひどく誤用され、ソース管理が継続的にバイパスされると、間違いが起こりやすいからです。したがって、彼らの見解では証拠は「それ自身のために語る」。 開発者は、サーバーコードを直接変更し、TFSをバイパスすると時間を節約できると主張します。これも議論するのが難しいです。開始するコードを同期するために必要なマージには時間がかかるためです。これに私たちが管理する10以上のプロジェクトを掛けます。 永続ファイルは、多くの場合、Webプロジェクトと同じディレクトリに保存されます。そのため、公開（完全公開）は、ソース管理にないこれらのファイルを消去します。これはまた、ソース管理に対する不信感を引き起こします。「公開するとプロジェクトが壊れる」ためです。これらの場所はweb.configで設定されておらず、多くの場合複数のコードポイントに存在するため、これを解決する（保存されたファイルをソリューションサブフォルダーから移動する）には多大な時間とデバッグが必要です。 だから、文化はそれ自体が持続します。悪い習慣はより悪い習慣を生みます。悪い解決策は、新しいハックを駆り立てて、より深く、より時間のかかる問題を「修正」します。サーバー、ハードドライブのスペースを手に入れるのは非常に困難です。それでも、ユーザーの期待は高まっています。 この状況で何ができますか？
7
バージョン管理の方法に何か問題がありますか？
私はプログラマーのチームとビジネスアナリストとして仕事をしています。製品のバージョン2.0をリリースしたばかりで、3か月後にリリースされる次のバージョンに取り組んでいます（内部ソフトウェア製品です）。残念ながら、バージョン2.0には修正が必要な問題がいくつかあり、数週間以内に修正を展開する予定です。問題は、まだ作業中であり、さらに3か月間リリースされる予定のない変更を展開したくないことです。 プログラマーは、これを管理する方法は、欠陥のコードのみをチェックインし、新しい拡張機能のコードは、完了するまで開発者のローカルマシンに保持することであると判断しました。テストのためにマシンからローカルビルドを取得する必要があります。彼らがコードをチェックインし、不具合を修正するために別のパッチをプッシュする必要がある場合、それらの機能強化をまだ含めたくないからです。また、同じコードファイルに不具合の修正と機能強化の両方が含まれるという問題もあるため、ローカルでコードファイルをコピーし、バグを修正するために変更を加えてバグをチェックし、その後、彼らが作ったローカルコピー。 かなり複雑に思えます-このタイプのシナリオを処理するより良い方法はありますか？Team Foundation ServerとVisual Studio 2010を使用しています。
22
ソースコードをチェックインする前のいくつかの良い習慣は何ですか？[閉まっている]
私のチームはソース管理にTeam Foundation Serverを使用しています。今日、チェックインする前にいくつかのバグとスモークテストアプリケーションを修正しましたが、コードをコメントするのを忘れていました。（このコードにより、UIが少し奇妙になりました。） コードをチェックインする前に、どのような優れたプラクティスがあるのか​​を知りたい-この種の間違いを二度とやりたくない。
10
間違ったブランチで作業することをどのように回避しますか？
通常、問題を回避するには注意するだけで十分ですが、時々、ランダムのソース管理パスをチェックして、作業中のブランチを再確認する必要があります（例：「うーん... devブランチにいますか？」）ファイル。 もっと簡単な方法を探して、それに応じてソリューションファイルに名前を付けることを考えました（例 MySolution_Dev.sln）が、各ブランチで異なるファイル名を使用して、ソリューションファイルをマージすることはできません。 大したことではありませんが、正しいブランチにいることをすばやく確認するために使用する方法や「小さなトリック」はありますか？TFS 2008でVisual Studio 2010を使用しています。
4
製品バックログ項目とタスクの違いを説明する
この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 6年前に移行 。 私はこの課題に何度か出くわしました。製品バックログアイテムとTFSのタスクの違いを説明する方法について、誰かが参照、トレーニング、またはアドバイスを提供できることを望んでいます。 製品バックログ項目は「何」であり、タスクは「方法」であると理解し、説明しました。また、PBIが要件であり、タスクが要件を満たす方法であることも説明しました。 私がこれを説明するとき、私は繰り返し空白の視線と頭の傷に会います。これを説明するソフトウェアエンジニアは区別できないようです。それらはすべて同じです。 私のもう一つの課題は、区別することが重要である理由を効果的に説明できないことだと思います。
4
TFSを使用して、プロダクションサポートからのバグを追跡する
私はちょうど新しい会社に移りましたが、彼らはバージョン管理システムとしてTFS 2010（2、3か月で2012）を使用しており、最近、開発者の作業追跡システムとして使用し始めました。 ただし、開発とテスト以外の人が使用するバグ追跡システムはないようです。実稼働サポートは、問題のレポートを取得し、その場で修正し、現時点でユーザーに報告します。これを変更する必要がありますが、バグを追跡したり開発作業を追跡したりするためのシステムを用意したくありません。 FogBugzと同じように、TFSにバグを入力する非常に軽量な方法を作成できる方法はありますか？バグレポートに記入するためにTFSにログインするのはかなり重いようで、特定のアプリケーションに関連付ける必要があります。サポートはこれを行うことができるかもしれませんが、アイテムのトリアージを行い、アプリケーション以外の関連付けを潜在的に変更できるようにしたいと考えています。 私は過去にFogBugzを使用しましたが、バグを追加するときに、アイテムに必要に応じて大/小を追加して、少なくとも記録し、後でチケットをトリアージするときに戻って情報を取得することができます。
3
小さなチームにバージョン管理分岐ポリシーを導入する
私は最近会社で始めた請負業者です。 チームは3人の開発者であり、2人の下級から中級レベルの開発者で構成されており、同じレベルの別の開発者が間もなく開始され、私（6年xp）です。両方の既存の開発者にとって、それは大学/大学からの最初の仕事であり、彼らは以前に自分の仕事を監督する上級開発者を持ったことがありません。 明示的なバージョン管理ポリシーはありません。開発者はすべての開発をトランクで行い、開発マシンから直接本番環境に展開します。既存のチームは分岐に精通していません。 これをすべて変更し、CI、TDDテスト/ステージング/プロダクションサーバーなどを導入し、これを補完するバージョン管理ポリシーを導入します。 ソース管理システムはTFSであり、これまで使用したことはありません。1つの巨大なリポジトリとして構成されています。 私はそれらのいくつかの指針を書き留めましたが、チームの経験を念頭に置いて、追加/修正する必要がある他のものはありますか？ バージョン管理ポリシー 開発はトランクで行われます 変更に1週間以上かかると推定される場合は、ブランチで行う必要があります。トランクからブランチへの定期的なマージを行い、2つの同期がとれないようにします。 本番コード用に作成されたリリースブランチ。そのブランチには、安定したコードのみが含まれている必要があります。スプリントごとに1回、トランクから更新される1つのリリースブランチを作成するか、週ごとに個別のリリースブランチを作成することができます。 本番コードに影響する緊急のバグ修正を行う必要がある場合は、リリースブランチで行われ、トランクにマージされます。 1つのリリースブランチ戦略を採用する場合、トランクはスプリントの終わりに向かってスプリントごとに1回リリースブランチにマージされます。 リリース戦略ごとに個別のブランチを採用する場合、トランクはリリースブランチにマージされません。 一部のシナリオでは、分岐が多すぎる場合、異なる分岐でバグを2回修正する必要があります。短いスプリントをしている場合、これはあまり頻繁に起こるべきではありません。 3台のサーバーを使用する予定です。リポジトリ内の最新のコードを常に実行しているテスト環境。リリース候補コードおよびUATをステージング/テストするための最新のリリース候補を実行しているステージング環境、および運用環境。 私がこれを行うことを計画している理由は、これまでクライアントは内部ソフトウェアのみを実行していたためです。最新のプロジェクトは注目度の高いメディアクライアント向けであり、私は、チームが現在行っているものよりも専門的な開発モデルを採用する必要があると感じています。 たとえば、現時点では、ユーザーはバグレポートを使用してチームに電話をかけることができます。開発者はバグを見つけて修正し、自分のマシンで簡単な目玉テストを実行してから、実稼働環境に直接展開します。自動テストなどはありません。 後知恵では、機能ブランチはあまりにも遠いステップだと思うので、削除します。 したがって、本質的には、a）まったく分岐しない）b）リリースブランチとトランク、およびc）リリースとトランクごとのリリースブランチになります。 私は後者に傾いていました。私の最初の考えは、リリース候補と別々のサーバー（UAT / Production）で同時に稼働するリリースの両方を同時に持つことですが、事実上、トランクはいつでもリリース候補であるため、リリースは非常識に傾いています。私が考えたのは、利害関係者に開発コードを見せたくない場合は、別のリリース候補ブランチが必要になるかもしれないが、YAGNIとその他すべて.....
3
TFSを2つのローカルディレクトリにマップする方法[終了]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新することがありますので、上のトピックソフトウェア工学スタックExchange用。 6年前に閉鎖されました。 TFSを使用して、Webアプリケーションで作業しています。サイトを構築するたびに、再起動に非生産的に長い時間がかかります。私はcドライブ上のサイトの2番目のマッピングを持ちたいと思います。そこでは、最新版を取得して1日に1回だけビルドするので、このバージョンは常に高速です。個人的には編集しないので、これは「読み取り専用」ディレクトリのようになります。 これが可能かどうか、または他に選択肢がある場合はお知らせください。
7
TFSからGitへ
私は.NET開発者であり、ソース管理ソフトウェアとしてTFS（チーム基盤サーバー）を何度も使用しています。TFSの優れた機能は次のとおりです。 Visual Studioとの良好な統合（だから私はほとんどすべてを視覚的に行う;コンソールコマンドはなし） 簡単なチェックアウト、チェックインプロセス 簡単なマージと競合解決 簡単な自動ビルド 分岐 ここで、Gitをオープンソースプロジェクトのバックボーン、リポジトリ、およびソース管理として使用したいと思います。私のプロジェクトは、C＃、JavaScript、またはMySQLを使用したPHP言語、またはストレージメカニズムとしてのSQL Serverデータベースです。 この目的でgithub.comのヘルプを使用し、そこでプロファイルを作成し、Git用のGUIをダウンロードしました。ここまではとても簡単でした。 しかし、私はこれ以上先を行くことにほとんど詰まっています。次のようないくつかの単純な（本当に単純な）操作を行いたいだけです。 Gitでプロジェクトを作成し、ラップトップのフォルダーにマッピングする ファイルとフォルダーのチェックアウト/チェックイン 競合の解決 それが今私がする必要があるすべてです。しかし、GUIはユーザーフレンドリーではないようです。GUIにはそのConnect To...ようなものがあり、プロジェクトのリストが表示されることを期待しています。1つを選択すると、TFSプロジェクトを探索するのと同じように、そのプロジェクトのファイルとフォルダーのリストが表示されますVisual Studioで。次に、ファイルを右クリックして、check-in...またはcheck-outそのようなものを選択できるようにします。 私は多くを期待していますか？TFSのようにGitを簡単に使用するにはどうすればよいですか？ここで何が欠けていますか？
5
.NETアプリケーション間でコードを共有する最も効果的な方法は何ですか？
私たちの仕事には、多くの基本機能を共有するいくつかの異なる.netアプリケーションがあります。クリーンなn層アーキテクチャを使用してこれらのアプリケーションを構築しましたが、同じ機能を何度か再実装したことに気付いたその瞬間にヒットしました。これは明らかにDRYに違反するため、修正する必要があります。すでに一般的なグルーコード（IoCの配線、ログ、設定）にNugetを使用していますが、すべてのアプリケーション間でデータ層とビジネス層を共有したいと考えています。このアイデアは、UIが実際に必要なビジネスレイヤーの部分のみを処理するというものです。 これは最初は簡単な問題のように見えますが、進行中の開発には落とし穴があり、どのように進めればよいかわかりません。すべてを支配するために1つのビジネスレイヤーを作成するとします。簡潔にするために、「Foundation」と呼びます。Foundationを使用するためにアプリケーションを移植しましたが、すべてが素晴らしいものです。Foundationはnugetを介してライトUIレイヤーに配布されており、見栄えが良いです。しかし、その後、アプリケーションに機能を追加し始め、トラブルに直面します。 プロジェクトAに取り組んでおり、Foundationの変更を必要とする新しい機能を追加するとします。Foundation（Foundation-A）に変更を加え、不安定なパッケージとしてNugetフィードにプッシュします。プロジェクトAは最新のnugetパッケージを取得し、すべてが良好です。一方、別の開発者がプロ​​ジェクトBに取り組んでいます。彼はソース管理から最新のFoundationを取得しますが、安定したブランチから取得するため、プロジェクトAの変更はありません。彼は変更を加え、Foundation-Bを作成しました。そして、すべてが良いです。しかし、その後、実際にコードを共有できるFoundation-AとFoundation-Bの実装機能を発見したため、それらを組み合わせます。一方、Foundation-Cは独自の変更を加えてそこに浮上しています。最終的に、Foundation-Bの運用準備が整いました。しかし、その後、プロダクションA、B、 これはうまくいくように思えますが、異なるデータベーススキーマで作業し、FoundationリポジトリのさまざまなブランチとプロジェクトA、B、Cリポジトリ間ですべてを同期させることを心配しています。おそらく多くの手作業が必要になるようで、エラーの可能性が広がります。これを可能な限り自動化したいと思います。 使用しているスタックは次のとおりです。C＃、継続的インテグレーションを備えたTFS、Nuget。当社のアプリケーションはすべて、さまざまな種類のASP.NETアプリケーションです。物事を簡単にする場合は、さまざまなSCMを検討します。 さまざまなソースコードブランチでNugetを正常に保つ方法を探しています。間違ったNugetパッケージを参照するため、誤って開発コードを本番環境にプッシュしたくありません。
5
奇妙な会社のリリースサイクル：分散ソース管理に行きますか？
この長い投稿については申し訳ありませんが、価値があると思います。 私は小さな.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番目の質問です！
1
最善の方法：既存のTeam Foundation Server（TFS）ソリューションを再構築する
私の部署では、ユニファイドコミュニケーションサーバー用にいくつかの小さなアドオンを開発しています。バージョン管理と分散開発では、Team Foundation Server 2012を使用します。 ただし、すべてのアプリケーションとライブラリに対応する大規模なTFSソリューションは1つだけです。 主な解決策 用途 アプリ1 アプリ2 アプリ3 外観 図書館 Lib 1 Lib 2 道具 「アプリケーション」パスには、すべての主要なアプリケーションが含まれています。これらは互いに依存していませんが、ライブラリと外部プロジェクトに依存しています。 「外部」パスには、アプリケーションとライブラリで参照される外部DLLが含まれています。 ライブラリパスには、一般的に使用されるライブラリ（UIテンプレート、ヘルパークラスなど）が含まれています。これらは互いに依存せず、ライブラリおよびツールプロジェクトで参照されます。 ツールパスには、セットアップヘルパー、更新Webサービスなどのヘルパープログラムが含まれています。 さて、この構造を変更したい理由はいくつかあります。 サーバービルドは使用できません。 そのようなソリューション構造で、スプリント、障害などでTFSスクラム管理を管理するのは不快です。 すべての開発者は、ソリューション内のすべてのプロジェクトに常にアクセスできます。 Visual Studioで誤って[F6]を押した場合、完全なビルドが長すぎます... このソリューションで何を変更しますか？それらのプロジェクトをより小さなソリューションにどのように分割し、それらのソリューションをどのように構成すべきですか 最初のアプローチは、アプリケーション、ライブラリ、およびツールごとに1つのTFSプロジェクトを作成することです。しかし、たとえばApp 2に常に最新バージョンのLib 1が含まれていることを確認するにはどうすればよいですか？Lib 1の変更を監視し、Libが変更されたらすぐにApp 2を手動で更新する必要がありますか？または、何らかの方法でVisual Studioに常に外部プロジェクトの最新バージョンを常に使用させることができますか？ 編集： TFSには、1つのTFSチームプロジェクトを含むTFSチームプロジェクトコレクションが1つだけあります。チームプロジェクトには、1つの大きなVisual Studioソリューションが含まれています。このソリューションには、複数のVSプロジェクトを含む複数のフォルダー（上記の構造を参照）が含まれています。 私の質問は今、どのように再編成しますか： TFSチームプロジェクト VSプロジェクト
6
リリースに適した分岐戦略の選択
新しいプロジェクトの新しい開発チームから始め、ソースリポジトリ（Microsoft Team Foundation Server 2010など）の分岐戦略を定義する必要があります。私たちは...するべきかどうかという難しい議論にぶつかりました... A。実稼働ビルドを行うリリースブランチが1つあり、実際に何かがリリースされたときにラベルを付ける または B。本番環境への新しいリリースごとに新しいリリースブランチを作成します（例：バージョン1、2、3など...） オプションAは非常に簡単に思えますが、これが長期的に問題を引き起こすかどうかはわかりません。オプションBは、時間の経過とともに積み重なる1回限りの長寿命ブランチを作成するだけのようです。 私たちが決めるのを助けることができる経験はありますか？具体的には、いずれか1つの選択肢のどこに問題があるのか​​を聞きたいと思っています。TFSおよび/またはリリース管理の意味に関連する特定の経験を提供してください。
5
開発ブランチはいつ作成する必要がありますか？
プロジェクトのチームを単一のメイン/トランクブランチから、メインに定期的にマージする必要がある複数の開発/ワークブランチに移動しています。この記事とTFS分岐ガイド（TFSとVisual Studio 2010を使用しています）に基づいて新しいプロセスを作成しています。 現在、1人から5人の人々がプロジェクトに取り組んでいます。Mainは必要に応じていつでもリリースできるようにするため、常に安定している必要があります。スプリントは修正されていません-少なくともまだ-現時点では1〜2週間ごとにリリースしています。 この時点で、各ユーザーはアプリケーション全体のバグを修正しています。数週間以内に、アプリの新しい大きなコンポーネントの開発を開始します。 私たちが見つけている一つのこだわりのポイントは、いつ開発ブランチを作成すべきかということです。開発者のスキルセットに応じて、複数のユーザーストーリーを並行して実装します。開発者ごとにブランチを作成することを考えましたが、それは意味がありません。作業の一部で常にコラボレーションが必要になるからです。他の作業が完了している間にMainにマージするため、単一の開発ブランチでは対応できません。 誰にもこれに関するガイダンスがありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.