Implemente DevOps em 7 passos usando o VSTS e Azure

ProMoveDevOpsImplemente DevOps em 7 passos usando o VSTS e Azure
Implementando DevOps com VSTS e Azure

O desejo de automação em processos é bastante antigo. Muitas empresas sonham com o dia em que todo o ciclo de desenvolvimento e sustentação de sistemas seja totalmente automatizado. E o DevOps é uma ferramenta que faz isso acontecer.

Este sonho já é realidade de muitas empresas no mundo todo.

O relatório de 2017 sobre a adoção de DevOps publicado pelas empresas Puppet e DORA, mostram que, no último ano, houve um crescimento de 27% do uso de DevOps nas equipes mundialmente.

Acreditamos que DevOps deixou de ser tendência e passou a ser um fator de competitividade das empresas.

Porém, apesar do crescimento em DevOps, muitas empresas ainda têm dificuldades em mudar a sua forma tradicional de desenvolvimento para uma forma mais ágil com processos automatizados.

Podemos citar algumas barreiras encontradas na adoção de DevOps:

  • Cultura da empresa.
  • Desafios de testes de automação.
  • Sistemas legados.
  • Complexidade da aplicação.
  • Restrições de orçamento.
  • Dificuldade em gerenciar vários ambientes.
  • Competências de TI limitadas.
  • Limitações orçamentárias.
  • Crescimento da cadeia de ferramentas.
  • A falta de apoio da alta direção.

Neste post, apresentamos 7 passos para ajudar você a superar essas barreiras e implementar na prática uma infraestrutura de DevOps usando o Visual Studio Team Service (VSTS) da Microsoft:

  1. Definir os componentes da infraestrutura de apoio com base no VSTS
  2. Definir a solução do projeto utilizando a infraestrutura integrada com o repositório de código
  3. Definir o build automático na ferramenta de deploy automático
  4. Criar scripts para execução de testes automatizados unitários
  5. Criar scripts para migração de código entre os ambientes
  6. Atualizar automaticamente a estrutura do banco de dados em cada ambiente
  7. Instanciar software de gerência de desempenho de aplicações do sistema

O que é DevOps?

Antes de detalhar cada um dos passos para implementação da infraestrutura de DevOps, vamos explicar o que DevOps significa na prática.

O conceito surgiu quando John Allspaw e Paul Hammond introduziram os termos Dev & Ops na sua famosa palestra em 2009.

Iniciou-se, então, um grande movimento liderado por Patrick Debois que organizou em 2009 o primeiro evento focado em DevOps, chamado de DevOpsDays.

Nos anos seguintes, o evento ganhou projeção internacional e vem sendo realizado regularmente em diversas cidades do mundo. No Brasil, o último DevOpsDays aconteceu em Novembro de 2016 na cidade de Brasília/DF.

DevOps é uma cultura centrada em 4 eixos que pode ser resumida no acrônimo CAMS:

  • Cultura
    • Colaboração
    • Fim das divisões
    • Relação saudável entre as áreas
    • Mudança de comportamento
  • Automação
    • Deploy
    • Controle
    • Monitoração
    • Gerência de configuração
    • Orquestração
  • Metric (Avaliação)
    • Métricas
    • Medições
    • Performance
    • Logs e integração
  • Sharing (Compartilhamento)
    • O feedback é tudo
    • Boa comunicação entre a equipe

Vemos, então, que automação é apenas um dos eixos de DevOps.

Os outros eixos são também muito importantes para que ocorra a transformação na forma como as equipes desenvolvem e entregam software para seus clientes.

O eixo da Cultura trata questões relacionadas à forma como as equipes são estruturadas e se relacionam. O eixo Avaliação (Metric) aborda práticas relacionadas à monitoração do desempenho da aplicação.

E o eixo Compartilhamento (Sharing) busca facilitar a comunicação entre os times.

Nas próximas seções, irei usar um projeto de exemplo no detalhamento dos 7 passos para implementar uma infraestrutura de DevOps com foco nos eixos Automação e Avaliação (Metric).

Passo 1: Use o Visual Studio Team Services (VSTS) como infraestrutura de apoio

O Visual Studio Team Services (VSTS) é uma plataforma para suporte a ALM (Application Lifecycle Management) baseada em nuvem para gestão de aplicações, código-fonte, qualidade, deploy automático, entre outras funções.

A arquitetura do nosso projeto de exemplo foi construída usando o VSTS, mas poderia muito bem ter sido usado o TFS on-premises.

