Tag: Build

Definições de Build – Continuous Integration (DevOps)

2 Comments

Por aqui vamos demonstrar o passo-a-passo das definições de Build, utilizando o VSTS da Microsoft para criar o workflow com as tarefas de Integração Contínua (Continuous Integration) no time de desenvolvimento.

Acesse o VSTS no Projeto que será feita a configuração de Build, utilizando o caminho Build and Release > Builds. O botão + New cria um novo workflow para configurar as definições de Build.

Get sources
O primeiro passo é configurar o versionador de código (TFVS | GitHub | Subversion | etc.) e Workspace Mappings (Map | Cloak) com o caminho de execução dos Builds do projeto.

Build-definition-I

NuGet
O NuGet é um package management compatível com plataforma Microsoft e contém o código compilado (DLLs),  trabalhando com bibliotecas e ferramentas do Visual Studio. Os pacotes podem ser publicados em host público ou privado. Nesta fase, somente indicar o local (path) da Solution do projeto, conforme abaixo:

Build-definition-II

Visual Studio Build
A configuração do Build é simples, basta indicar o path da Solution do projeto.

Build-definition-III

Visual Studio Test
Esta tarefa é sensacional para o CI. O Visual Studio Test permite executar testes unitários, code coverage, entre outros. Neste link há mais detalhes sobre esta task.

Neste exemplo, selecionamos o Test Assemblies, relacionando as DLLs e o caminho do projeto de teste da solução. Também habilitamos o Code Coverage Enabled para analisar a proporção de código que está sendo coberto por testes, como testes unitários.

Build-definition-IV

Index Sources & Publish Symbols
O Symbol Servers habilita os debuggers para retornar automaticamente o correto symbol files sem conhecimento do nome do produto, número do build ou nome do pacote. Veja mais em Publish Symbols for debugging.

Build-definition-V

Code Analysis
O VSTS analisa o código gerenciado de duas maneiras:

  • Static Analysis of Managed Assemblies – FxCop: fornece informações para corrigir problemas com violações de programação e regras de design.
  • . Net Compiler Platform Analyzers – Roslyn: analisa qualidade, estilo, facilidade de manutenção, design e outros problemas de código. Muitas regras da análise de código estático já foram reescritas na análise Roslyn e podem substituir a análise estática para código gerenciado.

Em nosso exemplo, definimos a regra de Minimum Recommended Rules que atua nos problemas mais críticos do código. A descrição de todas as regras podem ser encontradas na documentação da Microsoft.

Build-definition-VI

O check-in do código pode ser configurado com política para prevenir que o desenvolvedor faça check-in sem ter executado a análise do código. O SonarQube também é uma ótima ferramenta de análise do código e pode ser integrada com o VSTS.


Publish Build Artifacts
E na última etapa somente a configuração do local onde será publicado o artefato.

Build-definition-VII

 

Referências
– Get Sources – Cloak
– Nuget with VSTS
– Visual Studio Test
– Code Analysis – Microsoft
– Publish Symbols for debugging
– Publish Build Artifacts – Microsoft

VSTS – Processo de Release

Contexto: criar e configurar o processo de Release dentro do VSTS, gerenciando os artefatos e pipelines

Leitura recomendada: recomendo a leitura do artigo VSTS – Build e Release para entendimento do processo de Build e Release utilizando o VSTS

Criando o Processo de Release

O primeiro passo para criar um novo processo de Release é acessar o Visual Studio e escolher a opção “Releases” dentro do Menu “Build and Release”.

No canto esquerdo, clique no botão “+” e escolha a opção “Create release definition“. release-definition

E então é criada a Pipeline para a publicação dos binários:release-pipeline

Escolha o template que será utilizado para o projeto ou a opção “Empty Process”. Defina o nome para o ambiente que será feito o deploy no servidor e os owners do ambiente.release-environment

Adicionando o artefato de Build

A etapa posterior é testar os binários nos ambientes. Para isso, devemos adicionar o Build que será promovido nos ambientes. No Pipeline de Release, clique em “+ Add Artifact” e selecione o Build que será promovido no Pipeline de Release:

  • Source Type: escolha a opção Build
  • Project: (defina o nome do projeto que será utilizado)
  • Source (Build Definition): será o Build da última versão desenvolvida
  • Clique em Add…

release-artifact

 

Adicionando Tasks nos ambientes

E agora podemos adicionar as Tasks em cada um dos servidores. Para isso, acesse a Release criada (clicando no nome da Release) > Environments. Clique no link para adição / edição das tasks:
release-environments

Em Agent Phase, defina os seguintes parâmetros:
release-agent-phase

E em “+” para adicionar uma nova Task:
release-agent-phase-I

 

