Integração Contínua - Guia Rápido

A integração contínua foi introduzida pela primeira vez no ano de 2000 com o software conhecido como Cruise Control. Ao longo dos anos, a Integração Contínua se tornou uma prática chave em qualquer organização de software. Esta é uma prática de desenvolvimento que exige que as equipes de desenvolvimento garantam que uma construção e um teste subsequente sejam conduzidos para cada alteração de código feita em um programa de software. Esse conceito foi criado para remover o problema de localização de ocorrências tardias de problemas no ciclo de vida de construção. Em vez de os desenvolvedores trabalharem isoladamente e não se integrarem o suficiente, a Integração Contínua foi introduzida para garantir que as alterações e compilações do código nunca fossem feitas de forma isolada.

Por que integração contínua?

A integração contínua tornou-se parte integrante de qualquer processo de desenvolvimento de software. O processo de integração contínua ajuda a responder às seguintes perguntas para a equipe de desenvolvimento de software.

Todos os componentes de software funcionam juntos como deveriam? - Às vezes, os sistemas podem se tornar tão complexos que existem várias interfaces para cada componente. Nesses casos, é sempre essencial garantir que todos os componentes de software funcionem perfeitamente uns com os outros.
O código é muito complexo para fins de integração? - Se o processo de integração contínua continuar falhando, pode haver a possibilidade de o código ser muito complexo. E isso pode ser um sinal para aplicar padrões de design adequados para tornar o código menos complexo e mais fácil de manter.
O código está de acordo com os padrões de codificação estabelecidos? - A maioria dos casos de teste sempre verificará se o código está aderindo aos padrões de codificação adequados. Ao fazer um teste automatizado após a construção automatizada, este é um bom ponto para verificar se o código atende a todos os padrões de codificação desejados.
Quanto código é coberto por testes automatizados? - Não faz sentido testar o código se os casos de teste não cobrirem a funcionalidade necessária do código. Portanto, é sempre uma boa prática garantir que os casos de teste escritos abranjam todos os principais cenários do aplicativo.
Todos os testes foram bem-sucedidos após a última alteração? - Se um teste falhar, não há sentido em prosseguir com a implantação do código, portanto, este é um bom ponto para verificar se o código está pronto para passar para o estágio de implantação ou não.

Fluxo de Trabalho

A imagem a seguir mostra um rápido fluxo de trabalho de como todo o fluxo de trabalho de Integração Contínua funciona em qualquer projeto de desenvolvimento de software. Veremos isso em detalhes nos capítulos subsequentes.

Portanto, com base no fluxo de trabalho acima, geralmente é assim que funciona o processo de integração contínua.

Primeiro, um desenvolvedor confirma o código para o repositório de controle de versão. Enquanto isso, o servidor de Integração Contínua na máquina de compilação de integração consulta o repositório de código-fonte em busca de alterações (por exemplo, a cada poucos minutos).
Logo após ocorrer um commit, o servidor de Integração Contínua detecta que mudanças ocorreram no repositório de controle de versão, então o servidor de Integração Contínua recupera a última cópia do código do repositório e então executa um script de construção, que integra o software
O servidor de integração contínua gera feedback enviando os resultados da construção por e-mail para os membros do projeto especificados.
Os testes de unidade são realizados se a construção desse projeto for aprovada. Se os testes forem bem-sucedidos, o código está pronto para ser implantado no servidor de teste ou de produção.
O servidor de Integração Contínua continua a pesquisar mudanças no repositório de controle de versão e todo o processo se repete.

A parte do software é o aspecto mais importante de qualquer processo de integração contínua. Este capítulo enfoca o software que será necessário para todo o processo de Integração Contínua.

Repositório de código fonte

O repositório de código-fonte é usado para manter todo o código-fonte e todas as alterações feitas nele. Os dois mais populares para gerenciamento de repositório de código-fonte são o subversion e o Git, sendo o Git o sistema popular mais recente. Veremos agora como instalar o Git no sistema.

Requisitos de sistema

Memória	2 GB de RAM (recomendado)
Espaço em disco	Disco rígido de 200 MB para a instalação. É necessário armazenamento adicional para armazenar o código-fonte do projeto e isso depende do código-fonte adicionado.
Versão do sistema operacional	Pode ser instalado em Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS, Mac OS X.

Instalando Git

Step 1 - O site oficial do Git é https://git-scm.com/. Se você clicar no link, você chegará à página inicial do site oficial do Git conforme mostrado na imagem a seguir.

Step 2 - Para baixar o Git, basta rolar a tela para baixo e ir até a seção Downloads e clicar em Downloads.

Step 3 - Clique no link do Windows e o download do Git começará automaticamente.

Step 4- Clique no arquivo .exe baixado para Git. Em nosso caso, estamos usando o arquivo Git-2.6.1-64-bit.exe. Clique em Executar que aparece na próxima tela.

Step 5 - Clique no botão Avançar que aparece na tela seguinte.

Step 6 - Clique em Avançar na tela a seguir para aceitar o contrato de licença geral.

Step 7 - Escolha o local para a instalação do Git.

Step 8 - Clique em Avançar para aceitar os componentes padrão que precisam ser instalados.

Step 9 - Escolha a opção 'Usar Git a partir do prompt de comando do Windows', pois usaremos o Git do Windows.

Step 10 - Na tela a seguir, aceite a configuração padrão de 'Check-out no estilo Windows, envie terminações de linha no estilo Unix' e clique em Avançar.

Step 11 - Na tela seguinte, escolha a opção 'Usar janela de console padrão do Windows', pois estamos usando o Windows como sistema de instalação do Git.

A instalação começará agora, e as etapas subsequentes podem ser seguidas para configurar o Git, uma vez que a instalação for concluída.

Configurando Git

Depois de instalar o Git, as etapas de configuração precisam ser realizadas para a configuração inicial do Git.

A primeira coisa que precisa ser feita é configurar a identidade no Git e então configurar um nome de usuário e e-mail. Isso é importante porque cadaGit commitusa essa informação, e é imutavelmente embutida nos commits que você começa a criar. Pode-se fazer isso abrindo o prompt de comando e, em seguida, digite os seguintes comandos -

git config –global user.name “Username”
git config –global user.email “emailid”

A captura de tela a seguir é um exemplo para melhor compreensão.

Esses comandos irão, na verdade, alterar o arquivo de configuração do Git de acordo. Para garantir que suas configurações tenham efeito, você pode listar as configurações do arquivo de configuração Git usando o comando a seguir.

git config --list

Um exemplo da saída é mostrado na captura de tela a seguir.

Servidor de Integração Contínua

O próximo software crucial necessário para todo o pipeline de integração contínua é o próprio software de integração contínua. A seguir estão os softwares de Integração Contínua mais comumente usados na indústria -

Jenkins- Este é um software de integração contínua de código aberto que é usado por muitas comunidades de desenvolvimento.
Jet Brains TeamCity - Este é um dos softwares comerciais de Integração Contínua mais populares disponíveis e a maioria das empresas o usa para suas necessidades de Integração Contínua.
Atlassian Bamboo- Este é outro software de integração contínua popular fornecido por uma empresa chamada Atlassian Pvt. Ltd.

Todos os softwares citados acima funcionam no mesmo modelo de Integração Contínua. Para o propósito deste tutorial, veremosJetbrains TeamCity para o servidor de integração contínua.

Instalando TeamCity

A seguir estão as etapas e os requisitos do sistema para instalar o Jet Brains TeamCity em seu computador.

Requisitos de sistema

Memória	4 GB de RAM (recomendado)
Espaço em disco	HDD de 1 GB para a instalação. Armazenamento adicional é necessário para armazenar o espaço de trabalho de construção para cada projeto.
Versão do sistema operacional	Pode ser instalado em Windows, Linux, Mac OS X.

Instalação

Step 1 - O site oficial do TeamCity éhttps://www.jetbrains.com/teamcity/. Se você clicar no link fornecido, você irá para a página inicial do site oficial do TeamCity conforme mostrado na imagem a seguir. Você pode navegar na página para baixar o software necessário para TeamCity.

Step 2 - O .exe baixado está sendo usado para fins de execução TeamCity-9.1.6.exe. Clique duas vezes no executável e clique em Executar na próxima tela que aparecer.

Step 3 - Clique em Avançar para iniciar a configuração.

Step 4 - Clique no botão 'Concordo' para aceitar o contrato de licença e prosseguir com a instalação.

Step 5 - Escolha o local para a instalação e clique em Avançar.

Step 6 - Escolha os componentes padrão para a instalação e clique em Avançar

Isso iniciará o processo de instalação. Depois de concluído, o processo de configuração seguirá.

Step 7- Escolha um número de porta para o servidor executar. O melhor é usar uma porta diferente, como8080.

Step 8- Em seguida, ele perguntará com qual conta o TeamCity precisa ser executado. Escolha a conta SYSTEM e clique em Next.

Step 9- Em seguida, ele solicitará os serviços que precisam ser iniciados. Aceite os padrões e clique em Avançar.

Configurando TeamCity

Assim que a instalação for concluída, a próxima etapa é a configuração do TeamCity. Este software pode ser aberto navegando na seguinte URL no navegador -

http://locahost:8080

Step 1- O primeiro passo é fornecer a localização das construções, que serão realizadas pelo TeamCity. Escolha o local desejado e clique no botão Continuar.

