Auslösen einer Freigabe aus einem Build

Wenn Sie Ihre App mit Team Foundation Build erstellen, können Sie Versionen automatisch starten. Sie können auswählen, in welcher Stufe Ihr Versionsprozess starten soll. Um Versionen über einen Build auszulösen, müssen Sie sowohl Ihren Buildprozess als auch Ihren Releasepfad konfigurieren.

Wenn Sie noch keinen Releasepfad erstellt haben, können Sie dies hier nachholen.

Wenn Sie Ihr Buildsystem noch nicht eingerichtet haben, können Sie dies jetzt tun.

Konfigurieren des Buildprozesses

1. Wenn Sie keine Berechtigungen zum Bearbeiten von Builddefinitionen haben, richten Sie diese jetzt ein.

2. Verbinden Sie sich in Visual Studio, Team Explorer, mit dem Teamprojekt, in dem Sie arbeiten möchten (Tastatur: STRG+ 0, C).

3. Erstellen oder bearbeiten Sie auf der Seite Builds eine Builddefinition (Tastatur: STRG+ 0, B).

4. Wählen Sie auf der Registerkarte Prozess der Builddefinition, die Konfiguration, die Sie für diese Version verwenden möchten (z. B.: Debug- oder Release). Legen Sie Release-Build auf True fest. Wählen Sie die Phase, die Sie für die Veröffentlichung auslösen möchten oder lassen Sie dieses Feld leer, wenn Sie mit der ersten Phase beginnen möchten.

   

   Wenn der Abschnitt Version nicht angezeigt wird:

   • F: Ich verwende die Standardvorlage. Welche Buildprozessvorlage sollte ich für Release Management verwenden, und wie füge ich sie TFS hinzu?

   • F: Ich verwende die Upgradevorlage. Welche Buildprozessvorlage sollte ich für Release Management verwenden?

   • F: Ich verwende eine benutzerdefinierte Buildprozessvorlage. Wie füge ich die Workflowlogik hinzu, mit der eine Version ausgelöst wird?

   Wenn Komponenten mit Konfigurationsdateien vorhanden sind, die verschiedene Werte je nach Zielumgebung benötigen, können Sie eine Version der Konfigurationsdatei mit Token erstellen.

5. Nehmen Sie ggf. weitere Einstellungen vor, die der Buildprozess erfordert, und speichern Sie anschließend die Builddefinition.

Konfigurieren der Versionsvorlage

1. Wenn Sie Release Management Client für Visual Studio 2013 noch nicht auf dem Buildserver installiert haben, sollten Sie dies jetzt nachholen. Konfigurieren Sie Release Management Client so, dass er eine Verbindung mit Release Management Server herstellen kann.

   Nachdem Sie den Client auf dem Buildserver installiert haben, müssen Sie die Builddienste neu starten. Dies können Sie über die Team Foundation Server-Verwaltungskonsole vornehmen.

2. Wählen Sie in Ihrer Versionsvorlage die Builddefinition aus, die Sie zum Auslösen eines Builds festgelegt haben, und aktivieren Sie das Kontrollkästchen, damit durch den Buildprozess eine Version ausgelöst wird.

   

   Wenn die Auswahl "Builddefinition" nicht angezeigt wird, müssen Sie die TFS-Verbindung zu Release Management Client hinzufügen. (Fügen Sie die Verbindung über die Registerkarte TFS verwalten des Abschnitts Verwaltung hinzu.)

   Nachdem eine Version ausgelöst wurde, werden die Schritte der Stufe durchlaufen, die ausgewählt wurde. Wenn Sie Akzeptanzschritt und Bereitstellungsschritt für diese Stufe nicht auf Automatisiert festlegen, wird die Version nicht gestartet. Sie müssen diese Schritte im Releasepfad als automatisiert markieren.

Fragen und Antworten

F: Ich verwende die Standardvorlage.Welche Buildprozessvorlage sollte ich für Release Management verwenden, und wie füge ich sie TFS hinzu?

A: Wenn Sie die Standardvorlage verwenden, müssen Sie sie durch die entsprechende Releaseverwaltungs-Prozessvorlage ersetzen.

1. Wenn Sie keine Berechtigungen haben, Dateien beizutragen oder Builddefinitionen zu bearbeiten, richten Sie diese jetzt ein.

2. Verbinden Sie sich in Visual Studio, Team Explorer, mit dem Teamprojekt, in dem Sie arbeiten möchten (Tastatur: STRG+ 0, C).

3. Suchen Sie im Ordner Laufwerk:\Programme (x86)\Microsoft Visual Studio 12.0\ReleaseManagement\bin die Vorlage, die Sie benötigen. Oder laden Sie die ZIP-Datei mit der Vorlage, die an diesen Blogbeitrag angehängt ist, in dieses Verzeichnis herunter.

   • TFS 2013

     • TFVC: ReleaseTfvcTemplate.12.xaml.

     • Git: ReleaseGitTemplate.12.xaml

   • TFS 2012: ReleaseDefaultTemplate.11.1.xaml

   • TFS 2010: ReleaseDefaultTemplate.xaml

4. Fügen Sie die Vorlage zur Versionskontrolle hinzu. Es empfiehlt sich, die Vorlage in den BuildProcessTemplates-Ordner des Teamprojekts abzulegen.

   • TFVC: Hinzufügen von Dateien zum Server

   • Git: Verwalten von Dateien auf dem Entwicklungscomputer

5. Erstellen oder bearbeiten Sie auf der Seite Builds eine Builddefinition (Tastatur: STRG+ 0, B).

6. Wählen Sie auf der Registerkarte Prozess die Option Neu, um die Vorlage auszuwählen, die für die Buildprozessdatei verwendet werden soll. (Sie können zu der Vorlage navigieren, die Sie gerade hinzugefügt haben).