Em Add Tasks, no campo Search, digite Tokenize:
tokenize
Caso a task não esteja instalada no seu VSTS, ela deve ser baixada através do Market Place. Ela tem por objetivo mudar as linhas do Web.confg de acordo com o ambiente.  Clique em Add para adicionar a task e configure a task de Tokenize:
tokenize_I

Na aba Variables, podemos configurar as variáveis de ambiente oriundas do Web.Config
release-web-config

Em seguida, adicione uma Nova Task chamada Windows Machine File Copy e configure os parâmetros abaixo:
windows-machine

No VSTS existe a possibilidade de clonar os ambientes afim de aproveitar as configurações prévias. Para isso vá ao Pipeline > Environments > e clique em Clone. Será criado um novo ambiente para promoção do binário. Assim, teremos a esteira pronta para os servidores.
esteira

 

VSTS – Build e Release – DevOps

1 Comment

Objetivo: descrever a importância do Build e Release no processo de DevOps

Contexto: colocar um novo sistema em produção (ou incremento) é uma demanda frequente nas organizações que trabalham com desenvolvimento de sistemas. Não pode haver bottlenecks! Há um constante monitoramento para checar se os usuários estão realmente utilizando as releases e o que podemos fazer para melhorar a experiência do usuário.

Tudo isso exige um processo de Continuous Integration / Delivery / Deployment. As práticas de DevOps, incluindo a configuração de Build e Release, são essenciais para melhorar a qualidade, controle e integração dos sistemas a serem publicados. Evitar versões erradas em produção e a famosa frase do desenvolvedor “na minha máquina funciona” são dilemas que as empresas mitigam com um bom modelo de versionamento e gestão de fila da implementação.

E assim, desde a criação de máquinas de Build até a transição nos servidores de DEV, QA, Homologação, Pré-produção e Produção, compartilho no post abaixo uma orientação de configuração de Build e gestão dos artefatos no ambiente VSTS.


Build e Release

O processo de Build envolve funções de integração, construção, versionamento, qualidade e compilação do código-fonte produzido. As ferramentas VSTS, Maven e GitHub são utilizadas para auxiliar na integração e monitoramento dos artefatos. Quando há quebra no Build devido a problema neste processo, os desenvolvedores precisam corrigir e fazer o check-in novamente. O processo de integração contínua e o apoio da infraestrutura são necessários para manter a esteira de publicação rápida, principalmente para organizações que trabalham em larga escala.

Posteriormente, o Release é a liberação da nova versão do sistema em produção. Considera-se que no Build já tenha sido avaliado e testado a qualidade para garantir que não haja erros. Este processo consome recurso de servidores, que dependendo da complexidade, exige escalabilidade para realizar o deploy do código.

Para automatizar as etapas do processo de Build e Release e envio dos scripts ao repositório, os times geralmente utilizam ferramentas como Jenkins. Outros aspectos a serem considerados:

  • Criar servidor(es) para execução de Builds
  • Automatizar etapa de compilação e deploy
  • Ambientes (Dev | QA | Homologação | Produção)
  • Processo de qualidade para validação do negócio
  • Testes automatizados
  • Padrnoização de regras para arquitetura
  • Utilização de teste unitário, Sonarqube (qualidade do código) e práticas como BDD ou TDD


Utilizando VSTS

Build
Acesse o VSTS > Build and Release > Builds para configurar as definições de Build:

build

Todas as opções abaixo estão disponíveis para configuração:

  • Tasks – Build Name / Agent Queue / Path to solution / Artifact Name
  • Variables
  • Triggers – Continuous Integration (Build every change to matching branches: Disabled) | Gated Check-in (Accept check-ins only if the submitted changes merge and build successfully: Enabled) | Scheduled (Build matching branches for each schedule: Disabled)
  • Options – Build properties (Description / Build number format) / New build request processing: Enable / Automatically link new work in this build… / Create work item on failure / Allow scripts to access OAuth token / Build job / Define build job authorization and timeout settings / Build job authorization scope / Build job timeout in minutes / Build job cancel timeout in minutes / Demands / Specify which capabilities the agent must have to run this process
  • Retetion – Days to Keep / Minimum keep / When cleaning up builds… / History


Release
Também no VSTS > Build and Release > Release para criar as definições de Release:

release

E assim será criado o Pipeline para publicação dos binários, com a escolha do Template, nome do ambiente (que será realizado deploy) e owners do ambiente.

Artefatos de Build
Também podemos criar artefatos de Build, selecionando o Build (na Source Type) que será promovido na Pipeline de Release. Escolha também o projeto e a última versão desenvolvida.

artefato

Há outras configurações como tarefas, variáveis e opções que estão disponíveis no VSTS. Como o propósito foi introduzir o tema, sugiro acessar o Docs da Microsoft para ter mais detalhes sobre as configurações de Build e Release.