Step 2- A próxima etapa é especificar o banco de dados para armazenar todos os artefatos TeamCity. Para efeitos do tutorial, pode-se escolher oInternal (HSQLDB), que é um banco de dados interno mais adequado ao usar produtos para fins de teste.

O TeamCity irá então processar todas as etapas necessárias para colocá-lo em funcionamento.

Step 3- Em seguida, você será solicitado a aceitar o contrato de licença. Aceite o mesmo e clique em Continuar.

Step 4- Você precisa criar uma conta de administrador que será usada para fazer login no software TeamCity. Insira os detalhes necessários e clique no botão 'Criar conta'.

Agora você estará conectado ao TeamCity.

A ferramenta de construção

A ferramenta Build é uma ferramenta que garante que o programa seja construído de uma maneira particular. A ferramenta normalmente executará uma lista de tarefas, que são necessárias para que o programa seja construído de maneira adequada. Já que em nosso exemplo, vamos olhar para um.Net program , estaremos olhando para MSBuildcomo a ferramenta de construção. A ferramenta MSBuild examina um arquivo de construção que contém uma lista de tarefas usadas para construir o projeto. Vejamos um arquivo Build típico para um projeto de configuração da web.

A seguir estão as principais seções do arquivo Build, que precisam ser consideradas.

Configurações do IIS

As configurações a seguir são usadas para determinar qual é o número da porta, qual é o caminho no servidor da web e que tipo de autenticação é necessária quando o aplicativo é executado. Essas são configurações importantes, que serão alteradas por meio do comando MSBuild quando aprendermos como a implantação será realizada posteriormente no tutorial.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPor>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>

ItemGroup

Isso é usado para informar ao servidor de construção quais são todos os binários dependentes necessários para executar este projeto.

<ItemGroup>
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />

<ItemGroup>
   <Compile Include = "App_Start\BundleConfig.cs" />
   <Compile Include = "App_Start\FilterConfig.cs" />

Versão do .Net Framework

o TargetFrameworkVersioninforma qual é a versão do .Net que precisa estar presente para o projeto funcionar. Isso é absolutamente necessário porque, se o servidor de compilação não o tiver instalado, a compilação falhará.

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

Ambiente de implantação - Amazon

Para o propósito deste tutorial, vamos garantir que nosso servidor de integração contínua tenha a capacidade de implantar nosso aplicativo na Amazon. Para isso, precisamos garantir que os seguintes artefatos estejam no lugar.

Servidor de banco de dados

Execute as etapas a seguir para garantir que o servidor de banco de dados esteja instalado na Amazon para a implantação.

Step 1 - Vá para o Amazon Console - https://aws.amazon.com/console/.

Faça login com suas credenciais. Observe que você pode se inscrever para uma identificação gratuita no site amazon, o que permitirá que você tenha um nível gratuito que permite usar alguns dos recursos da Amazon gratuitamente.

Step 2 - Vá para a seção RDS para criar seu banco de dados.

Step 3 - Clique em Instâncias na próxima tela que aparece.

Step 4 - Clique no Launch DB opção na próxima tela que aparece.

Step 5 - Escolha a guia SQL Server e, em seguida, escolha a opção Selecionar para SQL Server Express.

Step 6 - Certifique-se de que os seguintes detalhes sejam inseridos para confirmar que você está usando o nível gratuito de bancos de dados disponíveis na Amazon.

Step 7 - Clique no botão Próxima etapa quando todos os campos forem preenchidos.

Step 8 - Na próxima tela que aparecer, aceite todas as configurações padrão e clique em Launch DB Instance.

Step 9- Será apresentada uma tela que informa que o DB está sendo iniciado com sucesso. Na mesma página, haverá um botão para visualizar a Instância de banco de dados. Clique no link para ver o seuDB Instance sendo configurado.

Após algum tempo, o status da tela acima mudará para notificar que a Instância de banco de dados foi criada com sucesso.

Servidor web

A próxima etapa é criar seu servidor web na Amazon, que hospedará o aplicativo web. Isso pode ser feito seguindo as etapas subsequentes para que isso aconteça.

Step 1 - Vá para Amazon Console - https://aws.amazon.com/console/.

Faça login com suas credenciais. Observe que você pode se inscrever para umfree id on the Amazon site, que permitirá que você tenha um nível gratuito que permite usar alguns dos recursos da Amazon gratuitamente.

Step 2 - Vá para o EC2 section para criar seu servidor web.

Step 3 - Na próxima tela, clique em Iniciar instância.

Step 4 - Clique no Windows - Microsoft Windows Server 2010 R2 Base.

Step 5 - Escolha o t2.microopção, que faz parte do nível gratuito. CliqueNext: Configure Instance Details.

Step 6 - Aceite as configurações padrão na próxima tela que aparecer e escolha a opção Next: Add Storage.

Step 7 - Aceite as configurações padrão na próxima tela e escolha a opção Next: Tag Instance.

Step 8 - Aceite as configurações padrão na próxima tela e escolha a opção de Next: Configure Security Group.

Step 9 - Aceite as configurações padrão na próxima tela e escolha a opção de Review and Launch.

Step 10 - Clique em Iniciar na próxima tela que aparecer.

Step 11- Na próxima tela que aparece, você será solicitado a criar um par de chaves. Isso será usado para fazer login no servidor posteriormente. Basta criar o par de chaves e clicarLaunch Instance.

A instância agora será configurada na Amazon.

Há chances de que algo dê errado em um projeto. Ao praticar CI de forma eficaz, você descobre o que acontece em cada etapa ao longo do caminho, e não mais tarde, quando o projeto está no ciclo de desenvolvimento. A CI ajuda a identificar e mitigar riscos quando eles ocorrem, tornando mais fácil avaliar e relatar sobre a integridade do projeto com base em evidências concretas.

Esta seção se concentrará nos riscos que podem ser evitados usando a Integração Contínua.

Em qualquer projeto, existem muitos riscos que precisam ser gerenciados. Ao eliminar os riscos no início do ciclo de vida de desenvolvimento, há menos chances de esses riscos se transformarem em problemas mais tarde, quando o sistema realmente entrar em operação.

Risco 1 - Falta de software implantável

“It works on my machine but does not work on another”- Esta é provavelmente uma das frases mais comuns encontradas em qualquer organização de software. Por causa do número de alterações feitas nas compilações de software diariamente, às vezes há pouca confiança se a compilação do software realmente funciona ou não. Essa preocupação tem os seguintes três efeitos colaterais.

Pouca ou nenhuma confiança se poderíamos construir o software.
Longas fases de integração antes de entregar o software internamente (ou seja, equipe de teste) ou externamente (ou seja, cliente), durante as quais nada mais é feito.
Incapacidade de produzir e reproduzir compilações testáveis.

Solução

Eliminando o acoplamento estreito entre o IDE e os processos de construção. Use uma máquina separada exclusivamente para integrar o software. Certifique-se de que tudo que você precisa para construir o software está contido no repositório de controle de versão. Finalmente, crie um sistema de Integração Contínua.

O servidor de Integração Contínua pode observar as alterações no repositório de controle de versão e executar o script de construção do projeto quando detectar uma alteração no repositório. A capacidade do sistema de Integração Contínua pode ser aumentada para incluir a execução do build por meio de testes, realização de inspeções e implantação do software nos ambientes de desenvolvimento e teste; assim você sempre tem um software funcionando.

“Inability to synchronize with the database”- Às vezes, os desenvolvedores não conseguem recriar o banco de dados rapidamente durante o desenvolvimento e, portanto, têm dificuldade para fazer alterações. Freqüentemente, isso ocorre devido à separação entre a equipe de banco de dados e a equipe de desenvolvimento. Cada equipe estará focada em suas próprias responsabilidades e terá pouca colaboração entre si. Essa preocupação tem os seguintes três efeitos colaterais -

Medo de fazer alterações ou refatorar o banco de dados ou o código-fonte.
Dificuldade em preencher o banco de dados com diferentes conjuntos de dados de teste.
Dificuldade em manter ambientes de desenvolvimento e teste (por exemplo, Desenvolvimento, Integração, QA e Teste).

Solução

A solução para o problema acima é garantir que o posicionamento de todos os artefatos do banco de dados no repositório de controle de versão seja executado. Isso significa tudo o que é necessário para recriar o esquema e os dados do banco de dados: scripts de criação de banco de dados, scripts de manipulação de dados, procedimentos armazenados, acionadores e quaisquer outros ativos de banco de dados são necessários.

Reconstrua o banco de dados e os dados de seu script de construção, eliminando e recriando seu banco de dados e tabelas. Em seguida, aplique os procedimentos armazenados e gatilhos e, finalmente, insira os dados de teste.

Teste (e inspecione) seu banco de dados. Normalmente, você usará os testes de componentes para testar o banco de dados e os dados. Em alguns casos, você precisará escrever testes específicos do banco de dados.

Risco 2 - Descoberta de defeitos mais tarde no ciclo de vida

Uma vez que há tantas mudanças que acontecem frequentemente por vários desenvolvedores no código-fonte, sempre há chances de que um defeito possa ser introduzido no código que só poderia ser detectado em um estágio posterior. Nesses casos, isso pode causar um grande impacto, pois quanto mais tarde o defeito for detectado no software, mais caro se torna a remoção do defeito.

Solução

Regression Testing- Este é o aspecto mais importante de qualquer ciclo de desenvolvimento de software, teste e teste novamente. Se houver alguma alteração importante no código do software, é absolutamente obrigatório garantir que todos os testes sejam executados. E isso pode ser automatizado com a ajuda do servidor de Integração Contínua.

