Tag: Release

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

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.