Tag: CI

VSTS – Pipeline de releases e gestão da mudança com aprovadores

1 Comment

Contexto: já vimos os benefícios e desafios dos processos de CI (Continuous Integration) e CD (Continuous Delivery) em outros posts. Além de habilitar esteiras velozes e eficientes para publicação de releases, é um dos pontos determinantes na adoção de práticas DevOps na empresa.

Este post é direcionado as empresas que possuem processos mais formais, regidos por compliance. O release neste caso depende de aprovações como do gestor da mudança (change management) e outras áreas, como a homologação do solicitante (geralmente o Product Owner), antes de ir para a produção.

VSTS – Configurando aprovações no pipeline de releases
Iniciamos criando uma nova definição de release. Para isso, acesse o VSTS na opção de Build and Release. Em Releases, clique em + Create Release Definition. A janela abaixo será aberta com as configurações da release. Escolha os ambientes (environments) e artefatos que serão trabalhados.

release

Em seguida, todas as Releases criadas serão exibidas na tela. Neste exemplo já haviam outras releases criadas, por isso apareceram várias. Clique em Edit para configurar o Pipeline com os Artefatos e Tarefas da release.

releases.png

O Pipeline habilita a configuração Artefato (na esquerda) e dos Ambientes (na direita). É nesta área que definimos os aprovadores, triggers e agendamento das tarefas.

pipeline-releases

Artefato
Ao adicionar um novo artefato, escolha o tipo do artefato – Build | Source Control | etc., referencie o nome do projeto e as definições de Build (por termos escolhido o Build no source type). 
artifact-release

Environments
Ao adicionar os ambientes em + New Environment, podemos criar por exemplo, os ambientes de desenvolvimento, homologação e produção. Utilize a opção clone environment após a criação do primeiro ambiente para copiar as configurações (se aplicável) a fim de facilitar.

Com os ambientes criados, clique na própria caixa do ambiente para configurar as tarefas que serão executadas pelo Agent (lado direito da imagem abaixo).

release-environments

Também na configuração do ambiente, mas no canto esquerdo da caixa há uma imagem que representa triggers e aprovadores para pré ou pós deployment. Clique nela:
trigger-approval

Em seguida, será exibida uma tela com a configuração de Pre-deployment:

  • Triggers: define se o evento acontecerá After release | After Environment | Manual Only
  • Pre-deployment approvals: insira os usuários que precisam aprovar a release antes de subir em produção, ou mesmo no ambiente de QA.
  • Schedule: se o build (que inicia a execução das releases) não estiver automático, esta opção permite agendar a execução das releases.

 

O acompanhamento do deploy das releases está disponível na aba Logs. O status de cada etapa e em qual ambiente está sendo executado pode ser visto no lado esquerdo da tela.release-log

As aprovações podem ser gerenciadas na guia Summary da conta do aprovador. Ao clicar em Approve or Reject, será aberta a janela para realizar a aprovação.

release-approval

Integração SonarQube com VSTS

1 Comment

Continuando o processo de CI (Continuous Integration) e CD (Continuous Delivery), o SonarQube é uma excelente ferramenta open source de análise de qualidade do código-fonte. Os times de desenvolvimento utilizam no processo de DevOps pipelines de integração contínua para inspecionar regularmente a qualidade dos Builds, entre eles, bugs, vulnerabilidades, code smells e code coverage.

A extensão do SonarQube pode ser instalada, acessando o Marketplace da Microsoft:

sonarqube-marketplace

Agora no VSTS, o primeiro passo é configurar o servidor SonarQube como um serviço endpoint do seu projeto. Acesse o Services no VSTS e escolha a opção + New Service Endpoint. Defina o nome da conexão e servidor de URL no SonarQube Server e o Authentication Token.

sonarqube-endpoint

A seguir devemos configurar a tarefa Prepare Analysis Configuration nas Definições de Build do VSTS. O nome do projeto, source e o servidor de endpoint do SonarQube são parametrizados nesta etapa.

sonarqube-vsts

E a análise do código pode ser acompanhada no servidor do SonarQube ou configurando o SonarCloud.

sonarqube

 

 

 

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

Backlog de Branch e Merge utilizando o VSTS – CI

Nos POSTs de Gerenciamento de código-fonte e Continuous integration, delivery and deployment apresentamos o processo de criação das linhas de Main | Dev | Release no gerenciamento de fontes, essenciais para trabalhar com Continuous Integration.

Continuando a abordagem de Integração Contínua, uma boa prática é gerenciar as atividades de Branch e Merge utilizando o board (Agile, Scrum ou CMMI) do VSTS. Assim, teremos o histórico e visibilidade das atividades que o o time de desenvolvimento realiza junto ao Configuration Manager.

Criando um novo projeto ou time no VSTS
Crie um novo projeto no VSTS, no exemplo abaixo utilizamos o nome DevOps, e escolha o template que irá trabalhar (Agile | Scrum | CMMI):

vsts-new-project* criamos um novo projeto, considerando que o Configuration Manager atende a todos os times do projeto na Sprint. Em cenários que o CM tenha apenas um time, o ideal é criar a um novo time no VSTS e assim distribuir as atividades de acordo com a alocação do CM no time de projeto.