Test Coverage- Não faz sentido testar se os casos de teste não cobrem toda a funcionalidade do código. É importante garantir que os casos de teste criados para testar o aplicativo sejam completos e que todos os caminhos de código sejam testados.

Por exemplo, se você tem uma tela de login que precisa ser testada, você simplesmente não pode ter um caso de teste com o cenário de um login bem-sucedido. Você precisa ter um caso de teste negativo em que um usuário insere uma combinação diferente de nomes de usuário e senhas e, em seguida, é necessário ver o que acontece em tais cenários.

Risco 3 - Falta de Visibilidade do Projeto

Os mecanismos de comunicação do manual exigem muita coordenação para garantir a disseminação das informações do projeto às pessoas certas em tempo hábil. Inclinar-se para o desenvolvedor próximo a você e informá-lo de que a compilação mais recente está no drive compartilhado é bastante eficaz, mas não é muito escalável.

E se houver outros desenvolvedores que precisam dessas informações e eles estão em uma pausa ou indisponíveis? Se um servidor cair, como você é notificado? Alguns acreditam que podem atenuar esse risco enviando manualmente um e-mail. No entanto, isso não pode garantir que as informações sejam comunicadas às pessoas certas no momento certo, porque você pode acidentalmente deixar as partes interessadas de fora e algumas podem não ter acesso ao seu e-mail no momento.

Solução

A solução para esse problema é novamente o servidor de integração contínua. Todos os servidores de CI têm a facilidade de ter e-mails automatizados para serem acionados sempre que as compilações falharem. Por meio desta notificação automática a todos os principais interessados, também é garantido que todos estão a bordo sobre o estado atual do software.

Risco 4 - Software de baixa qualidade

Existem defeitos e, em seguida, defeitos potenciais. Você pode ter defeitos potenciais quando seu software não é bem projetado ou se não está seguindo os padrões do projeto, ou é complexo de manter. Às vezes, as pessoas se referem a isso como código ou cheiro de design - "um sintoma de que algo pode estar errado".

Alguns acreditam que software de qualidade inferior é apenas um custo de projeto adiado (após a entrega). Pode ser um custo de projeto adiado, mas também leva a muitos outros problemas antes de você entregar o software aos usuários. Código excessivamente complexo, código que não segue a arquitetura e código duplicado - todos geralmente levam a defeitos no software. Encontrar esses odores de código e design antes que se manifestem em defeitos pode economizar tempo e dinheiro e pode levar a software de alta qualidade.

Solução

Existem componentes de software para realizar uma verificação da qualidade do código que podem ser integrados ao software CI. Isso pode ser executado depois que o código é construído para garantir que o código realmente está em conformidade com as diretrizes de codificação adequadas.

Os sistemas de controle de versão, também conhecidos como controle de origem, sistemas de gerenciamento de código-fonte ou sistemas de controle de revisão, são um mecanismo para manter várias versões de seus arquivos, de modo que, ao modificar um arquivo, você ainda possa acessar as revisões anteriores.

O primeiro sistema de controle de versão popular foi uma ferramenta UNIX proprietária chamada SCCS(Sistema de controle de código-fonte) que remonta à década de 1970. Isso foi substituído porRCS, o Sistema de Controle de Revisão e posterior CVS, Sistema de versões simultâneas.

Agora, o sistema de controle de versão mais popular usado é Subversion e Git. Vamos primeiro ver por que precisamos usar um sistema de controle de versão e, a seguir, vamos ver como colocar nosso código-fonte emGit source code repository system.

Objetivo do Sistema de Controle de Versão

Um motivo pelo qual usamos o termo controle de versão em vez de controle de origem é que o controle de versão não é apenas para código-fonte. Cada artefato relacionado à criação de seu software deve estar sob controle de versão.

Developers should use it for source code - Por padrão, todo o código-fonte precisa ser armazenado no sistema de controle de versão

Related artefacts- Cada sistema teria artefatos relacionados ao código-fonte, como scripts de banco de dados, scripts de construção e implantação, documentação, bibliotecas e arquivos de configuração para seu aplicativo, seu compilador e coleção de ferramentas, e assim por diante. Tudo isso complementa todo o processo de desenvolvimento e implantação e também precisa ser armazenado no sistema de controle de versão.

Ao armazenar todas as informações do aplicativo no controle de origem, fica mais fácil recriar os ambientes de teste e produção em que seu aplicativo é executado. Isso deve incluir informações de configuração para a pilha de software do aplicativo e os sistemas operacionais que compõem o ambiente, arquivos de zona DNS, configuração de firewall e assim por diante.

No mínimo, você precisa de tudo o que é necessário para recriar os binários do seu aplicativo e os ambientes nos quais eles são executados. O objetivo é ter tudo o que pode mudar em algum momento da vida do projeto armazenado de forma controlada. Isso permite que você recupere um instantâneo exato do estado de todo o sistema, do ambiente de desenvolvimento ao ambiente de produção, em qualquer ponto do histórico do projeto.

É ainda útil manter os arquivos de configuração para os ambientes de desenvolvimento da equipe de desenvolvimento no controle de versão, pois torna mais fácil para todos na equipe usarem as mesmas configurações. Os analistas devem armazenar documentos de requisitos. Os testadores devem manter seus scripts e procedimentos de teste no controle de versão. Os gerentes de projeto devem salvar seus planos de liberação, gráficos de progresso e registros de risco aqui.

Resumindo, cada membro da equipe deve armazenar qualquer documento ou arquivo relacionado ao projeto no controle de versão.

Trabalhando com Git para sistema de controle de versão de código-fonte

Esta seção agora se concentrará em como o Git pode ser usado como um sistema de controle de versão. Ele se concentrará em como você pode carregar seu código para o sistema de controle de versão e gerenciar as alterações nele.

Nosso aplicativo de demonstração

Para o propósito de todo este tutorial, vamos dar uma olhada em um simples Web ASP.Netaplicativo que será usado para todo o processo de integração contínua. Não precisamos nos concentrar em todos os detalhes do código para este exercício, apenas ter uma visão geral do que o projeto faz é suficiente para compreender todo o processo de integração contínua. Este aplicativo .Net foi construído usando oVisual Studio Integrated Development Environment.

A captura de tela a seguir é a estrutura da solução no ambiente Visual Studio. É um aplicativo da Web muito simples, que possui o código principal noDemo.aspx Arquivo.

O código no arquivo Demo.aspx é mostrado no programa a seguir -

<html xmlns = "http://www.w3.org/1999/xhtml">
   <head runat = "server">
      <title>TutorialsPoint</title>
   </head>
   
   <body>
      <form id = "form1" runat="server">
         <div><%Response.Write("Continuous Integration"); %></div>
      </form>
   </body>
   
</html>

O código é muito simples e apenas envia a string “Integração Contínua” para o navegador.

Quando você executa o projeto no Google Chrome, a saída será conforme mostrado na captura de tela a seguir.

Movendo o código-fonte para o Git

Vamos mostrar como mover o código-fonte para o Git a partir da interface da linha de comando, de forma que o conhecimento de como o Git pode ser usado seja mais claro para o usuário final.

Step 1 - Inicialize o Git Repository. Vá para o prompt de comando, vá para a pasta do projeto e emita o comandogit init. Este comando adicionará os arquivos Git necessários à pasta do projeto, para que possa ser reconhecido pelo Git quando precisar ser carregado no repositório.

Step 2- Adicionar seus arquivos que precisam ser adicionados ao repositório Git. Isso pode ser feito emitindo ogit add command. A opção ponto informa ao Git que todos os arquivos na pasta do projeto precisam ser adicionados ao repositório Git.

Step 3- A etapa final é enviar os arquivos do projeto para o repositório Git. Esta etapa é necessária para garantir que todos os arquivos agora façam parte do Git. O comando a ser emitido é fornecido na imagem a seguir. o–m option é fornecer um comentário para o upload de arquivos.

Sua solução agora está disponível no Git.

A seguir estão alguns dos principais recursos ou práticas para integração contínua.

Maintain a single source repository- Todo o código-fonte é mantido em um único repositório. Isso evita que o código-fonte seja espalhado por vários locais. Ferramentas comoSubversion and Git são as ferramentas mais populares para manter o código-fonte.
Automate the build- A construção do software deve ser realizada de forma que possa ser automatizada. Se houver várias etapas que precisam ser realizadas, a ferramenta de construção deve ser capaz de fazer isso. Para .Net, MSBuild é a ferramenta de compilação padrão e para aplicativos baseados em Java você tem ferramentas comoMaven and Grunt.
Make your build self-testing- A construção deve ser testável. Imediatamente após a criação, os casos de teste devem ser executados para garantir que o teste possa ser realizado para as várias funcionalidades do software.
Every commit should build on an integration machine- A máquina de integração é o servidor de construção e deve-se garantir que a construção seja executada nesta máquina. Isso significa que todos os componentes dependentes devem existir no servidor de Integração Contínua.
Keep the build fast- A compilação deve acontecer em minutos. A construção não deve levar horas para acontecer, porque isso significaria que as etapas de construção não estão configuradas corretamente.
Test in a clone of the production environment- O ambiente de construção deve ser próximo ao ambiente de produção. Se houver grandes diferenças entre esses ambientes, pode haver um caso em que a construção falhe na produção, mesmo que passe no servidor de construção.
Everyone can see what is happening - Todo o processo de construção, teste e implantação deve ser visível para todos.
Automate deployment- A integração contínua leva à implantação contínua. É absolutamente necessário garantir que a construção seja fácil de implementar em um ambiente de teste ou de produção.