As organizações geralmente escolhem o TFS on-premises quando precisam que seus dados fiquem dentro da sua rede, ou eles querem acessar sites do SharePoint e serviços de relatórios do SQL Server que se integram com os dados e ferramentas do TFS.

Veja aqui uma análise comparativa do VSTS e TFS.

A arquitetura .Net é fundamentada em diversos componentes que integrados fornecem um grande ganho de qualidade e produtividade para equipes de desenvolvimento ágil e entrega de valor para o cliente.

A arquitetura .Net pode ser estruturada de diversas formas. As outras formas de estruturação serão tema de outros posts que irei tratar em breve.

A arquitetura que utilizamos para o projeto de exemplo é apresentada na Figura 1.

Figura 1 - Arquitetura do projeto de exemplo com Visual Studio 2017, Visual Studio Team Services, Release Server Management, Git e Azure
Figura 1 – Arquitetura do projeto de exemplo com Visual Studio 2017, Visual Studio Team Services, Release Server Management, Git e Azure

Os componentes principais da arquitetura do projeto de exemplo são os seguintes:

  • Visual Studio 2017 – Ambiente de desenvolvimento para aplicações Web, Mobile e C#.
  • Git – Ferramenta open source de gerência de configuração distribuída totalmente integrada ao VSTS
  • Build & continuous integration – Ferramenta de compilação do código.
  • Release Management (RM) – Ferramenta de migração de código e execução de tarefas de deploy entre os ambientes de homologação e produção instanciados para o projeto de exemplo.
  • Microsoft Azure – É o serviço de nuvem oferecido pela Microsoft.
  • QA – Um ambiente de Homologação no Azure instanciado para o projeto de exemplo.
  • Prod – Um ambiente de Produção no Azure instanciado para o projeto de exemplo.
  • Application Insights – Ferramenta de gerência de desempenho de aplicações do sistema instalado no Azure que recebe informações a respeito do desempenho das aplicações Web.

Passo 2: Defina a solução do projeto no MS Visual Studio 2017 integrado ao repositório de código Git

Foi utilizado como template para o projeto de exemplo, o projeto Contact Manager implementado em C#, utilizando MVC e acessando um banco de dados SQL Server.

Foi criado um repositório Git no próprio VSTS para armazenar o código-fonte e gerenciar as tarefas do projeto de exemplo.

A Figura 2 apresenta a tela do repositório Git do projeto de exemplo.

Figura 2 - Repositório Git criado no VSTS criado para armazenar o projeto Contact Manager
Figura 2 – Repositório Git criado no VSTS criado para armazenar o projeto Contact Manager

Passo 3: Execute o Build integrado ao VSTS

O Build consiste de um módulo pertencente ao VSTS em que a execução do conceito de integração contínua ocorre a cada check in/commit realizado no código pelo desenvolvedor, conforme a figura 3.

A arquitetura do Build será explicada com mais detalhes em um próximo post. Aguardem!

Figura 3 - Definição do Build associado ao repositório de código do projeto de exemplo
Figura 3 – Definição do Build associado ao repositório de código do projeto de exemplo

Em linhas gerais, a cada check in/commit realizado no código, são executadas automaticamente uma sequência de tarefas de Build associadas.

A Figura 4 apresenta a tela de configuração dessas tarefas de Build no projeto de exemplo.

Figura 4 - Lista de Tarefas definidas para o Build do projeto de exemplo
Figura 4 – Lista de Tarefas definidas para o Build do projeto de exemplo

As tarefas de Build do projeto de exemplo são as seguintes:

  • Tarefa GetSources – Recupera o código do projeto de exemplo do Git para o servidor de Build do VSTS.
  • Tarefa NuGet restore – Recupera todas as referências dos projetos instalados no repositório do Nuget.
  • Build solution – Compila todo o código associado ao projeto de exemplo gerando as DLLs associadas.
  • Tarefa Test Assemblies – Executa todos os projetos de testes unitários associados ao projeto de exemplo que possua a string “test” no seu nome. O TDD é executado nesta tarefa.
  • Copy File to: – Copia as DLLs geradas para uma área intermediária conhecida como artifact stage. Utilizada normalmente para projetos Web.
  • Copy and Publish Artifact: webdeploypackage  – Copia o arquivo da área de artifact stage para criar um artefato definido no servidor de Build do VSTS com o nome webdeploypackage. Esta tarefa é necessária para a migração do código compilado nos ambientes de homologação e produção.

Passo 4: Executando os Testes Unitários Automatizados

O primeiro passo para introduzir qualidade no processo de desenvolvimento é automatizar testes unitários.

