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:

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:

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.

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.