Construindo Projetos .NET com o TeamCity

Este guia mostra como construir projetos .NET com o TeamCity e é recomendado para desenvolvedores que estão usando o TeamCity pela primeira vez.

Pré-requisitos

Recomendamos que você tenha um conhecimento básico de .NET e do .NET CLI. For more information, see the Getting Started guide in the .NET documentation.

Primeiro passo: crie um projeto TeamCity

  1. Clique na engrenagem Administration no canto superior direito da página do TeamCity.
  2. Clique em + Create Project e selecione a aba From a repository URL. In the Repository URL field, enter your repository, for example: https://github.com/matkoch/teamcity-dotnet.git. O TeamCity suporta todos os mais populares sistemas de controle de versão: Git, Subversion, Mercurial, Perforce e TFS (TeamCity Cloud + On-Premises). O suporte a CVS, StarTeam e Visual SourceSafe está disponível apenas no TeamCity On-Premises.
  3. Se seu repositório necessita de autenticação, insira seu nome de usuário e senha/token de acesso.
  4. Clique em Proceed.

Se o TeamCity conectar com sucesso ao seu repositório, você verá a seguinte caixa de diálogo.

Na caixa de diálogo Create Project From URL, você poderá alterar o nome do projeto e o nome da configuração de build inicial.

Nota: Nas versões mais recentes do TeamCity, você também verá os campos Default branch e Branch specification, que permitem especificar quais branches o TeamCity deve construir. Ignore-os por enquanto.

  • O TeamCity irá sugerir um nome de projeto default, mas você pode escolher um nome mais adequado para seu projeto, se desejar.
  • Todo projeto TeamCity consiste em pelo menos uma configuração de build, que contém todas as etapas necessárias para construir seu projeto. As configurações de build do TeamCity são frequentemente chamadas de jobs em outros sistemas de CI. Por enquanto você pode usar o nome “Build”, que é o nome default da configuração do build.

Depois de clicar em Proceed, o TeamCity verifica automaticamente seu repositório de controle de versão em busca de tecnologias suportadas, neste caso .NET.

Se o TeamCity detectar um arquivo de solução (*.sln) no seu repositório, ele irá automaticamente sugerir etapas de build para seu projeto, que envolvem compilar sua solução .NET com dotnet build e executar todos os seus testes com dotnet test.

As etapas de build não devem ser confundidas com uma configuração de build. Uma configuração de build pode conter, potencialmente, várias etapas de build.

Marque as caixas de seleção das etapas de build do .NET e clique em Use selected.

Você acaba de configurar com sucesso seu repositório .NET com o TeamCity:

Segundo passo: execute seu primeiro build

Agora você pode executar seus primeiros builds clicando no botão Run no canto superior direito, conforme mostrado aqui:

Observação: Se você estiver usando o TeamCity Cloud, pode levar alguns minutos antes que um agente de build esteja disponível. Durante esse período, seu build aguardará na fila até que seja selecionado por um agente disponível.

Se você estiver usando o TeamCity On-Premises com agentes de build locais, seu build começará imediatamente.

Assim que seu build começar, você será redirecionado para a página de visão geral do build com a aba Build Log aberta. Ela mostrará os dados em tempo real relacionados ao seu build.

Depois que a execução do build terminar, você pode dar uma olhada nos seus resultados de teste ou navegar no build log completo.

Terceiro passo: configurando seu projeto .NET no TeamCity

Agora que seu repositório .NET está conectado ao TeamCity, você pode continuar a desenvolver e fazer push do seu código para o repositório.

Por default, TeamCity irá pesquisar o branch main do seu repositório VCS a cada 60 segundos para mudanças de entrada e acionar um build (combinado) para todos os commits detectados.

Construindo branches

Se você deseja disparar uma build para cada alteração em qualquer branch do seu repositório, não apenas no branch main, adicione uma especificação de branch curinga às configurações do root do seu VCS. Observe que as configurações de VCS pertencem ao projeto TeamCity como um todo, não a uma única configuração de build. Portanto, quaisquer alterações que você fizer serão aplicadas a todas as configurações de build que usam a mesma root no VCS.

  1. Na página de visão geral do projeto, clique em Edit Project. Como alternativa, se você estiver com a configuração de build Build aberta, clique em Edit Configuration.
  2. Navegue até VCS Roots (sistemas de controle de versão) e edite a root do seu VCS.
  3. Preencha o campo de entrada Branch Specification e clique em Save. Se você não conseguir ver o campo de entrada Branch Specification, clique primeiro em Show Advanced.

Exemplos de especificações de build:

  • +:refs/heads/*: o TeamCity irá verificar se há mudanças em todos os branches de seus projetos, mas não verificará solicitações pull em plataformas como GitHub, pois essas correspondem a refs/pull/*.
  • +:*: o TeamCity irá verificar se houve quaisquer alterações recebidas em qualquer branch.
  • Sua própria especificação de branch personalizada.

O TeamCity agora vai monitorar todos os branches que estão em conformidade com a especificação do seu branch e que foram enviadas para o seu repositório, monitorando alterações recebidas, e executará os builds de acordo.

Compilando solicitações Pull

Se você deseja que o TeamCity construa automaticamente as solicitações pull que são feitas no seu repositório, você pode adicionar o Pull Request build feature à sua configuração de build.

  1. Abra sua configuração de build e clique em Edit Configuration.
  2. Navegue até Build Features e clique em Add Build Feature. Se você não puder ver o link Build Features, clique em Show More.
  3. Selecione Pull Requests no menu dropdown e escolha seu repositório, assim como o provedor de repositório (GitHub, GitLab ou similar).
  4. Opcionalmente, aplique o Pull Request Filtering, por autor ou nome do branch.

Observação: O recurso de build Pull Request expande de forma transparente a especificação do branch (veja o passo anterior para mais informações). Por exemplo, no caso do GitHub, o recurso de solicitação pull irá adicionar +:refs/pull/*, de forma invisível, à sua especificação de branch.

Recomendamos garantir que os branches de solicitações pull não sejam incluídos na sua especificação geral de branch quando o recurso de solicitação pull for usado, caso contrário, os recursos relacionados à solicitações pull não estarão disponíveis no TeamCity.

Agora o TeamCity irá monitorar a plataforma externa para detectar solicitações de pull e disparar um build para aquelas que corresponderem às suas regras de configuração.

Observação: Você deve usar este recurso com cuidado em repositórios públicos, pois qualquer pessoa pode enviar código malicioso para o repositório (código que você não vai querer construir).

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. Este recurso atualizará o status da solicitação pull, na plataforma correspondente, com os resultados do build.

Para configurar o TeamCity para relatar os resultados do build de volta ao GitHub, você deve seguir as seguintes etapas:

  1. Abra sua configuração de build e clique em Edit Configuration.
  2. Navegue até Build Features e clique em Add Build Feature.
  3. Selecione Commit Status Publisher no menu dropdown e escolha seu repositório e um editor (GitHub, GitLab ou similar).
  4. Forneça um token de acesso com direitos suficientes para publicar status de commit.
  5. Clique em Save.

Depois que o TeamCity executar uma build, você poderá facilmente descobrir se as alterações causaram alguma falha no build através da aba Pull Request no GitHub (marca de seleção verde).