A automação de testes unitários é pré-requisito para automatizar outros níveis de testes, como por exemplo, testes funcionais com Selenium, testes de desempenho com JMeter e testes de aceitação do usuário com SpecFLow.

Nos próximos posts, iremos discutir como fazer cada uma dessas automações. Fique ligado!

Após a execução do Build, devem ser executados os testes unitários automatizados, também conhecidos como (Test Driven Development – TDD), conforme a figura 5.

Figura 5 - Executando testes unitários automatizados.
Figura 5 – Executando testes unitários automatizados.

Nós utilizamos o MSTest para testes unitários automatizados, framework padrão para automação de testes da Microsoft.

Powered by Rock Convert

Caso fosse usado o NUnit, a tarefa seria definida da mesma forma, pois existe compatibilidade total com o Build do VSTS.

O VSTS gera uma seção específica para apresentação de métricas a respeito da execução dos testes unitários, conforme a figura 6.

 

Figura 6 - Relatório obtido com a execução dos testes unitários - Parte 1
Figura 6 – Relatório obtido com a execução dos testes unitários – Parte 1

 

As seguintes métricas são apresentadas como resultado da execução dos testes no Build do VSTS:

  • Total de casos de testes unitários executados (Total Tests)
  • Total de casos de testes unitários executado com sucesso (Passed)
  • Total de casos de testes unitários com falha (Failed)
  • Total de casos de testes nunca executados que falharam (New)
  • Total de casos de testes existentes que falharam (Existing)
  • Percentual de casos de testes executados com sucesso (Pass percentage)
  • Tempo de execução dos casos de testes unitários (Run duration)
  • Quantidade de falhas considerando os últimos 10 testes executados (Test failures)
  • Tempo de duração dos últimos 10 testes (Test duration)

Uma vez que todos os testes unitários automatizados forem executados com sucesso no ambiente de desenvolvimento, uma release é gerada no ambiente de homologação para serem executados os testes funcionais.

Após execução com sucesso dos testes funcionais, nosso aplicativo está pronto para ir Live no ambiente de produção!

Passo 5: Migrando o código entre o ambiente de homologação e o ambiente de produção

Na Figura 7, são apresentados os 3 ambientes integrados que fazem parte da arquitetura de infraestrutura do projeto de exemplo: Ambiente de Desenvolvimento (DSV), Ambiente de Homologação (QA) e Ambiente de Produção (PROD).

FIgura 7 – Migração de códigos entre os ambientes do projeto exemplo Contact Manager.

O Ambiente de Desenvolvimento (DSV) é constituído pelos recursos de hardware e software utilizados pelo desenvolvedor (notebook pessoal, Visual Studio, IIS local, SQL Express local, etc).

No Ambiente de Build, é compilado o código que está no trunk e são executados os testes unitários automatizados.

O Ambiente de Homologação (QA) é onde serão executados automaticamente os testes funcionais e de aceitação do usuário.

E o Ambiente de Produção (PROD) fornece acesso externo ao sistema.

As Figuras 8 e 9 apresentam a definição do grupo de tarefas para o deploy da aplicação nos Ambientes de Homologação e Produção.

Figura 8 – Migrando o código para o Ambiente de Homologação
Figura 9 – Migrando o código para o Ambiente de Produção

As tarefas para deploy da aplicação nos Ambientes de Homologação e Produção são as seguintes:

  • Tokenizer: Transform Source filename – Altera o arquivo de SetParameters.xml com as variáveis de Connection String e o nome da URL da aplicação definidas para cada ambiente. Permite a geração do web.config com esses novos parâmetros. A extensão está disponível no Marketplace do VSTS.
  • Azure App Service Deploy – Executa a instalação da aplicação web no container App service definido no Azure. A task é nativa do VSTS.
  • Task Group: Deploy migration – Grupo de tarefas criado para a reutilziação dos passos do migration para os ambientes de  homologação e produção.

Passo 6: Atualizando automaticamente a estrutura do banco de dados em cada ambiente

No projeto de exemplo, utilizamos o framework de persistência Entity Framework com a estratégia code-first, considerando a criação dos atributos das classes para a posterior geração das tabelas no banco de dados.

No nosso exemplo, acrescentados novos campos à uma classe do modelo.

Baseado na estratégia do CodeFirst, criamos os campos na classe do modelo e geramos o arquivo de migração que será utilizado para o migration.

A outra estratégia possível é o DatabaseFirst, que consiste na geração do banco de dados para posterior criação automática das classes de domínio.