A seguir está a lista dos requisitos mais importantes para integração contínua.

Check-In Regularly- A prática mais importante para que a integração contínua funcione corretamente são os check-ins frequentes no tronco ou linha principal do repositório de código-fonte. O check-in do código deve acontecer pelo menos algumas vezes por dia. O check-in regularmente traz muitos outros benefícios. Isso torna as alterações menores e, portanto, menos propensas a interromper a construção. Significa que a versão mais recente do software para a qual reverter é conhecida quando um erro é cometido em qualquer construção subsequente.

Também ajuda a ser mais disciplinado na refatoração de código e a se limitar a pequenas mudanças que preservam o comportamento. Isso ajuda a garantir que as alterações que alteram muitos arquivos tenham menos probabilidade de entrar em conflito com o trabalho de outras pessoas. Ele permite que os desenvolvedores sejam mais explorativos, experimentando ideias e descartando-as, revertendo para a última versão confirmada.
Create a Comprehensive Automated Test Suite- Se você não tiver um conjunto abrangente de testes automatizados, um build aprovado significa apenas que o aplicativo pode ser compilado e montado. Embora para algumas equipes isso seja um grande passo, é essencial ter algum nível de teste automatizado para fornecer a confiança de que seu aplicativo está realmente funcionando.

Normalmente, existem 3 tipos de testes realizados em Integração Contínua, nomeadamente unit tests, component tests, e acceptance tests.

Os testes de unidade são escritos para testar o comportamento de pequenas partes do seu aplicativo isoladamente. Geralmente, eles podem ser executados sem iniciar todo o aplicativo. Eles não atingem o banco de dados (se o seu aplicativo tiver um), o sistema de arquivos ou a rede. Eles não exigem que seu aplicativo seja executado em um ambiente de produção. Os testes de unidade devem ser executados muito rápido - todo o seu pacote, mesmo para um aplicativo grande, deve ser executado em menos de dez minutos.

Os testes de componentes testam o comportamento de vários componentes de seu aplicativo. Como os testes de unidade, eles nem sempre exigem a inicialização de todo o aplicativo. No entanto, eles podem atingir o banco de dados, o sistema de arquivos ou outros sistemas (que podem ser eliminados). Os testes de componentes geralmente demoram mais para serem executados.
Keep the Build and Test Process Short - Se demorar muito para construir o código e executar os testes de unidade, você encontrará os seguintes problemas.
- As pessoas vão parar de fazer uma compilação completa e vão executar os testes antes de fazer o check-in. Você começará a obter mais compilações com falha.
- O processo de integração contínua levará tanto tempo que vários commits teriam ocorrido no momento em que você pudesse executar a compilação novamente, então você não saberá qual check-in interrompeu a compilação.
- As pessoas farão o check-in com menos frequência porque têm que ficar sentadas por muito tempo esperando o software ser construído e os testes executados.
Don’t Check-In on a Broken Build- O maior erro da integração contínua é verificar uma compilação quebrada. Se o build falhar, os desenvolvedores responsáveis estão esperando para consertá-lo. Eles identificam a causa da quebra o mais rápido possível e corrigem. Se adotarmos essa estratégia, estaremos sempre na melhor posição para descobrir o que causou a quebra e consertar imediatamente.

Se um de nossos colegas fez um check-in e, como resultado, quebrou a compilação, então, para ter a melhor chance de consertá-lo, eles precisarão de uma correção completa do problema. Quando essa regra é quebrada, inevitavelmente leva muito mais tempo para que a construção seja corrigida. As pessoas se acostumam a ver o build quebrado, e muito rapidamente você entra em uma situação em que o build fica quebrado o tempo todo.
Always Run All Commit Tests Locally Before Committing- Sempre certifique-se de que os testes projetados para o aplicativo sejam executados primeiro em uma máquina local antes de executá-los no servidor CI. Isso é para garantir que os casos de teste corretos sejam escritos e se houver alguma falha no processo de CI, é devido aos resultados do teste com falha.
Take Responsibility for All Breakages that Result from Your Changes- Se você confirmar uma alteração e todos os testes que você escreveu passarem, mas outros falharem, a compilação ainda está danificada. Normalmente, isso significa que você introduziu um bug de regressão no aplicativo. É sua responsabilidade - porque você fez a alteração - corrigir todos os testes que não foram aprovados como resultado de suas alterações. No contexto da CI, isso parece óbvio, mas na verdade não é uma prática comum em muitos projetos.

Há uma variedade de ferramentas de construção disponíveis para uma variedade de linguagens de programação. Algumas das ferramentas de construção mais populares incluemAnt for Java e MSBuild for .NET. Usar uma ferramenta de script projetada especificamente para construir software, em vez de um conjunto customizado de shell ou scripts em lote, é a maneira mais eficaz de desenvolver uma solução de construção consistente e repetível.

Então, por que precisamos de um processo de construção para começar. Bem, para começar, para um servidor de integração contínua, o processo de construção deve ser fácil de trabalhar e deve ser fácil de implementar.

Vamos dar um exemplo simples de como pode ser um arquivo de construção para .Net -

<?xml version = "1.0" encoding = "utf-8"?>
<project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
   <Target Name = "Build">
      <Message Text = "Building Project" />
      <MSBuild Projects = "project.csproj" Targets = "Build/>"
   </Target>
</project>

Os seguintes aspectos precisam ser observados sobre o código acima -

Um destino é especificado com um nome de Build. Onde, um destino é uma coleção de etapas lógicas que precisam ser executadas em um processo de construção. Você pode ter vários destinos e dependências entre eles.
Em nosso alvo, mantemos uma mensagem de opção que será mostrada quando o processo de construção for iniciado.
o MSBuild task é usado para especificar qual projeto .Net precisa ser construído.

O exemplo acima é o caso de um arquivo de construção muito simples. Na Integração Contínua, é garantido que este arquivo seja mantido atualizado para garantir que todo o processo de construção seja perfeito.

Construindo uma Solução em .Net

A ferramenta de compilação padrão para .Net é MSBuild e é algo que vem com a estrutura .Net. Dependendo da estrutura do seu sistema, você terá a versão relevante do MSbuild disponível. Por exemplo, se você tiver o .Net framework instalado no local padrão, você encontrará oMSBuild.exe arquivo no seguinte local -

C:\Windows\Microsoft.NET\Framework\v4.0.30319

Vamos ver como podemos construir nosso projeto de amostra. Vamos supor que nosso projeto de amostra está localizado em uma pasta chamadaC:\Demo\Simple.

Para usar o MSBuild para construir a solução acima, precisamos abrir o prompt de comando e usar a opção MSBuild conforme mostrado no programa a seguir.

msbuild C:\Demo\Simple\Simple.csproj

No exemplo acima, csprojé o arquivo de projeto específico para .Net. O arquivo csproj contém todas as informações relevantes para garantir que as informações necessárias estejam presentes para que o software seja construído adequadamente. A seguir está a captura de tela da saída do comando MSBuild.

Você não precisa se preocupar com os avisos de saída, desde que o Build foi bem-sucedido e não houve erros.

Agora, vamos examinar certos aspectos do arquivo MSBuild para ver o que eles significam. Esses aspectos são importantes para saber a partir de um Ciclo de Integração Contínua.

Os scripts de construção são usados para construir a solução que fará parte de todo o ciclo contínuo de integração. Vejamos o script de construção geral que é criado como parte do Visual Studio em.Netpara nossa solução de amostra. O script de construção é muito grande, mesmo para uma solução simples, portanto, examinaremos as partes mais importantes dele. Por padrão, o script de construção será armazenado em um arquivo com o mesmo nome da solução principal no Visual Studio. Portanto, em nosso caso, se você abrir o arquivoSimple.csproj, você verá todas as configurações que serão usadas para construir a solução.

Dependência da versão do MSBuild usada - As configurações a seguir usarão os arquivos MSBuild instalados no servidor de CI.

<VisualStudioVersion Condition = "'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> <VSToolsPath Condition = "'$(VSToolsPath)' == ''"> 
   $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)
</VSToolsPath>

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

<Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" /> <Import Project = "$(VSToolsPath)\WebApplications\
   Microsoft.WebApplication.targets" Condition = "'$(VSToolsPath)' ! = ''" /> <Import Project = "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\
   WebApplications\Microsoft.WebApplication.targets" Condition = "false" />

Quais arquivos são necessários para construir a solução adequadamente - O ItemGroupA tag conterá todos os arquivos .Net necessários para que o projeto seja construído com sucesso. Esses arquivos precisarão residir no servidor de compilação de acordo.

<ItemGroup>
   <Reference Include = "Microsoft.CSharp" />
   <Reference Include = "System.Web.DynamicData" />
   <Reference Include = "System.Web.Entity" />
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />
   <Reference Include = "System" />
   <Reference Include = "System.Data" />
   <Reference Include = "System.Core" />
   <Reference Include = "System.Data.DataSetExtensions" />
   <Reference Include = "System.Web.Extensions" />
   <Reference Include = "System.Xml.Linq" />
   <Reference Include = "System.Drawing" />
   <Reference Include = "System.Web" />
   <Reference Include = "System.Xml" />
   <Reference Include = "System.Configuration" />
   <Reference Include = "System.Web.Services" />
   <Reference Include = "System.EnterpriseServices"/>
