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:
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:
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:
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).
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
Os componentes principais da arquitetura do projeto de exemplo são os seguintes:
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
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
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
As tarefas de Build do projeto de exemplo são as seguintes:
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.
Nós utilizamos o MSTest para testes unitários automatizados, framework padrão para automação de testes da Microsoft.
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.
[caption id="attachment_153" align="aligncenter" width="248"]
Figura 6 – Relatório obtido com a execução dos testes unitários – Parte 1[/caption]
As seguintes métricas são apresentadas como resultado da execução dos testes no Build do VSTS:
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!
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.
[caption id="attachment_155" align="alignnone" width="562"]
Figura 8 – Migrando o código para o Ambiente de Homologação[/caption]
[caption id="attachment_156" align="alignnone" width="563"]
Figura 9 – Migrando o código para o Ambiente de Produção[/caption]As tarefas para deploy da aplicação nos Ambientes de Homologação e Produção são as seguintes:
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:
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.
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:
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.
Nenhum comentário aprovado.
Deixe um comentário