Kompilieren von .NET-Projekten mit TeamCity

1. Klicken Sie in der oberen rechten Ecke der TeamCity-Seite auf Administration.
   
2. Klicken Sie auf + Create Project und wählen Sie den Tab From a repository URL aus. In the Repository URL field, enter your repository, for example: https://github.com/matkoch/teamcity-dotnet.git. TeamCity kommt von Haus aus mit allen gängigen Versionierungssystemen zurecht: Git, Subversion, Mercurial, Perforce und TFS (TeamCity Cloud + lokale Installation). Die Unterstützung für CVS, StarTeam und Visual SourceSafe ist nur in lokalen TeamCity-Installationen verfügbar.
3. Wenn Ihr Repository eine Authentifizierung erfordert, geben Sie Ihren Benutzernamen und Ihr Passwort oder Ihren Zugriffstoken ein.
4. Klicken Sie auf Proceed.

Wenn TeamCity erfolgreich eine Verbindung zu Ihrem Repository hergestellt hat, sehen Sie den folgenden Dialog:

Im Dialog Create Project From URL haben Sie die Möglichkeit, den Projektnamen und den Namen der anfänglichen Build-Konfiguration zu ändern.

Hinweis: In neueren Versionen von TeamCity sehen Sie auch die Felder Default branch und Branch specification, mit denen Sie angeben können, für welche Branches TeamCity Builds erstellen soll. Diese können Sie vorerst ignorieren.

• TeamCity schlägt einen Standard-Projektnamen vor, Sie können Ihrem Projekt jedoch bei Bedarf einen geeigneteren Namen geben.
• Jedes TeamCity-Projekt besteht aus mindestens einer Build-Konfiguration, die alle Schritte enthält, die zum Kompilieren Ihres Projekts erforderlich sind. Die Build-Konfigurationen von TeamCity werden in anderen CI-Systemen oft als Jobs bezeichnet. Sie können vorerst den standardmäßigen Build-Konfigurationsnamen „Build“ behalten.

Nachdem Sie Proceed angeklickt haben, durchsucht TeamCity automatisch Ihr Repository nach unterstützten Technologien, in diesem Fall .NET.

Wenn TeamCity eine Projektmappendatei (*.sln) in Ihrem Repository erkennt, schlägt es automatisch Build-Schritte für Ihr Projekt vor, um Ihre .NET-Projektmappe mit dotnet build zu kompilieren und alle dazugehörigen Tests mit dotnet test auszuführen.

Build-Schritte sollten nicht mit Build-Konfigurationen verwechselt werden. Eine Build-Konfiguration kann viele Build-Schritte enthalten.

Aktivieren Sie die Kontrollkästchen für die .NET-Build-Schritte und klicken Sie auf Use selected.

Damit haben Sie Ihr .NET-Repository erfolgreich in TeamCity konfiguriert:

Sie können jetzt Ihre ersten Builds ausführen, indem Sie wie in der Abbildung gezeigt oben rechts die Schaltfläche Run anklicken.

Hinweis: Wenn Sie TeamCity Cloud verwenden, kann es einige Minuten dauern, bis ein Build-Agent verfügbar ist. Während dieser Zeit wartet Ihr Build in der Warteschlange, bis er von einem verfügbaren Agent angenommen wird.

Wenn Sie TeamCity On-Premises mit lokalen Build-Agents verwenden, wird Ihr Build sofort gestartet.

Sobald Ihr Build gestartet wurde, werden Sie zur Übersichtsseite des Builds weitergeleitet. Dort werden auf dem Build Log-Tab Echtzeitdaten zu Ihrem Build angezeigt.

Nachdem der Build abgeschlossen wurde, können Sie einen Blick auf Ihre Testergebnisse werfen oder sich das komplette Build-Protokoll ansehen.

Nachdem Ihr .NET-Repository nun mit TeamCity verbunden ist, können Sie die Entwicklung fortsetzen und Ihren Code in das Repository übertragen.

Standardmäßig überprüft TeamCity den main-Branch Ihres VCS-Repositorys alle 60 Sekunden auf eingehende Änderungen und löst einen (kombinierten) Build für alle erkannten Commits aus.

Builds für Branches erstellen

Wenn Sie für Änderungen in jedem Branch Ihres Repositorys – nicht nur im main-Branch – einen Build auslösen möchten, fügen Sie in Ihren VCS-Root-Einstellungen eine Branch-Spezifikation mit einem Platzhalter hinzu. Beachten Sie, dass die VCS-Einstellungen für das TeamCity-Projekt und nicht für eine einzelne Build-Konfiguration gelten. Daher werden alle Änderungen, die Sie vornehmen, auf alle Build-Konfigurationen angewendet, die denselben VCS-Root verwenden.