</ItemGroup>

Quais são as configurações do servidor Web a serem usadas - Quando visitarmos nosso tópico de Implantação contínua, você verá como o MSBuild será usado para substituir essas configurações e implantá-las em nosso servidor de escolha.

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>

A próxima etapa importante é garantir que a solução seja construída no servidor de construção. A primeira parte é uma etapa manual, porque antes que a ferramenta de integração contínua seja usada, primeiro devemos garantir que o build seja executado no servidor de build da mesma maneira que foi feito na máquina cliente. Para fazer isso, devemos implementar as seguintes etapas -

Step 1- Copie todo o arquivo da solução para o servidor. Criamos um servidor de instância da Amazon que seria usado como nosso servidor de construção. Então, faça uma cópia manual para o servidor de todo o.Net solução para o servidor.

Step 2- Certifique-se de que a estrutura esteja presente no servidor. Se você compilou seu aplicativo em .Net framework 4.0 em sua máquina cliente, deve garantir que ele também esteja instalado na máquina servidor. Então vá para o localC:\Windows\Microsoft.NET\Framework em seu servidor e verifique se a estrutura desejada está presente.

Step 3 - Agora vamos apenas executar o MSBuild no servidor e ver o que acontece.

Ok, parece que encontramos um erro. Há uma lição importante na Integração Contínua: você precisa garantir que o Build funcione no servidor de build. Para isso, você precisa garantir que todo o software obrigatório esteja instalado no servidor de construção.

Para .Net, precisamos instalar um componente chamado Visual Studio Redistributable package. Este pacote contém todos os arquivos necessários para um.Netaplicativo para construir em um servidor. Portanto, vamos realizar as seguintes etapas de instalação no servidor de compilação.

Step 4 - Clique duas vezes no arquivo executável para iniciar a instalação.

Step 5 - Na próxima etapa, concorde com os Termos da Licença e clique em Instalar.

Step 6 - Agora, ao executar o MSBuild, precisamos garantir que incluamos um parâmetro adicional ao chamar o MSBuild que é - p:VisualStudioversion = 12.0. Isso garante que o MSBuild faça referência aos arquivos baixados na etapa anterior.

Agora podemos ver que a solução foi construída corretamente e também sabemos que nosso projeto de linha de base foi construído corretamente no servidor.

O próximo aspecto importante é garantir que nosso código de base seja verificado em nosso servidor de gerenciamento de repositório de código-fonte, que é o Git. Para fazer isso, precisamos seguir estas etapas.

Step 1- Inicialize o repositório para que possa ser carregado no Git. Isso é feito com ogitcomando init. Então você precisa ir para a pasta do seu projeto e emitir ogit init comando.

Step 2- A próxima etapa é chamada de arquivos de teste no Git. Isso prepara todos os arquivos na pasta do projeto, que precisam ser adicionados ao Git. Você faz isso com ogit addcomando conforme mostrado na imagem a seguir. O '.' notação é usada para dizer que todos os arquivos no diretório e subdiretório devem ser incluídos no commit.

Step 3 - A etapa final é enviar os arquivos para o repositório Git, para que agora seja um repositório Git completo.

Agora que temos nosso código-fonte no repositório Git e todo o nosso código inicial funciona no servidor de construção, é hora de criar um projeto em nosso servidor de integração contínua. Isso pode ser feito através das seguintes etapas -

Step 1- Faça login no software TeamCity. Vá para o url em seu servidor de Integração Contínua -http://localhost:8080/login.html.

Insira as credenciais de administrador e faça login no servidor.

Step 2- Uma vez conectado, você verá a tela inicial. CliqueCreate Project para iniciar um novo projeto.

Step 3- Dê um nome para o projeto e clique em Criar para iniciar o projeto. No nosso caso, estamos dando o nome de 'Demo' ao nosso projeto, conforme mostrado na imagem a seguir.

Step 4- O próximo passo é mencionar o repositório Git que será usado em nosso projeto. Lembre-se de que, em um ambiente de integração contínua, o servidor de CI precisa coletar o código do repositório habilitado para Git. Já habilitamos nossa pasta de projeto para ser um repositório habilitado para Git na etapa anterior. No TeamCity, você precisa criar uma raiz VCS. Para isso, cliqueVCS Roots na tela principal do projeto.

Step 5 - Na tela que aparece a seguir, clique em Create VCS root como mostrado na imagem a seguir.

Step 6 - Na próxima tela que aparecer, execute as seguintes etapas -

Mencione o tipo de VCS como Git.
Dê um nome para a raiz do VCS, que pode ser qualquer nome amigável. Demos o nome deApp.
Forneça o url de busca como C:\Demo\Simple - Isto é out git repositório habilitado.
Se você rolar a tela para baixo, verá um botão Testar conexão. Clique nele para garantir que você pode se conectar com êxito ao repositório habilitado para Git.

Step 7 - Clique em Criar e agora você verá seu repositório registrado conforme mostrado na imagem a seguir.

Step 8- A próxima etapa é criar uma configuração de construção que será usada para construir o projeto. Vá para a tela do seu projeto emTeamCity → General Settings. Clique em Criar configuração de compilação.

Step 9- Na tela a seguir, dê um nome para a Configuração do Build. Em nosso caso, nós o nomeamos comoDemoBuild e clique em Criar.

Step 10 - Na próxima tela que aparecer, você deverá escolher o VCS repositoryque foi criado nas etapas anteriores. Então escolha o nome‘App’ e clique em Anexar.

Step 11- Agora na próxima tela que aparece, precisamos configurar as etapas de construção. Então clique no botão 'configure build steps manually'hiperlink.

Step 12 - Na próxima tela de construção, precisamos inserir os seguintes detalhes -

Escolha o tipo de Runner como MSBuild.
Dê um nome opcional para o nome da etapa.
Dê o nome do arquivo que precisa ser construído. Quando especificamos MSbuild nas seções anteriores, normalmente vemos que oferecemos a opção deSimple.csproj. A mesma coisa deve ser especificada aqui.
Escolha a versão do MSBuild como 'Microsoft Build Tools 2013'.
Escolha o MSBuild ToolsVersion como 12,0.
Role a página para baixo para Salvar as configurações.

Step 13 - Na próxima tela, clique em Executar.

Você verá a construção de seu aplicativo em andamento.

Você deve obter uma tela de sucesso, o que é um bom sinal de que sua solução está sendo construída corretamente.

Você também pode ir para o log de construção para ver todas as etapas que foram cobertas pelo servidor de integração contínua, conforme mostrado na captura de tela a seguir.

Agora que temos nosso código base no Git e um link para o servidor de Integração Contínua, é hora de ver a primeira etapa da Integração Contínua em ação. Isso é feito definindo tarefas no servidor de integração contínua, como gatilhos, o que torna todo o processo de integração contínua o mais perfeito possível. Vamos fazer uma alteração em nosso código no Visual Studio.

Step 1 - Vá para o Demo.aspx página no Visual Studio e faça uma alteração no título da página.

Step 2 - Se consultarmos nosso repositório Git por meio do git status comando, você verá de fato que o Demo.aspx arquivo foi modificado.

Agora, precisamos garantir que cada mudança em nosso código acione um build em nosso servidor de integração contínua. Para isso, precisamos fazer as seguintes alterações.

Step 3 - Vá para o painel do seu projeto, clique na seção de acionadores e clique em Add new trigger.

Step 4 - Na próxima tela que aparecer, escolha VCS trigger, que será usado para criar um gatilho para que, quando um check-in for feito no repositório, uma construção seja disparada.

Step 5 - Clique Show Advanced Options e verifique se as opções mostradas na captura de tela a seguir estão selecionadas.

Step 6- Clique em Salvar. Agora você verá o gatilho registrado com sucesso, conforme mostrado na imagem a seguir.

Step 7- Agora é hora de verificar nosso código no repositório Git e ver o que acontece. Então, vamos ao nosso prompt de comando e emitir ogit add comando para preparar nossos arquivos alterados.

Step 8 - Agora emita o git commit comando, e ele irá enviar as alterações para o repositório Git.

Step 9 - Se você for para a tela Visão geral dos projetos, verá que uma nova construção foi acionada e executada.

Se você ver o Change log Tab, você verá o git comment que acionou a construção.

Vamos tentar mais uma vez. Vamos fazer outra mudança noDemo.aspxArquivo. Vamos realizar umgit add comando e um git commit comando com a seguinte mensagem de confirmação.

Agora você verá uma construção sendo acionada automaticamente no painel do Projeto no TeamCity.

O build mostrará uma mensagem de sucesso.

Você verá agora a mensagem de 'Segundo commit' que foi usada quando a mudança foi enviada para o git repository.

Concluímos agora com sucesso a primeira parte do processo de Integração Contínua.

Uma Notificação de falha de construção é um evento que é disparado sempre que uma construção falha. A notificação é enviada a todas as pessoas-chave sempre que uma compilação falha. A primeira coisa importante a fazer nesse caso é garantir que o tempo seja gasto na construção com falha para garantir que a construção foi aprovada. As etapas a seguir são usadas para garantir que as notificações de construção sejam colocadas em vigor no TeamCity.

A seguir estão as etapas para configurar notificações de email no TeamCity.