Para cada ambiente, foram geradas as seguintes tarefas:

  • Tarefa Copy Files to: DLLs do Entity Framework – Copia as DLLs fornecidas pela Entity Framework  para a execução do migration
  • Tarefa Copy Files to: DLLs do ContactManager – Copia as DLLs do projeto Contact Manager resultantes da tarefa de Build Solution.
  • Tarefa Copy Files to: Arquivos do Migration – Copia os arquivos gerados pelo comando Add-Migration do Entity Framework.
  • PowerShell Script: Executando Migration – Executa o comando migrate.exe para atualização do banco de dados de acordo com o arquivo gerado pelo Add-Migration.

Passo 7: Utilizando o Application Insight para Monitorar o desempenho da aplicação

Mas a infraestrutura de DevOps não acaba quando a aplicação entra em produção.

A cadeia de valor do projeto de desenvolvimento com DevOps segue durante a operação do produto.

Este é um dos grandes diferenciais da cultura DevOps com relação à forma tradicional de desenvolvimento: a equipe é continuamente responsável pela qualidade do software entregue ao usuário final.

Assim, é responsabilidade do time de DevOps monitorar a performance da aplicação, identificar e analisar melhorias visando manter as aplicações totalmente operantes de forma rápida e estável.

Um pesquisa da Aberdeen apontou que o monitoramento de aplicação é capaz de antecipar 53% dos problemas de aplicações antes de receber uma reclamação.

Além disso, o tempo de correções nas falhas de desempenho pode melhorar em 48% e o número total de reclamações dos usuários pode ser reduzido em até 15%.

A Figura 10 apresenta o Painel de Controle do Azure para o monitoramento da aplicação do nosso projeto de exemplo.

Figura 10 – Tela para diagnosticar e resolver problemas na monitoração de aplicações do Azure

O primeiro painel descreve o % de de disponibilidade do container App Service do projeto exemplo.

O segundo painel lista todas as paradas da aplicação nas últimas 24 horas. Existem centenas de métricas para monitoramento de aplicações no Application Insights, que serão tema de outro post.

Quais os Ganhos com DevOps?

O relatório de 2017 sobre o estado de DevOps no mundo apresenta dados dos benefícios alcançados pelas empresas para aumentar a performance das equipes de TI.

Esse estudo apontou que equipes de TI de alto desempenho têm uma melhor performance conforme a seguir:

  • Implantações de código 46 vezes mais freqüentes.
  • Tempo de execução 440 vezes mais rápido de commit para deploy.
  • Tempo médio 96 vezes mais rápido para recuperar do tempo de inatividade.
  • Taxa de falha de alteração 5 vezes menor (mudanças com 20% de probabilidade de falhar).

Além disso, o estudo também identificou que as organizações de alto desempenho gastam 21 por cento menos tempo no trabalho não planejado e retrabalho, e 44 por cento mais de tempo em novos trabalhos.

Na nossa experiência, percebemos que a cultura de DevOps ajuda a diminuir a dependência de pessoas, além de eliminar a necessidade de manuais complexos para execução de tarefas de infraestrutura como migração, atualização de versões, entre outras.

A motivação da equipe também aumentou com a implementação de DevOps nos nossos projetos, eliminando tarefas manuais e repetitivas.

O aumento da velocidade de entrega de novas funcionalidades também ajudou a aumentar a satisfação dos usuários das aplicações.

Apesar de DevOps trazer muitos benefícios, a implantação de cultura de DevOps requer uma grande dedicação do time de desenvolvimento e infraestrutura.

O sucesso de uma iniciativa de DevOps na organização depende de um bom planejamento do projeto com priorização de ações com foco em metas claras e tangíveis.

E aí? Conseguiu conhecer bem essa metodologia? Entre em contato para saber como a ProMove pode ajudar a sua empresa na implementação da cultura de DevOps.

About the author

Mestre em Engenharia de Sistemas e Computação na COPPE/UFRJ. Trabalha com avaliação e melhoria de processo de software desde 2004. Foi responsável pela definição e implantação da infraestrutura, customização do processo, treinamento e administração do TFS 2010 na APPAI. Responsável pela migração de todo o ambiente para a versão TFS 2015, com a adaptação do processo para as novas funcionalidades do TFS 2015. Implantação do deploy automático e testes automatizados unitários e funcionais utilizando o TFS 2017, incluindo todos os sistemas core da arquitetura da APPAI. Responsável pela definição, customização, treinamento do processo e administração do TFS 2012 no Banco Modal.