F: Ich verwende eine benutzerdefinierte Buildprozessvorlage.Wie füge ich die Workflowlogik hinzu, mit der eine Version ausgelöst wird?

A: Fügen Sie Ihrer benutzerdefinierten Buildprozessvorlage Abschnitte hinzu, um die Workflowlogik bereitzustellen. Laden Sie die Ausschnittdatei mit diesen Abschnitten hier herunter. Verwenden Sie die Ausschnitte, um diese Argumente der Buildprozessvorlage hinzuzufügen: ConfigurationsToRelease, ReleaseBuild, ReleaseTargetStage, DropBuild.

Speichern Sie die Buildprozessvorlage. Checken Sie sie außerdem ein, wenn Sie die Team Foundation-Versionskontrolle nutzen. Wenn Sie Git verwenden, führen Sie einen Commit- und Pushvorgang für die Buildprozessvorlage aus.

F: Ich verwende die Upgradevorlage.Welche Buildprozessvorlage sollte ich für Release Management verwenden?

A:Hier erfahren Sie, wie Sie vorgehen sollten.

F: Kann ich Komponenten meiner Anwendung auf verschiedenen Computern bereitstellen?

A: Ja. Erstellen Sie Komponenten mit Release Management Client, und fügen Sie sie dann der Versionsvorlage hinzu.

Sie können diese Komponenten Ihrem Build hinzufügen.

Wenn das Komponentenfenster angezeigt wird, doppelklicken Sie auf die Komponente, die Sie hinzufügen möchten.

Jede Komponente, die Sie hinzufügen, muss mit der Option Build wird mit Anwendung erstellt oder Build wird extern erstellt konfiguriert werden.

Ein '\' in Buildablageort gibt an, dass sich der Build auf der Stammebene des Ablageordners befindet.

F: Welche Tools kann ich verwenden, um eine Komponente bereitzustellen?

A: Für jede Komponente, die Sie definieren, können Sie das zu verwendende Tool über die Registerkarte "Bereitstellung" auswählen. Weitere Informationen zu den Tools finden Sie hier.

Ersetzen Sie Argumente durch spezifische Informationen zum Bereitstellen dieser Komponente.

Um ein benutzerdefiniertes Tool zu verwenden, fügen Sie das Tool zunächst über die Seite "Bestand" hinzu, und wählen Sie es dann auf der Registerkarte "Bereitstellung" aus.

Stellen Sie sicher, dass jede Datei, auf die sich der Befehl bezieht, zum Zeitpunkt der Bereitstellung am Speicherort des Pakets verfügbar ist.

F: Warum wurde keine Version gestartet?

Mögliche Ursachen:

• Sie haben den Build so konfiguriert, dass eine Version ausgelöst wird (Versionsbuild=True), haben aber nicht das Kontrollkästchen Kann eine Freigabe aus einem Build auslösen? für die Versionsvorlage aktiviert. Dadurch schlägt der Build fehl, und infolgedessen wird auch die Version nicht gestartet.

• Sie haben die Versionsvorlage mit einer Builddefinition konfiguriert, die keine Auslösung einer Version vorsieht (Versionsbuild=False) oder nicht die richtige Versionslogik enthält.

• Die Versionsvorlage enthält eine Komponente, für die die unabhängige Erstellung konfiguriert ist.

• Sie haben Akzeptanzschritt und Bereitstellungsschritt für die Stufe, die von der Version ausgelöst wird, nicht auf Automatisiert festgelegt, sodass die Version nicht gestartet wird. Sie müssen für diesen Releasepfad eine Automatisierung der Schritte festlegen.

• Sie haben Release Management Client nicht auf dem Computer installiert, auf dem Team Foundation Build-Server ausgeführt wird.

• Das Abschließen der Bereitstellung dauert länger als 10 Minuten. Sie können den Wert, der Durch TFS ausgelöster Bereitstellungstimeout zugewiesen ist, über die Registerkarte "Verwaltung", Seite "Einstellungen" ändern.

F: Wie kann ich vorgehen, wenn Konfigurationsdateien je nach Zielumgebung unterschiedliche Werte benötigen?

A: Verwenden Sie Token für die Konfigurationsdateien:

Erstellen Sie für jede Konfigurationsdatei in Ihrer Projektmappe, die unterschiedliche Werte je nach Umgebung benötigt, eine Version mit Token.

Wenn die Projektmappe beispielsweise die Datei "web.config" enthält, erstellen Sie eine Kopie dieser Datei, und benennen Sie sie "web.config.token". Die Datei "web.config" wird nicht geändert und wird verwendet, wenn Sie die App lokal ausführen. Die Datei "web.config.token" enthält Token anstelle der eigentlichen Werte.

Beispiel: Wenn die Datei "web.config" diese Zeile enthält:

<add key="SMTPHostServer" value="mysmtp.myserver.domain"/>

dann enthält die Datei "web.config.token" diese Zeile, wobei "SMTPHostServer" das Token ist:

<add key="SMTPHostServer" value="SMTPHostServer"/>

Halten Sie die lokalen Dateien und die Tokendateien synchronisiert.

F: Wie definiere ich, welche Dateien durchsucht werden sollen, um Token durch Variablen zu ersetzen?

A: Sie können den Dateierweiterungsfilter auf der Registerkarte "Konfigurationsvariablen" für jede definierte Komponente entsprechend einstellen.

Der Deployment Agent, den Sie für die Komponente angegeben haben, verwendet einen Musterabgleich, um die Dateien zu durchsuchen, in denen Token durch Variablen ersetzt werden sollen. Trennen Sie zwei oder mehrere Dateinamenerweiterungen mithilfe eines Semikolons (;).