Step 1- No TeamCity, vá para o painel do projeto, clique em Administração no canto superior direito. Você então verá oEmail Notifierlink no lado esquerdo. Clique neste link para abrir as configurações gerais de e-mail.

Step 2 - O próximo passo é inserir os detalhes de um SMTP Server. O Gmail oferece um recurso SMTP gratuito, que pode ser usado por qualquer pessoa. Portanto, podemos inserir esses detalhes na próxima tela que aparece, conforme mostrado na imagem a seguir.

Host SMTP - smtp.gmail.com
Porta SMTP nº - 465
Enviar mensagens de e-mail de e login SMTP - Deve ser um id válido do Gmail
Senha SMTP - senha válida para esse id do Gmail
Conexão segura - coloque como SSL

Step 3 - Clique Test Connectionapenas para garantir que as configurações estão funcionando corretamente. Então cliqueSave para salvar as configurações.

Step 4- A próxima etapa é habilitar notificações de construção para um usuário. A primeira tarefa é criar um usuário que receberá essas notificações de construção. Vá para o painel do seu projeto e escolha oUsers Option.

Step 5- Crie um novo usuário. Digite o nome de usuário e a senha necessários. Em seguida, clique no botão Criar usuário, que estará localizado na parte inferior da tela.

Step 6 - Agora faça o login no sistema TeamCity com este novo ID de usuário e senha.

Step 7- Depois de fazer o login, serão apresentadas as configurações gerais do usuário. Na seção Notificador de e-mail, clique em Editar.

Step 8 - Na próxima tela que aparecer, clique em Add new rule.

Step 9 - Em Adicionar nova regra, escolha as duas opções a seguir e clique em Salvar.

Compilações de projetos selecionados - Escolha o projeto Demo.
Ative a caixa de seleção para 'Falha na construção'.

Ao habilitar essas duas opções, agora sempre que uma compilação falhar para o projeto Demo, uma notificação por email será enviada ao usuário - demouser.

Step 10- Agora vamos acionar uma construção errada para ver isso em ação. No Visual Studio, vá para odemo.aspx.cs arquivo e adicione uma linha de código errada.

Step 11 - Agora verifique o código do Git fazendo um git add e git commit.

Agora, no Painel do projeto, a construção será acionada automaticamente e você verá que a construção teria falhado, conforme mostrado na captura de tela a seguir.

Se você fizer login no id do Gmail do demouser, você verá uma notificação de falha de compilação, conforme mostrado na captura de tela a seguir.

Um dos principais aspectos da integração contínua é sempre ver como os builds estão se saindo, reunindo métricas importantes, documentando esses resultados e gerando feedback contínuo por meio de builds contínuos.

Quais são os benefícios de ter essas métricas em vigor?

Not Committing Code Enough- Se os desenvolvedores não estão enviando código para um repositório de controle de versão com frequência, o motivo pode ser uma construção de integração lenta. Para começar a reduzir a duração do build, execute uma análise de alto nível do ambiente de build de integração para determinar os gargalos.

Em seguida, analise as descobertas e determine a melhoria mais apropriada, então tente fazer mudanças no processo de construção para reduzir a duração da construção. Por último, reavalie a duração da construção para determinar se melhorias adicionais são necessárias.
Improve Test Performance- Mesmo em um sistema de CI em bom funcionamento, grande parte do tempo de construção da integração será consumido pela execução de testes automatizados. Avaliar e melhorar o desempenho desses testes pode reduzir drasticamente a duração da compilação.
Infrastructure Issues- Você pode descobrir que as compilações de integração são lentas por causa da infraestrutura do sistema. Talvez o desempenho da rede esteja lento ou haja uma conexão de rede privada virtual de desempenho lento.

Sistemas geograficamente dispersos e hardware ou software não confiáveis também podem induzir a problemas de desempenho. Investigue e melhore quaisquer recursos de infraestrutura para reduzir a duração da construção.

Métricas

A seguir estão algumas das métricas que estão disponíveis em um servidor de integração contínua.

Vejamos o que TeamCity tem a oferecer -

Uma das formas mais simples de métricas é o que está disponível no painel do projeto. O principal elemento aqui é observar a duração de cada construção. Se a duração de cada construção começar a aumentar desproporcionalmente ao código que está sendo construído, isso pode ser um problema. Portanto, este é um feedback que pode ser obtido e as causas disso podem ser que o servidor de CI está com poucos recursos e talvez a capacidade do servidor precise ser aumentada.

O TeamCity tem a facilidade de ver se o servidor de CI está de fato tendo algum tipo de problema com relação à infraestrutura. Noadmin dashboard no TeamCity, pode-se clicar em Disk Usage para ver quanto espaço em disco está sendo consumido por cada construção.

Se mais detalhes forem necessários, TeamCity tem o diagnostics button, que pode fornecer mais informações sobre o CPU and Memory sendo utilizado pelo CI Server.

Visão detalhada das métricas de compilação

Se alguém quiser ter uma visão detalhada das compilações de um projeto específico ao longo do tempo, isso estará disponível como parte das compilações do projeto. Na tela de construção do projeto, vá para a tela Estatísticas, que fornecerá várias estatísticas e gráficos sobre o desempenho da construção.

Um dos principais recursos da Integração Contínua é garantir que o on-going testingcontém todo o código que é construído pelo servidor CI. Depois que uma construção é realizada pelo CI Server, deve-se garantir que os casos de teste estejam em vigor para que o código necessário seja testado. Cada servidor CI tem a capacidade de executar casos de teste de unidade como parte doCI suite. Dentro.Net, o teste de unidade é um recurso que está embutido no .Net framework e a mesma coisa também pode ser incorporada ao CI Server.

Este capítulo verá como podemos definir um caso de teste em .Nete, em seguida, deixe nosso servidor TeamCity executar este caso de teste após a conclusão da compilação. Para isso, primeiro precisamos garantir que temos um teste de unidade definido para nosso projeto de amostra.

Para fazer isso, devemos seguir as etapas seguintes com o máximo cuidado.

Step 1- Vamos adicionar uma nova classe à nossa solução, que será usada em nosso Teste de Unidade. Esta classe terá uma variável de nome, que conterá a string “Integração Contínua”. Esta string será exibida na página da web. Clique com o botão direito no Projeto Simples e escolha a opção de menuAdd → Class.

Step 2 - Dê um nome para a classe como Tutorial.cs e clique no botão Adicionar na parte inferior da tela.

Step 3- Abra o arquivo Tutorial.cs e adicione o código a seguir nele. Este código apenas cria uma string chamadaName, e no Construtor atribui o nome a um valor de string como Continuous Integration.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      public Tutorial() {
         Name = "Continuous Integration";
      }
   }
}

Step 4 - Vamos fazer a mudança em nosso Demo.aspx.csarquivo para usar esta nova classe. Atualize o código neste arquivo com o código a seguir. Portanto, este código agora criará uma nova instância da classe criada acima.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      protected void Page_Load(object sender, EventArgs e) {
         tp.Name = "Continuous Integration";
      }
   }
}

Step 5 - no nosso demo.aspx arquivo, vamos agora fazer referência ao tp.Name variável, que foi criada no aspx.cs Arquivo.

<%@ Page Language = "C#" AutoEventWireup = "true" 
   CodeBehind = "Demo.aspx.cs" Inherits = "Simple.Demo" %>
<!DOCTYPE html>
<html xmlns = "http://www.w3.org/1999/xhtml">
   
   <head runat = "server">
      <title>TutorialsPoint1</title>
   </head>
   
   <body>
      <form id = "form1" runat = "server">
         <div>
            <% = tp.Name%>)
         </div>
      </form>
   </body>
   
</html>

Apenas para garantir que nosso código funcione bem com essas alterações, você pode executar o código no Visual Studio. Você deve obter a seguinte saída quando a compilação for concluída.

Step 6- Agora é hora de adicionar nossos testes de unidade ao projeto. Clique com o botão direito emSolution e escolha a opção do menu Add → New Project.

Step 7 - Navegue para Test e no lado direito, escolha Unit Test Project. Dê um nome comoDemoTest e clique em OK.

Step 8 - no seu Demo Test project, você precisa adicionar uma referência ao projeto Simples e ao necessário testing assemblies. Clique com o botão direito no projeto e escolha a opção de menuAdd Reference.

Step 9 - Na próxima tela que aparecer, vá para Projetos, escolha Simple Reference e clique em OK.

Step 10 - Clique Add Reference novamente, vá para Assemblies e digite Webna caixa de pesquisa. Em seguida, adicione uma referência deSystem.Web.

Step 11 - no Unit Test file, adicione o seguinte código. Este código irá garantir que a classe Tutorial tenha uma variável de nome de string. Também afirmará o fato de que o Nome deve ser igual a um valor de “Integração Contínua”. Este será nosso caso de teste simples.

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;

namespace DemoTest {
   [TestClass]
   public class UnitTest1 {
      [TestMethod]
      public void TestMethod1() {
         Tutorial tp = new Tutorial();
         Assert.AreEqual(tp.Name, "Continuous Integration");
      }
   }
}

Step 12- Agora vamos executar nosso teste no Visual Studio para ter certeza de que funciona. No Visual Studio, escolha a opção de menuTest → Run → All Tests.

Depois de executar o teste, você verá o Teste executado com êxito no lado esquerdo do Visual Studio.

Habilitando testes contínuos dentro do TeamCity - Agora que todos os casos de teste estão implementados, é hora de integrá-los em nosso servidor Team City.

