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.
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.
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).
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 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
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, Um exemplo é o teste funcional com Selenium. Outro é o teste de desempenho com JMeter. E ainda o teste de aceitação do usuário com SpecFLow.
Nos próximos posts, iremos discutir como fazer cada uma dessas automações. Fique ligado!

Figura 5 – Executando testes unitários automatizados.
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
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.
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:
No projeto de exemplo, utilizamos o framework de persistência Entity Framework. Adotamos 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.
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.
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.
Em 11 de março de 2026, Vasilios Syrakis recebeu o e-mail que muitos engenheiros sênior têm recebido: oito anos na Atlassian, infraestru...
Seja o primeiro a comentar!