Ce guide vous explique comment créer des projets .NET avec TeamCity. Il est recommandé aux développeurs qui ne connaissent pas du tout TeamCity.
Conditions préalables
Nous vous recommandons de maîtriser les notions de base de .NET et de .NET CLI. For more information, see the Getting Started guide in the .NET documentation.
Si TeamCity se connecte avec succès à votre dépôt, le message ci-dessous s'affiche.
Dans la boîte de dialogue Create Project From URL, vous avez la possibilité de modifier le nom du projet et le nom de la configuration de build initiale.
Remarque : Dans les versions plus récentes de TeamCity, vous verrez également les champs Default branch et Branch specification, qui vous permettent de spécifier les branches que TeamCity doit créer. Ignorez-les pour l'instant.
Après avoir cliqué sur Proceed, TeamCity analyse automatiquement votre dépôt de contrôle de version à la recherche de technologies prises en charge, dans ce cas .NET.
Si TeamCity détecte un fichier solution (*.sln) dans votre dépôt, il suggérera automatiquement des étapes de build pour votre projet qui impliquent la compilation de votre solution .NET avec dotnet build
et l'exécution de tous ses tests avec dotnet test
.
Les étapes de build ne doivent pas être confondues avec une configuration de build. Une configuration de build peut potentiellement contenir de nombreuses étapes de build.
Cochez les cases des étapes de build .NET et cliquez sur Use selected.
Vous avez maintenant configuré avec succès votre dépôt .NET avec TeamCity :
Vous pouvez désormais exécuter vos premiers builds en appuyant sur le bouton Run en haut à droite comme indiqué ici :
Remarque : Si vous utilisez TeamCity Cloud, la disponibilité d'un agent de build peut prendre jusqu'à quelques minutes. Pendant ce temps, votre build attendra dans la file d'attente jusqu'à ce qu'elle soit prise en charge par un agent disponible.
Si vous utilisez des installations locales de TeamCityTeamCity avec des agents de build locaux, votre build commencera immédiatement.
Une fois votre build démarré, vous serez redirigé vers la page d'aperçu du build avec l'onglet Build Log ouvert, qui affiche les données de votre build en temps réel.
Une fois que le build a fini de s'exécuter, vous pouvez consulter les résultats de test ou parcourir le journal de build complet.
Maintenant que votre dépôt .NET est connecté à TeamCity, vous pouvez continuer à développer et à transmettre votre code à votre dépôt.
Par défaut, TeamCity interroge la branche principale de votre dépôt VCS toutes les 60 secondes pour les changements entrants et déclenche un build (combiné) pour tous les commits détectés.
Si vous voulez déclencher un build pour chaque changement apporté à n'importe quelle branche de votre dépôt, et pas seulement à la branche principale, ajoutez une spécification de branche avec un caractère générique à vos paramètres racine VCS. Notez que les paramètres VCS appartiennent au projet TeamCity, et non à une seule configuration de build. Par conséquent, toute modification apportée est appliquée à toutes les configurations de build qui utilisent la même racine VCS.
Exemple de spécifications de branche :
+:refs/heads/*
: TeamCity vérifiera les changements dans toutes les branches de vos projets, mais ne vérifiera pas les requêtes Pull sur des plateformes comme GitHub dans la mesure où elles correspondent à refs/pull/*
. +:*
: TeamCity vérifiera toutes les modifications entrantes sur toutes les branche. TeamCity surveille désormais toutes les branches qui sont conformes à votre spécification de branche et qui sont transmises à votre dépôt, en vérifiant les changements entrants, et il exécute les builds en conséquence.
Si vous souhaitez que TeamCity fasse un build automatique des requêtes Pull faites sur votre dépôt, vous pouvez ajouter la fonctionnalité de build Pull Request à votre configuration de build.
Remarque : la fonctionnalité de build Pull Request étend de manière transparente la spécification de branche (voir l'étape précédente pour plus d'informations). Par exemple, dans le cas de GitHub, la fonctionnalité de requête Pull ajoute (de manière invisible) +:refs/pull/*
à votre spécification de branche.
Nous recommandons de vous assurer que les branches de requêtes Pull ne sont pas incluses dans votre spécification de branche générale lorsque la fonctionnalité de requête Pull est utilisée. Sinon, les fonctionnalités liées aux requêtes Pull ne seront pas disponibles dans TeamCity.
TeamCity détecte désormais les requêtes Pull sur la plateforme externe et déclenche un build pour celles qui correspondent à vos règles de configuration.
Remarque : Vous devriez utiliser cette fonctionnalité avec prudence sur les dépôts publics, car n'importe qui pourrait publier du code nuisible dans le dépôt (que vous ne voudriez surtout pas inclure dans votre build).
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. Cette fonctionnalité met à jour le statut de la requête Pull sur la plateforme correspondante avec les résultats du build.
Pour configurer TeamCity afin de transmettre les résultats du build à GitHub, veuillez suivre les étapes suivantes :
Après que TeamCity a exécuté un build, vous pourrez désormais facilement voir si les changements ont causé un échec de build directement depuis l'onglet Pull Request sur GitHub (coche verte).