Step 13- Para isso, precisamos criar uma etapa de construção em nossa configuração de projeto. Vá para a página inicial do seu projeto e clique em Editar definições de configuração.

step 14 - Em seguida, vá para Etapa de compilação → MS Build e clique em Adicionar etapa de compilação conforme ilustrado na captura de tela a seguir.

Na próxima tela que aparecer, adicione os seguintes valores -

Escolha o tipo de corredor como Testes do Visual Studio.
Insira um nome de etapa de teste opcional.
Escolha o tipo de mecanismo de teste como VSTest.
Escolha a versão do Test Engine como VSTest2013.
No nome dos arquivos de teste, forneça o local como DemoTest\bin\Debug\DemoTest.dll - Lembre-se disso DemoTesté o nome do nosso projeto que contém nossos Testes Unitários. oDemoTest.dll será gerado por nossa primeira etapa de construção.
Clique em Salvar, que ficará disponível no final da tela.

Agora você terá 2 etapas de construção para seu projeto. A primeira é a etapa Build, que criará o código do aplicativo e o projeto de teste. E o próximo será usado para executar seus casos de teste.

Step 15- Agora é hora de fazer o check-in de todo o seu código no Git, para que todo o processo de construção possa ser acionado. A única diferença é que desta vez, você precisa executar ogit add e git commit comando do Demo parent folder como mostrado na imagem a seguir.

Agora, quando o build for acionado, você verá uma saída inicial que dirá que o teste foi aprovado.

Step 16 - Se você clicar no resultado Teste aprovado e ir para a guia Teste, verá agora que o UnitTest1 foi executado e aprovado.

A Inspeção Contínua é o processo de revisão automatizada do código da inspeção realizada para o seu código antes que os testes reais sejam executados. Existem diferenças sutis entre inspecionar e testar o software. O teste é dinâmico e executa o software para testar a funcionalidade. A inspeção analisa o código com base em um conjunto de regras predefinidas.

Os inspetores (ou ferramentas de análise estática e dinâmica) são dirigidos por padrões identificados que as equipes devem aderir (geralmente codificação ou métricas de design). Exemplos de alvos de inspeção incluem padrões de “gramática” de codificação, aderência de camadas arquitetônicas, duplicação de código e muitos outros.

A inspeção contínua reduz o tempo entre uma descoberta e uma correção. Existem várias ferramentas de Inspeção Contínua disponíveis. Para este exemplo, vamos usarNCover 3.xque tem integração com TeamCity. Vamos ver como podemos realizar a Inspeção Contínua e o que ela pode fazer por nós.

Baixe e instale o NCover

NCover é um produto separado que precisa ser baixado e instalado. Para baixar o NCover, clique no link a seguir e baixe o instalador de 32 bits -http://www.ncover.com/info/download.

Execute o instalador baixado e clique em Avançar depois que o instalador for iniciado.

Aceite o contrato de licença e clique em Avançar.

Aceite os componentes padrão e clique em Avançar.

Clique no botão Instalar para iniciar a instalação.

Clique no botão Concluir para concluir a instalação.

Inicie a instalação do NCover pela primeira vez indo para C:\Program Files (x86)\NCover\ NCover.Explorer.exe. Você só precisará instalar uma chave de teste pela primeira vez, o que é um processo simples.

Configure o projeto em TeamCity para usar NCover

Step 1 - Vá para a tela inicial do projeto e clique em Editar definições de configuração.

Step 2 - Vá para Build Steps e clique em Edit para o TestStep. A inspeção contínua precisa ser executada junto com os testes de unidade que são definidos.

Step 3 - Na seção Cobertura .Net, clique em .Net Coverage Tool. Em seguida, escolha as seguintes configurações.

Escolha a ferramenta de cobertura .Net como NCover (3.x)
Plataforma como x86
Versão como v4.0
Caminho para NCover como C: \ Arquivos de programas (x86) \ NCover
Deixe as outras configurações como estão

Step 4 - Clique em Salvar.

Step 5 - Agora vá para a tela principal do seu projeto e clique em Executar.

Step 6- Assim que a compilação for executada, clique em Teste aprovado. Agora você verá uma tela de Cobertura de Código e muitos indicadores de métrica.

Step 7 - Agora você pode clicar na guia Cobertura de código para obter mais informações sobre a análise de código.

Step 8 - Clique no fullcoveragereport.html. Você agora obterá um relatório completo e abrangente sobre a inspeção realizada para o.Net code.

A integração contínua de banco de dados é o processo de reconstruir seu banco de dados e testar os dados sempre que uma alteração é aplicada ao repositório de controle de versão de um projeto.

Na integração de banco de dados, geralmente todos os artefatos relacionados à integração de banco de dados -

Deve residir em um sistema de controle de versão.
Pode ser testado quanto ao rigor e inspecionado quanto à conformidade com as políticas.
Pode ser gerado usando seus scripts de construção.

As atividades que podem estar envolvidas na integração contínua de banco de dados podem ser qualquer uma das seguintes -

Drop a Database - Elimine o banco de dados e remova os dados associados, para que você possa criar um novo banco de dados com o mesmo nome

Create a new Database - Criar um novo banco de dados usando Data Definition Language (DDL).

Insert the Initial Data - Insira quaisquer dados iniciais (por exemplo, tabelas de pesquisa) que se espera que o seu sistema contenha quando entregue.

Migrate Database and Data - Migre o esquema e os dados do banco de dados periodicamente (se estiver criando um sistema baseado em um banco de dados existente).

Modify Column Attributes - Modifique os atributos e restrições da coluna da tabela com base nos requisitos e refatoração.

Modify Test Data - Altere os dados de teste conforme necessário para vários ambientes.

Portanto, em nosso exemplo de banco de dados contínuo, vamos realizar as seguintes etapas -

Criaremos um banco de dados MS SQL Server e uma tabela correspondente.
Criaremos um script a partir do SQL Server Management Studio. Este script de banco de dados será usado para configurar nossa tabela no banco de dados.
Vamos escrever um código em nosso projeto ASP.Net para acessar este banco de dados.
Vamos criar uma etapa em nosso projeto no TeamCity para executar este script.
Vamos verificar nosso script no Git.

Etapas para fazer isso no banco de dados AWS que foi criado em uma seção anterior.

Step 1- Crie um banco de dados MS SQL Server e uma tabela correspondente. Vamos abrir o SQL Server Management Studio e criar um banco de dados e uma tabela simples. Clique com o botão direito em bancos de dados e clique emNew Database.

Step 2 - Nomeie como Demodb e clique em OK

Step 3 - No novo banco de dados, clique com o botão direito e crie uma nova tabela.

Step 4 - Você pode adicionar as colunas desejadas à tabela.

Step 5 - Salve a tabela e nomeie-a como Demotb.

Step 6 - Agora clique com o botão direito na mesa e escolha a opção do menu Script Table as → Drop and Create to → File.

Step 7 - Salve o arquivo na pasta do projeto de demonstração como Sample.sql.

Esta é a aparência do script de banco de dados. Primeiro, ele eliminaria uma tabela existente, se presente, e depois a recriaria.

USE [Demodb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******

DROP TABLE [dbo].[Demotb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Demotb](
   [TutorialName] [nvarchar](max) NULL,
   [TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

Step 8 - Agora vamos mudar rapidamente nosso ASP.Net code para se referir ao novo banco de dados.

Step 9 - no Tutorial.cs arquivo em seu Demo project, adicione as seguintes linhas de código. Essas linhas de código irão se conectar ao seu banco de dados, pegar a versão do servidor e armazenar o nome da versão na variável Name. Podemos exibir essa variável de nome em nossoDemo.aspx.cs arquivo através de um Response.write comando.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      
      public Tutorial() {
         string connectionString = "Data Source = WIN-50GP30FGO75;
         Initial Catalog = Demodb;
         Integrated Security = true;";
         
         using (SqlConnection connection = new SqlConnection()) {
            connection.ConnectionString = connectionString;
            connection.Open();
            Name = connection.ServerVersion;
            connection.Close();
         }
      }
   }
}

Step 10 - Adicione o seguinte código ao Demo.aspx.cs arquivo para garantir que exibe a versão do SQL Server.

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      
      protected void Page_Load(object sender, EventArgs e){
         Response.Write(tp.Name);
      }
   }
}

Agora, se executarmos o código, você obterá a seguinte saída no navegador.

Step 11- Agora vamos adicionar nossa etapa no TeamCity, que invocará o script do banco de dados. Vá para o painel do seu projeto e clique emEdit Configuration Settings.

Step 12 - Vá para Build Steps e clique em Add build step.

Escolha as seguintes opções (observe que o cliente MS SQL Server deve ser instalado no CI Server).

O tipo de corredor deve ser a linha de comando.
Dê um nome de etapa opcional.
A execução deve ser executável com parâmetros.
O executável do comando deve ser C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe
Os parâmetros de comando devem ser -S WIN-50GP30FGO75 -i Sample.sql. Onde –S fornece o nome da instância do SQL Server.

Step 13 - Clique em Salvar.

Agora, o que precisa ser garantido é a ordem de construção. Você deve garantir que a ordem de construção seja a seguinte.

Step 14 - Você pode alterar a ordem de construção escolhendo a opção de reordenar as etapas de construção.

A configuração do banco de dados deve ser a primeira - então, isso será usado para recriar seu banco de dados do zero.
A seguir está a construção de seu aplicativo.
Finalmente sua configuração de teste.

