Esta é a primeira de duas postagens do blog sobre Jenkins e Couchbase. Esta primeira postagem é uma introdução geral à implantação contínua: você aprenderá a usar Jenkins para implantar um aplicativo .NET automaticamente. A segunda publicação do blog se concentrará mais em como usar o Jenkins para configurar dados de teste no Couchbase antes de executar seu código de teste.

Como desenvolvedor de .NET, você provavelmente está usando o Visual Studio. Pressionar F5 no Visual Studio compila o código-fonte e inicia o depurador. Se você for como eu, pressionará F5 muitas vezes durante o desenvolvimento e a busca de bugs.

Mas o que acontece quando o código está pronto para o horário nobre? A implantação acontece!

Quando preciso publicar um aplicativo, geralmente escolho a opção mais preguiçosa: copiar manualmente o executável para o destino, instalar manualmente e iniciar manualmente o aplicativo.

É "divertido" nas primeiras vezes, mas, no final, torna-se muito difícil, principalmente acompanhar as alterações e as atualizações/implantações manuais. Para ser sincero, essa abordagem manual não é muito bem dimensionada: leva tempo desnecessário e é propensa a erros humanos no processo de implementação.

Uma opção mais madura seria ter uma infraestrutura automatizada para lidar com a implementação. Essa infraestrutura é geralmente chamada de integração contínua/implantação contínua.

O uso da integração contínua/implantação contínua permite um fluxo de trabalho como este:

  • Codifique, crie e teste localmente em sua caixa de desenvolvimento (como de costume)
  • Verifique o código-fonte em uma ramificação de desenvolvimento no seu sistema de gerenciamento de controle de fontes favorito.
  • Revisão opcional do código pelos membros da equipe.
  • Faça o merge de suas alterações na ramificação principal (versão).
  • O servidor de CI detectará as alterações na ramificação principal e fará o download, compilará e implantará/instalará seu aplicativo no servidor de versão.

Não há etapas manuais: tudo é roteirizado e automático.

Implementação contínua

Você pode escolher entre várias ferramentas de integração/implantação contínua (CI), cada uma com suas próprias ressalvas. Na minha configuração, preciso de um servidor de CI que entenda os componentes do meu aplicativo.

Então, vamos dar uma olhada mais de perto na arquitetura e nos componentes do meu aplicativo:

  • Plataforma: .NET 4.5.2
  • IDE: Visual Studio 2015 (arquivos MSBuild)
  • Tipo de aplicativo: Serviço do Windows
  • NuGet: Gerenciador de pacotes usado para todas as referências.
  • Controle de origem: Git (github.com)

O servidor de CI deve ser capaz de compreender todos os componentes mencionados acima e (como sou preguiçoso) deve ser muito fácil de manter e configurar.

Pesquisei um pouco e, com base nas experiências de outras pessoas e em publicações em blogs, descobri que é melhor usar o Jenkins para implantar um serviço do Windows.

Jenkins

O Jenkins é um servidor de compilação com uma arquitetura de plug-in que permite que a comunidade amplie o que o Jenkins pode "entender". Essa arquitetura facilita a extensão do Jenkins para suportar arquivos MSBuild, controle de versão Git etc.

Conheça Jenkins

Configuração

O Jenkins é instalado em um servidor de compilação. Na minha configuração, o servidor de compilação é o mesmo que o servidor de lançamento, mas isso pode ser configurado de forma diferente.

Faça o download e instale Jenkins para sua plataforma aqui: https://jenkins-ci.org/

Após a instalação, o Jenkins estará disponível em sua porta padrão: http://localhost:8080/

Configurar o Jenkins

O Jenkins tem plug-ins para entender repositórios Git, arquivos MSBuild e várias outras tecnologias. Na configuração atual, só precisamos estender o Jenkins com esses dois plug-ins.

Instale o plug-in do Git para o Jenkins:

  1. Open Jenkins, http://localhost:8080/
  2. Navegue até "Gerenciar Jenkins"
  3. Navegue até "Manage Plugins" (Gerenciar plug-ins)Link direto: http://localhost:8080/pluginManager
  4. Use a caixa de "filtro" para pesquisar "Git plugin" e instalar o plugin.