1. Klicken Sie auf der Übersichtsseite des Projekts auf Edit Project. Alternativ, wenn die Build-Konfiguration Build geöffnet ist, klicken Sie auf Edit Configuration.
2. Navigieren Sie zu VCS Roots (Versionierungssysteme) und bearbeiten Sie Ihren VCS-Root.
3. Füllen Sie das Eingabefeld Branch Specification aus und klicken Sie auf Save. Wenn Sie das Eingabefeld Branch Specification nicht sehen können, klicken Sie zuerst auf Show Advanced.

Beispielhafte Branch-Spezifikationen:

• +:refs/heads/* – TeamCity überprüft alle Branches Ihrer Projekte auf Änderungen, überprüft jedoch keine Pull-Requests auf Plattformen wie GitHub, da diese mit refs/pull/* übereinstimmen.
• +:* – TeamCity sucht nach beliebigen eingehenden Änderungen in beliebigen Branches.
• Ihre eigene Branch-Spezifikation.

TeamCity überwacht jetzt alle Branches, die Ihrer Branch-Spezifikation entsprechen und in Ihr Repository gepusht werden. Bei eingehenden Änderungen wird ein entsprechender Build ausgeführt.

Builds nach Pull-Requests

Wenn Sie möchten, dass TeamCity für Pull-Requests, die an Ihr Repository gesendet werden, automatisch Builds erstellt, können Sie das Build-Feature Pull Requests zu Ihrer Build-Konfiguration hinzufügen.

1. Öffnen Sie Ihre Build-Konfiguration und klicken Sie auf Edit Configuration.
2. Navigieren Sie zu Build Features und klicken Sie auf Add Build Feature. Wenn Sie den Link Build Features nicht sehen können, klicken Sie auf Show More.
3. Wählen Sie Pull Requests aus der Dropdown-Liste und wählen Sie Ihr Repository sowie den Repository-Anbieter (GitHub, GitLab usw.) aus.
4. Aktivieren Sie optional die Pull-Request-Filterung nach Autor oder Branch-Name.

Hinweis: Das Build-Feature Pull Requests erweitert transparent die Branch-Spezifikation (siehe dazu den vorherigen Schritt). Im Fall von GitHub beispielsweise fügt das Pull-Request-Feature den (unsichtbaren) Eintrag +:refs/pull/* zu Ihrer Branch-Spezifikation hinzu.

Bei Verwendung des Pull-Request-Features sollten die Pull-Request-Branches nicht in Ihrer allgemeinen Branch-Spezifikation enthalten sein, da ansonsten die Pull-Request-bezogenen Funktionen von TeamCity nicht verfügbar sind.

TeamCity überwacht nun die externe Plattform auf Pull-Requests und löst einen Build für diejenigen aus, die Ihren Konfigurationsregeln entsprechen.

Hinweis: In öffentlichen Repositories sollten Sie diese Funktion mit Vorsicht verwenden, da jeder schädlichen Code in das Repository pushen könnte (und diesen sollten Sie nicht kompilieren).

Commit Status Publisher

When using the pull requests feature in combination with Azure DevOps, Bitbucket Server, GitHub, or GitLab, it also makes sense to use the Commit Status Publisher build feature. Dieses Feature aktualisiert den Status des Pull-Requests auf der jeweiligen Plattform mit den Build-Ergebnissen.

Um TeamCity so einzurichten, dass Build-Ergebnisse an GitHub gemeldet werden, müssen Sie die folgenden Schritte ausführen:

1. Öffnen Sie Ihre Build-Konfiguration und klicken Sie auf Edit Configuration.
2. Navigieren Sie zu Build Features und klicken Sie auf Add Build Feature.
3. Wählen Sie Commit Status Publisher aus der Dropdown-Liste und wählen Sie Ihr Repository sowie einen Publisher (GitHub, GitLab usw.) aus.
4. Geben Sie einen Zugriffstoken mit ausreichenden Rechten zum Veröffentlichen von Commit-Status-Informationen an.
5. Klicken Sie auf Save.

Nachdem TeamCity einen Build ausgeführt hat, können Sie jetzt direkt auf dem GitHub-Tab Pull Request sehen, ob die Änderungen einen Build-Fehler verursacht haben (grünes Häkchen).