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

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.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

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 smellscode 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

 

 

 

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

 

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 trunkao 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