Instale o plug-in MSBuild para Jenkins:

  1. Open Jenkins, http://localhost:8080/
  2. Navegue até "Gerenciar Jenkins"
  3. Navegue até "Manage Plugins" (Gerenciar plug-ins)Link direto: http://localhost:8080/pluginManager
  4. Use a caixa de "filtro" para pesquisar "MSBUILD plugin" e instalar o plugin.plugin screenO Jenkins agora entende os arquivos do MSBuild e o controle de origem do Git, mas ainda precisamos configurar o plug-in do MSBuild com um caminho para o arquivo msbuild.exe que gostaríamos de usar.

Configuração do MSBuild

Quando o plug-in MSBuild foi instalado, ele adicionou suas próprias opções de configuração à página de configuração global do Jenkins.

  1. Navegue até http://localhost:8080/
  2. Clique em "Manage Jenkins" (Gerenciar Jenkins)
  3. Clique em "Configure System" (Configurar sistema)
  4. Role a lista para baixo até encontrar "MSBuild"
  5. Clique no botão "MSBuild installations..." (Instalações do MSBuild...)
  6. Clique em "Add MSBuild" (Adicionar MSBuild)
  7. Dê à nova configuração do MSBuild um nome como "MSBuild-default".
  8. No campo path (caminho), insira o caminho totalmente qualificado para msbuild.exeNo meu servidor, o caminho é: C:Arquivos de Programas (x86)MSBuild14.0Binmsbuild.exeLeia abaixo para obter mais informações sobre o MSBuild e como instalá-lo.
  9. Clique em salvar.

plugin screen

Instalação do MSBuild

O MSBuild é instalado com o Visual Studio, é o sistema de compilação que o Visual Studio usa quando você seleciona "build" ou pressiona "F5".

Nem sempre é viável ou mesmo possível instalar o Visual Studio em seu computador de compilação. Isso pode ocorrer devido a problemas de licença e segurança etc.

Para acomodar isso, a Microsoft lançou um pacote separado chamado: "Microsoft Build Tools 2015", que contém tudo o que você precisa para usar o MSBuild.

Download direto: https://www.microsoft.com/en-us/download/details.aspx?id=48159

Após a instalação bem-sucedida, você terá o MSBuild disponível no servidor de compilação e, com isso, obterá o valor do caminho para a etapa 8, acima.

Com essa etapa concluída, o Jenkins está pronto para criar e implantar com o MSBuild e o Git.

Criar um novo projeto de compilação Jenkins

Agora é hora de indicar a Jenkins o código-fonte e começar a construir.

  1. Open Jenkins, http://localhost:8080/
  2. Selecione "novo". Link direto http://localhost:8080/view/All/newJob
  3. Dê ao projeto o nome "Windows Service Deployment" ou algo que você possa lembrar.
  4. Selecione "Freestyle project" (Projeto de estilo livre).
  5. Selecione "Ok".plugin screen
  6. Em seguida, expanda a região "Source Code Management" selecionando "Git".plugin screen
  7. Complete a configuração do Git preenchendo os espaços em branco com um URL para o seu repositório e, opcionalmente, com as credenciais (se necessário). Nesta configuração, deixarei a ramificação como padrão (Master), mas você pode selecionar o que for mais adequado às suas necessidades. Se você ainda não tiver um repositório Git pronto para teste, poderá usar o repositório pré-preparado aqui:https://github.com/martinesmann/jenkins-ci-templateO código-fonte contém alguns arquivos a mais do que a solução "Hello Windows Service" comum. Explicarei as partes relevantes mais adiante, à medida que forem usadas. Por enquanto, trataremos isso apenas como uma solução "Hello World".
  8. Se ainda não tiver feito isso, clique em "Save" (Salvar) para manter suas alterações e voltar à página principal do "Project" (Projeto).

Testar a configuração do Git

Agora podemos testar se a guia Git Source Management foi configurada corretamente e se podemos clonar o código-fonte.

