Ich habe einTFS 2013 Server mit mehreren TFS-Teamprojektsammlungen und Entwicklern, die gerne gegen sie arbeiten. Die Projektsammlungen haben eine Reihe vonTFS-Builds zugehörige, einschliesslich relevanter CI-Builds, die bei jedem Check-In oder in einigen Fällen Rolling-Check-Ins (akkumuliert) auslösen. Dieser Prozess funktioniert einwandfrei und funktioniert seit mehreren Jahren.

Vor kurzem haben wir eineGit-Repository in die mischung welcheebenfalls Befindet sich auf unserem TFS 2013-Server und wird als Knoten angezeigt, zu dem ich über meine Entwicklungsumgebung eine Verbindung herstellen kann, wenn ich eine Verbindung zu meinem TFS 2013-Server herstelle. (d. h. es ist kein lokales Repo ...)

Dies wird von verschiedenen Entwicklern verwendet, die VS2013 und (hauptsächlich) die Git-Integration verwenden, die Teil von Team Explorer unter VS2013 ist.

Das alles funktioniert fabelhaftAUSSER..... Team 1 checkt einTFS-Quellcodeverwaltung und Auslösen von CI-Builds, die ich für das Git-Repository eingerichtet habe. Jedes einzelne Commit von Team 1 löst den Build aus, obwohl der Code, der NICHT Teil des Git-Repos ist, geändert wurde und wird! Ich musste vorerst auf "manuelle" Builds zurückgreifen, was nicht ideal ist, da ich wirklich einen CI-Build brauche, um Tests auszuführen.

In Bezug auf die Prozessvorlage verwenden wir eine geringfügige Änderung der Standard-Git-Build-Vorlage, die meiner Meinung nach von der Arbeit der ALM-Ranger abgeleitet wurde. Die Änderung ist ein zusätzlicher Schritt, um eine InRelease-Bereitstellung auszulösen. Ich bin mir nicht sicher, ob dies relevant ist oder nicht, aber im Interesse der Detaillierung des Themas ...

Hat jemand eine Idee, wie ich das beheben kann? Im Wesentlichen möchte ich die TFS- und Git-Quellcodeverwaltung vollständig isolieren, wenn es um die ausgelösten Builds geht.