Ich habe also eine Situation, in der wir ein Projekt mit 10 Entwicklern haben. Jedem Entwickler wird nach dem Zufallsprinzip eine Maschine zur Verfügung gestellt, die er an diesem Tag für die Entwicklung verwenden kann. Die Maschinennamen sind unterschiedlich, sagen wir DEV01 - DEV10. Zu dem Zeitpunkt, an dem sie an die Entwickler ausgegeben werden, sind die Maschinen identisch, und es bleiben keine Änderungen, die die Entwickler während des Tages vornehmen, auf den Maschinen (Quellcodeänderungen werden in TFS gespeichert, nicht lokal). Dies sind natürlich tatsächlich virtuelle Maschinen, aber das ist für den vorliegenden Punkt nicht wirklich relevant.
Das Problem ist, dass die Entwickler jeden Morgen drei Probleme haben:
1) Der Computer, dem sie zugewiesen sind, ist möglicherweise nicht derselbe Computer, dem sie zuletzt zugewiesen wurden. Zum Beispiel könnte DevMan A gestern DEV04 verwendet haben und DEV06 heute erhalten haben. Seine Arbeitsbereichsdefinitionen sind jetzt an DEV06 gebunden; Er muss einen neuen Arbeitsbereich erstellen oder den alten Arbeitsbereich nach DEV04 migrieren.
2) Die Maschine, der sie zugeordnet sind, wurde möglicherweise bereits verwendet, und einige der Zuordnungen können Konflikte verursachen. Zum Beispiel könnte DevMan A heute DEV04 haben und möchte einen Arbeitsbereich erstellen, der den Projektordner auf "C: \ MyProj \ Solution" abbildet. DevMan B hatte gestern jedoch DEV04, und er benutzte den gleichen Projektordner. TFS beschwert sich jetzt.
3) Dies könnte das erste Mal sein, dass sie sich auf einer bestimmten Maschine befinden. Sie müssen nun für diese Maschine alle ihre Quellsteuerungszuordnungen für die neue Maschine neu erstellen.
All diese Probleme lassen sich von Fall zu Fall auf einfache Art und Weise lösen, aber sie mindern ab dem Morgen etwas Produktivität. Wir würden es vorziehen, wenn die TFS-Arbeitsbereich-Definitionen "entspannt" werden könnten, so dass sie den Computernamen irgendwie nicht in die Definition aufgenommen haben. Wenn jemand eine Lösung für die oben genannten Probleme kennt, die automatisch ausgeführt werden können, oder wenn der Benutzer nur begrenzt eingreifen kann, wäre dies ebenfalls ideal.
Erstens ist die super-offensichtliche Antwort, Maschinen den Benutzern zu widmen.
Zweitens ... wenn Sie das Problem wirklich wie gesagt lösen wollen:
Sie können keine Arbeitsbereiche verwenden, ohne sie einem bestimmten Computer zuzuweisen. Diese Annahme ist implizit im Produkt enthalten. Aber du kannst es täuschen :)
Warnung: Dieses Rezept scheint zu funktionieren, aber ich habe kein Projekt selbst ausgeführt.
Wenn der Benutzer nun Visual Studio öffnet, verwendet der Arbeitsbereich den angegebenen Wert "UseridVM" als Computername, daher wird auf jeder Maschine derselbe Arbeitsbereich gefunden.
Wenn Sie keine persistente virtuelle Festplatte haben, dann muss jeder Benutzer sicher sein, ein "echtes" "Get Latest" (Get Specific Version, alle Kontrollkästchen aktivieren) beim Start für den Tag zu machen, da der Arbeitsbereich was speichert Dateien wurden bereits heruntergeladen und werden nicht erneut heruntergeladen, wenn sie sich bereits als vorhanden erwiesen haben.
1.) Für jede Workstation, an der Sie arbeiten werden, müssen Sie einen Arbeitsbereich definieren (remote & lt; = & gt; local mapping). Sie können Quelldateien im Netzwerk speichern (dies wird aufgrund des VS-Caching nicht empfohlen), aber der lokale Arbeitsbereich (Zuordnungsdefinition) muss für einen bestimmten Benutzer auf einem bestimmten PC vorhanden sein.
2.) Erstellen Sie separate lokale Ordner pro Entwickler, um zu verhindern, dass verschiedene Personen an demselben Ordner arbeiten und dass Sie den letzten ausgecheckten Code anderer erhalten. Zum Beispiel:
%Vor%3.) Dies wird wahrscheinlich zu vielen Diskussionen führen, aber ich empfehle die Zuordnung von root von Ihrem TFS zu Ihrem lokalen Arbeitsbereich, z. DevManA Mapping:
%Vor%Wenn Sie dann Projekte überprüfen, erhalten Sie eine Struktur:
%Vor%usw.
Dies ist ein einfaches und schnelles Mapping, das jeder in 5 Sekunden durchführen kann und Sie sind bereit zu gehen. Dann hat jeder das gleiche Layout auf der Festplatte wie in TFS, das auch leichter zum Gehirn passt.
Sie können den Arbeitsbereich auf einem freigegebenen Netzlaufwerk platzieren, so dass es egal ist, auf welchem Computer (virtuell oder nicht) der Entwickler angemeldet ist. Das funktioniert gut, aber Sie müssen auch einige COM-Einträge einmal konfigurieren, um es glücklich zu machen.
Tags und Links tfs visual-studio-2008 virtualization version-control workspace