Ainda não estamos construindo nada, apenas clonando a fonte. A compilação virá em breve. Primeiro, vamos nos certificar de que o Jenkins possa clonar a fonte do repositório.

  1. Navegue até a página "Project" (Projeto)
  2. Clique em "Build Now" para iniciar uma "Build".plugin screen
  3. Na região "Build History" (Histórico de compilação), você deverá ver uma compilação em andamento com o nome "#1".
  4. Se tudo for concluído como esperado, "SUCCESS" (Sucesso), o criador de bolhas permanecerá azul; caso contrário, ficará vermelho.
  5. Para ver os detalhes da compilação, clique no número da compilação "#1"
  6. Em seguida, clique em "Console Output" (Saída do console). Você deverá ver algo semelhante ao que tenho aqui:

    *O que é importante observar aqui é a caminho para o "espaço de trabalho", pois é nele que o código-fonte é baixado e construído. Esse conhecimento pode ser muito útil ao depurar a configuração da CI.

Criação do código-fonte

A próxima etapa é compilar e construir o código-fonte.

  1. Navegue até a página "projeto"
  2. Selecione "Configure" (Configurar)
  3. Localize a opção "Adicionar etapa de compilação"image
  4. Selecione a opção "Build a Visual Studio project or solution using MSBuild". Precisamos configurar alguns valores aqui:
    1. Primeiro, selecione a versão do MSBuild (configuramos isso em uma etapa anterior).
    2. Em seguida, forneça o caminho para o arquivo *.sln ou *.proj de seu projeto.Para o repositório pré-cozido, o caminho é: srcMyWindowsServiceMyWindowsServiceDeploy-Windows-Service-Via-MSBuild.projObserve: Não estamos apontando para o arquivo de solução, mas sim para um arquivo MSBuild personalizado que está no projeto. Esse arquivo MSBuild está lidando com todas as etapas envolvidas na compilação e na implementação do serviço do Windows.Se estiver usando o repositório pré-preparado, sua configuração deverá ser semelhante a esta:image
    3. Clique em salvar

Restauração do pacote NuGet

Se fôssemos criar o projeto neste momento, ele falharia devido à falta de pacotes NuGet. Portanto, precisamos restaurar os pacotes NuGet antes de tentar compilar a fonte.

nuget.exe torna essa tarefa muito fácil, basta acionar esse comando no arquivo de solução:

nuget restore "caminho para o arquivo *.sln

Não é surpresa que o Jenkins possa lidar com várias etapas de compilação, então vamos adicionar uma etapa de compilação para ativar a restauração do NuGet.

  1. Navegue até a página "projeto".
  2. Selecione "Configure" (Configurar).
  3. Localize a opção "Adicionar etapa de compilação".
  4. Clique em "Add build step" (Adicionar etapa de compilação).image
  5. Selecione "Execute Windows batch command" (Executar comando em lote do Windows).
  6. Reorganize a ordem de construção arrastando a nova etapa de construção para o topo.image
  7. No campo Comando, insira:nuget restore srcMyWindowsService
  8. Clique em "Salvar".

Agora estamos prontos para construir o projeto!

O teste final! Horário nobre!

  1. Navegue até a página do projeto
  2. Clique no link "Build now" (Criar agora)
  3. Aguarde a conclusão da compilação
  4. Abra o "Windows Explorer" e navegue até C:
  5. Confirme se o arquivo "MyWindowsService.log" existeimage
  6. Abra o arquivo e leia o conteúdo do registro. Esse arquivo foi criado pelo nosso serviço do Windows recém-instalado!
  7. Verifique se o serviço está instalado e em execução:
    1. No Windows, abra a janela de gerenciamento "Serviços"
    2. Role a tela para baixo até encontrar o serviço "My Windows Service (...)"image

Parabéns! Agora você configurou com sucesso o Jenkins para fazer download, compilar e implementar um serviço Windows .NET! A automação é demais!

O código-fonte:

Até o momento, não demos muita atenção ao código-fonte, mas vamos analisar o conteúdo e a estrutura do repositório.

Se você navegar até a raiz do repositório em:

https://github.com/martinesmann/jenkins-ci-template

Você encontrará todos os arquivos usuais como README etc., mas também um arquivo chamado nuget.exe.

nuget.exe é o executável usado para restaurar as dependências do pacote NuGet da solução. Você poderia argumentar se é ou não uma boa prática ter arquivos binários no seu controle de origem, mas, nesse caso, é uma dependência necessária para o sistema de compilação e, portanto, eu o incluí.

Eu coloquei nuget.exe na raiz, para mantê-lo separado do código-fonte real e facilitar a localização ao configurar a compilação no Jenkins.