Step 15 - Agora execute o git add e git commit comando para que o Sample.sqlarquivo é verificado no Git. Isso irá disparar uma construção automaticamente. E esta construção deve passar.

Agora você tem um ciclo de construção completo com um aspecto de integração contínua de banco de dados também em seu ciclo. Na próxima seção, vamos aprofundar e examinar a implantação contínua.

Agora que você fez isso com um SQL Server local, podemos repetir as mesmas etapas para um AWS MS SQLServidor que foi criado em uma das seções anteriores. Para se conectar a um Microsoft SQL Server, você precisa se conectar por meio da seguinte convenção.

Step 16- Primeiro veja qual é o nome atribuído à sua instância de banco de dados na AWS. Ao fazer login no AWS, vá para a seção RDS na seção de banco de dados.

Step 17 - Clique em Instâncias de banco de dados na próxima tela que aparecer.

step 18- Clique em seu banco de dados e anote o endpoint. Na imagem a seguir, édemodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433

Step 19 - Agora, para se conectar ao banco de dados de SQL Server Management Studio, você precisa especificar a conexão como demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com,1433 (Observe a vírgula usada entre o nome da instância e o número da porta).

A captura de tela a seguir mostra uma conexão bem-sucedida com o banco de dados.

Então você pode repetir todos os mesmos passos. oSqlcmd command será o seguinte -

Este mesmo comando pode ser substituído na etapa de construção do banco de dados no TeamCity. Quando você executa osqlcmd command, a tabela será criada automaticamente em seu banco de dados SQL Server na AWS.

Builds automatizados e builds repetíveis. Testes automatizados e testes repetíveis. Categorias de teste e frequências de teste. Inspeções contínuas. Integração contínua de banco de dados. Essa sequência de tarefas na criação de um ambiente de CI eficaz permite principalmente um benefício importante: o lançamento de software funcional a qualquer momento, em qualquer ambiente.

Em nossos capítulos anteriores, realizamos todos os seguintes segmentos -

Criou nosso código.
Garantiu uma construção adequada no TeamCity.
Criou um processo de integração de banco de dados.
Teste realizado com sucesso.

Agora só falta fazer uma implantação automatizada, para que todo o nosso processo seja concluído.

Para uma implantação automatizada em nosso caso, precisamos seguir estas etapas -

Em nosso servidor de implantação, verifique se o IIS está instalado.
Certifique-se de que o usuário IIS tenha acesso ao nosso banco de dados.
Crie um perfil de publicação que será usado para publicar o site quando ele for construído.
Certifique-se de alterar nosso comando MSBuild para fazer uma implantação automática.
Automatize o TeamCity para fazer uma publicação automática.
Faça um git commit para garantir que todos os seus arquivos estejam no Git.

Step 1- Configure um servidor IIS local. Se você tiver um servidor IIS local ou remoto, a seguinte configuração pode ser realizada para implantar nosso aplicativo. É sempre uma boa prática ver se uma implantação pode ser feita manualmente antes de ser feita de forma automatizada.

Step 2 - Em um servidor Windows 2012, vá para o Gerenciador do servidor e clique em Adicionar funções e recursos.

Step 3 - Clique em Avançar na tela seguinte que aparece.

Step 4 - Escolha a instalação baseada em funções ou recursos na próxima tela e clique em Avançar.

Step 5 - Selecione o servidor padrão e clique em Avançar.

Step 6 - Escolha a função do servidor Web e clique em Avançar.

Step 7 - Na próxima tela que aparecer, clique em Avançar.

Step 8 - Clique em Avançar novamente na tela a seguir que aparece.

Step 9 - Na próxima tela que aparecer, clique em Avançar.

Step 10 - Na tela final, você pode clicar no botão Instalar para instalar o IIS.

Depois de instalar o IIS, você pode abri-lo abrindo os Serviços de Informações da Internet.

Step 11 - Clique em pools de aplicativos, você verá um pool com o nome de DefaultAppPool. Isso precisa ter acesso ao SQL Server na próxima etapa.

Step 12 - Se precisarmos conectar um aplicativo ASP.Net a um aplicativo MS SQL Server, temos que dar acesso ao pool de aplicativos padrão para a instância do SQL Server, para que ele possa se conectar ao nosso Demodb base de dados.

Step 13- Abra o SQL Server Management Studio. Vá para Logins, clique com o botão direito e escolha a opção do menuNew Login.

Na próxima tela, atualize os parâmetros a seguir e clique em OK.

Nome de login como IIS APPPOOL \ DefaultAppPool.
Banco de dados padrão - este deve ser nosso banco de dados, que é demodb.

Step 14 - Criando um Publish Profile. O perfil de publicação é usado no Visual Studio para criar um pacote de implantação que pode ser usado com o MS Build e em qualquer CI Server de acordo. Para fazer isso, a partir do Visual Studio, clique com o botão direito do mouse no projeto e clique na opção de menu Publicar

Step 15 - Na próxima tela que aparecer, escolha criar um novo perfil de Publicação, dê um nome a ele - DemoDeployment. Em seguida, clique no botão Avançar.

Na tela seguinte que aparece, adicione os seguintes valores -

Escolha o método Publish como Web Deploy.
Insira o servidor como localhost.
Insira o nome do site como Site / Demo padrão.
Coloque o url de destino como http://localhost/Demo

Em seguida, clique no botão Avançar.

Step 16 - Na próxima tela, clique em Avançar.

Step 17 - Na tela final que aparece, clique no botão Publicar.

Agora, se você for ao C:\Demo\Simple\Properties\PublishProfiles localização do seu projeto, você verá um novo publish profile xml filecriada. Este arquivo de perfil de publicação terá todos os detalhes necessários para publicar seu aplicativo no servidor IIS local.

Step 18- Agora vamos personalizar nosso comando MSBuild e usar o perfil de publicação acima e ver o que acontece. Em nosso comando MSBuild, especificamos os seguintes parâmetros -

Implantar na construção é verdadeiro - isso acionará uma implantação automática assim que uma construção bem-sucedida for concluída.
Em seguida, estamos mencionando o uso do perfil Publicar que foi usado na etapa acima.
A versão do Visual Studio é apenas para ser mencionada no recurso de implantação do MSBuild sobre qual é a versão do Visual Studio que está sendo usada.

Quando você executa o comando acima, o MSBuild aciona um processo de construção e implantação. O que você notará, é implantá-lo em nossoDefault Website em nosso servidor IIS.

Agora, se navegarmos até o site - http://localhost/Demo/Demo.aspx veremos a seguinte saída, o que significa que o MSBuild fez uma implantação bem-sucedida em nosso site.

Step 19 - Automatizando através do TeamCity - Agora é hora de adicionar uma tarefa ao nosso servidor TeamCity para usar automaticamente o MSBuild para implantar nosso aplicativo, com base nas etapas acima mencionadas.

Step 20 - Vá para o painel do seu projeto e clique em Edit Configuration Settings.

Step 21 - Vá para Etapas de construção e clique em Adicionar uma etapa de construção.

Escolha as seguintes opções -

O tipo de corredor deve ser MSBuild
Dê um nome de etapa opcional
Insira o caminho de construção como Simple / Simple.csproj
Mantenha a versão do MSBuild como Microsoft Build Tools 2013
Mantenha a versão do MSBuild Tools como 12.0
Coloque a linha de comando como / p: DeployOnBuild = true / p: PublishProfile = DemoDeployement / p: VisualStudioVersion = 12.0

Step 22 - Clique em Salvar.

Certifique-se de que nas etapas de construção, a etapa Implementar seja a última etapa da cadeia.

Step 23 - Agora vamos fazer uma final git commit, para garantir que todos os arquivos estejam no Git e possam ser usados pelo TeamCity.

Parabéns, você configurou com sucesso um Ciclo de Integração Contínua completo para seu aplicativo, que pode ser executado a qualquer momento.

Vamos fazer uma revisão final das melhores práticas de integração contínua com base em todas as lições que aprendemos até agora -

Maintain a code repository- Esta é a etapa mais básica. Em todos os nossos exemplos, tudo é mantido em um repositório Git, desde a base de código até os perfis de publicação e os scripts de banco de dados. Deve-se sempre garantir que tudo seja mantido no repositório de código.
Automate the build- Vimos como usar o MSBuild para automatizar uma compilação junto com o uso de um perfil de publicação. Esta é novamente uma etapa fundamental no processo de integração contínua.
Make the build self-testing - Certifique-se de que você pode testar a construção mantendo os casos de teste de unidade no lugar e esses casos de teste devem ser de tal forma que possam ser executados pelo servidor de Integração Contínua.
Everyone commits to the baseline every day- Este é um princípio fundamental da Integração Contínua. Não adianta ficar até o final de todo o processo para ver quem quebra a compilação.
Every commit (to baseline) should be built- Todo commit feito para o aplicativo precisa ser construído com sucesso. Se o build falhar por qualquer motivo, o código precisará ser alterado para garantir que o build seja aprovado.
Keep the build fast- Se a construção for lenta, isso indicaria um problema em todo o processo de Integração Contínua. Certifique-se de que as compilações sejam sempre limitadas a uma duração, de preferência nunca ultrapasse 10 minutos.
Everyone can see the results of the latest build- O painel TeamCity dá a todos uma visão de todas as construções, que foram aprovadas ou reprovadas. Isso dá uma boa visão para todas as pessoas que estão envolvidas no processo de Integração Contínua.