Criando a estrutura de backlog
Em seguida, a nível da Requirement * (template CMMI), adicione duas novas: Solicitação de Merge e Solicitação de Branch para cadastrar as tarefas relacionadas.

vsts-pb-devops
* nível Product Backlog Item (em template Scrum) ou User Story (em template Agile)

Solicitando a Branch ou Merge
Com a estrutura criada, os desenvolvedores podem abrir uma nova tarefa (work item), solicitando a criação de Branch ou Merge.

branch-vsts

A solicitação (tarefa) deve conter as informações:

  • Nome do projeto que irá ser alterado (mesmo nome do repositório)
  • Tipo: Melhoria, Correção ou Emergencial
  • Encaminhada ao Configuration Manager
  • No campo “Iteration” deverá estar na Sprint corrente

work-item-branch-vsts

Pronto! Agora conseguimos gerenciar o backlog de Merge e Branch no VSTS, deixando o processo transparente para o time de desenvolvimento.

backlog-devops

 

DevOps – CI / CD – Continuous integration, delivery and deployment

10 Comments

 

Nesta abordagem sobre DevOps, vamos demonstrar os benefícios de trabalhar com o processo de CI (Continuous Integration – Integração Contínua), CD (Continuous Delivery – Entrega contínua) e CD (Continuous Deployment – Implantação contínua) no processo de desenvolvimento de sistemas da organização.

O primeiro ponto é entender o conceito e as diferenças entre os três processos:

Continuous Integration
É a integração contínua e testes de um novo código-fonte (branch ou trunk) ao principal (main), permitindo frequentes ajustes nos códigos e entregas rápidas – essenciais em equipes que trabalham com métodos ágeis. Desta forma, os desenvolvedores atuam em uma parte do código, solicitando uma branch para trabalhar em uma cópia completa do código, sem interferência no código principal main e de outros desenvolvedores.

O controle de versão entre o código da branch e da main mantém apenas as diferenças, consolidando os códigos. As ferramentas como GitHub (Java,PHP, etc.) e TFVC (.Net, etc.) são necessárias para garantir o processo de integração, versionamento e histórico das modificações.

A cada nova modificação – seu time pode definir a cadência a cada Work Item ou no final do expediente – o processo de Build e aplicação de testes unitários devem ser executados para validação e permitir uma rápida atuação em caso de bug. Lembrando que a boa prática é manter a esteira veloz para novas implementações ao invés de aplicar rollback de modificação. O MSBuild na Microsoft (.Net), Maven e Ant para Java são ferramentas recomendadas de Build. O VSTS da Microsoft possui uma área de Build/Release que traz análises deste processo:

A orquestração de todo o processo de CI – integração do código a main, execução dos builds e validação dos testes – exige o uso de ferramentas como Jenkins para validar e gerenciar as etapas, incluindo notificações para o time de desenvolvimento ter ciência da operação.

Continuous Delivery
Vai um passo além do CI. O objetivo do Continuous Delivery é garantir que novas modificações estejam disponíveis – validação em ambiente de Homolog ou QA – para serem implementadas no ambiente de produção. O deploy para produção não é automático, porém pode ser realizado a qualquer momento, dependendo do aceite da alteração.

O processo automatizado de testes e release contribuem com o controle de qualidade para prover feedbacks rápidos aos desenvolvedores. As ferramentas como o Test Manager (Microsoft), Selenium e Cucumber são utilizadas na automação dos testes. A infraestrutura e a gestão dos ambientes para realização de Build, Release e Deploy (Desenvolvimento | Homologação | QA | Produção) são essenciais para o sucesso do DevOps. A IaC (Infrastructure as code) é o processo que permite gerenciar e provisionar estes ambientes aos times ágeis.

Continuous Deployment
Processo sem intervenção humana, realizando todas as validações anteriores para disponibilizar a nova modificação em produção automaticamente. Somente uma falha encontrada nos testes impede a implementação em produção.

Neste processo é muito importante validar com a área de segurança da informação e compliance da sua empresa a aplicabilidade deste processo. Em operações críticas que trabalham com deploys contínuos (dezenas, centenas ou milhares por dia), torna-se inviável gerenciar este processo sem ter a implantação do Continuous Deployment.


Benefícios

  • Redução de bugs em produção – regressões são capturas previamente
  • Facilidade na integração das releases e gestão de Builds
  • Custo de teste reduz drasticamente devido a capacidade de execução do servidor CI
  • Times QA perdem menos tempo com testes e focam em melhoria da qualidade
  • Garantir o processo de entregas contínuas, acelerando o feedback com os clientes
  • Menor risco na implantação de releases, devido a facilidade de encontrar erros e aplicar correção

 

Bom, e minha última contribuição para direcionar a prática de DevOps em sua organização, compartilho um diagrama com as ferramentas que irão auxiliar na implantação de CI e CD, além da gestão de atividades e ciclo de vida do desenvolvimento de aplicações. Vale a pena ponderar a aplicabilidade e tecnologias que sua empresa já utiliza para findar o modelo adequado para o seu negócio.

devops

 

Referências
https://www.code-maze.com/what-is-continuous-integration/
https://www.atlassian.com/continuous-delivery/ci-vs-ci-vs-cd