Se navegarmos mais profundamente no repositório para src/MyWindowsService/MyWindowsService/ encontramos quatro arquivos que fazem todo o trabalho pesado de compilação e instalação do Windows Service.

O arquivo do ponto de entrada principal é Implantar o Windows-Service via-MSBuild.proj é um arquivo MSBuild criado não apenas para compilar o código-fonte, mas também para parar, desinstalar e iniciar o aplicativo Windows Service. Isso é feito chamando os três arquivos em lote conforme necessário: safeServiceDelete.bat, safeServiceStart.bat e safeServiceStop.bat.

Está fora do escopo desta postagem do blog explicar em detalhes o que cada um dos quatro arquivos faz, mas se você der uma olhada nos arquivos individualmente, tenho certeza de que terá uma boa compreensão de seu funcionamento interno e de como eles colaboram.

O código-fonte do Windows Service pode ser visualizado e editado no Visual Studio para atender às suas necessidades específicas. O código-fonte de amostra fornecido no repositório é muito simples e grava apenas algumas entradas em um arquivo de texto (arquivo de registro) e também "insere" um documento no Couchbase Server:

Service1.cs

Se você não tem experiência com o Couchbase, sugiro que dê uma olhada no nosso tutorial de .NET aqui:

try-cb-dotnet.

Crie seu próprio

A maneira mais fácil de usar o Jenkins e o .NET para criar e implantar Seu próprio serviço automatizado do Windows provavelmente seria clonar esse repositório e alterar o código do serviço no Visual Studio para atender às suas necessidades.

Obrigado pela leitura!

Autor

Postado por Martin Esmann, defensor dos desenvolvedores, Couchbase

Martin Esmann é um defensor do desenvolvedor .Net na Couchbase. Ele é um desenvolvedor apaixonado com foco profundo em tecnologias Microsoft como .NET.

5 Comentários

  1. Boa postagem, Martin,
    Você pode explicar melhor como instalar a restauração do pacote NuGet.
    Até onde sei, o gerenciador de pacotes NuGet exige que o Visual Studio instale todos os pacotes que serão usados no projeto.
    Depois que o pacote é instalado, as DLLs são adicionadas à pasta "bin", que será usada nos pacotes de implantação.
    Então, qual é o uso exato da restauração de pacotes NuGet aqui?

  2. Andy,
    O nuget.exe que Martin menciona na postagem é a versão de linha de comando do gerenciador de pacotes incorporado ao VS (está disponível em nuget.org). O fluxo típico para um servidor de CI é:
    * Confira o código mais recente
    * Restaurar pacotes (linha de comando: nuget restore)
    * Compilar usando o MSBuild
    Quando você faz uma restauração do nuget, os pacotes não são colocados na pasta bin - isso é para os binários compilados após a compilação. As dependências do nuget são colocadas em um diretório de pacotes (normalmente no mesmo nível do arquivo de solução) e, em seguida, o MSBuild faz toda a sua mágica.

  3. Como você conseguiu implementar o Windows Service com o MSBuild? Poderia dar mais informações?

  4. Obrigado por compartilhar conosco. Adorei sua forma de apresentação. Gostei de ler isso. Obrigado por compartilhar e continue escrevendo. É bom ler blogs como esse. Treinamento em Dot Net

  5. Ótimo guia! Só uma pergunta: tudo funciona para mim, exceto a etapa de restauração do pacote NuGet. Isso me dá os seguintes erros:

    ADVERTÊNCIA: O servidor remoto retornou um erro: (404) Não encontrado.
    ADVERTÊNCIA: O servidor remoto retornou um erro: (404) Não encontrado.
    ADVERTÊNCIA: O servidor remoto retornou um erro: (404) Não encontrado.
    ADVERTÊNCIA: O servidor remoto retornou um erro: (404) Não encontrado.
    Não foi possível encontrar a versão '3.1.0' do pacote 'Common.Logging'.
    Não foi possível encontrar a versão '3.1.0' do pacote 'Common.Logging.Core'.
    Não foi possível encontrar a versão '2.2.2' do pacote 'CouchbaseNetClient'.
    Não foi possível encontrar a versão '6.0.8' do pacote 'Newtonsoft.Json'.

    Você tem alguma ideia do que pode estar acontecendo de errado?

Deixar uma resposta