Maturidade DevOps – Pessoas e Robôs colaborando juntos com o ChatOps

Já discutimos nesta série três dimensões da maturidade DevOps.

Iremos agora discutir um aspecto primordial na cultura DevOps, que é o aumento da comunicação e colaboração. Curiosamente, são agora os robôs (ou bots) que vem ao nosso alcance aqui para ajudar times a manter o compasso da comunicação.

Conheça o ChatOps

O ChatOps é a prática do desenvolvimento e operação orientado por conversações. Ao trazer suas ferramentas para suas conversas e usar um bot de bate-papo modificado para trabalhar com plug-ins e scripts, as equipes de desenvolvimento podem automatizar tarefas e colaborar, trabalhando melhor, mais barato e mais rápido.

Ou seja, enquanto estiver em uma sala de bate-papo, os membros da equipe podem digitar comandos que o bot do chat está configurado para executar scripts personalizados e plugins, tais como o disparo de build ou a promoção de código para um ambiente de homologação. Isto é, toda a equipe colabora em tempo real à medida que os comandos são executados.

A figura abaixo exemplifica a arquitetura básica de uma infraestrutura ChatOps.

chatops-fundamental-architecture

Da mesma forma, as ferramentas como o GitHub, Jira, Trello, VSTS, Jenkins, Puppet, entre outras, também podem ser configuradas para gerarem eventos de conversação dos bots. E com isso as ferramentas “avisam” os seres humanos sobre eventos importantes que devam ser monitorados.

Existem muitas ferramentas para realizarmos ChatOps, como por exemplo o HipChat, Flowdock e o  Campfire. Cito aqui o Slack como exemplo, ferramenta para chat entre seres humanos e robôs. Você pode imaginar ao usá-la que ela é similar ao Skype ou GoogleTalk, mas ela vai muito além. Por contar das integrações diversas com muitas ferramentas, ela permite  que times interajam com ela através de comandos para enviar ou receber notificações de ferramentas como o VSTS, Docker, Ansible ou Puppet.  Um exemplo simplista é mostrado na figura abaixo.

15-slash-command-example

E existe também a possibilidade de você integrar qualquer ferramenta nativa que possua na sua empresa através de ferramentas para o desenvolvimento de ChatOps. Um artigo com 12 frameworks da Nordic API fornece algumas boas opções para isso.

Um Modelo de Maturidade para Automação da Comunicação

Com esta definição de ChatOps, vamos caminhar em direção a um modelo de maturidade de infraestrutura como código

  1. Maturidade 1 – Inicial – Aqui não existe automação da comunicação. As ferramentas operam de forma silenciosa e também não aceitam comandos através de ferramentas de linha de comando e ferramentas de chats. O conceito de bots é desconhecido ou ignorado pelos times.
  2. Maturidade 2 – Consciente –  Aqui os primeiros experimentos de automação começam a acontecer. Neste nível, o time começa a usar integradores de uso trivial como IFTTT e o Zapier para fazer ferramentas como o Trello e JIRA conversarem com ferramentas de chats como o Slack ou HipChat.
  3. Maturidade 3 – Gerenciado – Aqui a automação da conversação ganha escala e existe forte comunicação das ferramentas de ciclo de vida com as ferramentas de chat nos pontos críticos dos processos. Além disso, os times começam a experimentar também o envio de comandos automatizados nas ferramentas de Chats para disparar processos automatizados de build, release e operação, entre outros. É esperado neste nível que todo o time de desenvolvimento passe a usar esta infraestrutura de comunicação.
  4. Maturidade 4 – Avançado – Neste nível, todo o ciclo de vida do desenvolvimento e operação de um produto está automatizado por conversações, seja dos humanos para as ferramentas quanto vice-versa. Neste nível, até produtos nativos foram personalizados e integrados na automação da comunicação com frameworks ChatOps. Aqui as equipes de infraestrutura também se sentem confortáveis para usar esta abordagem de comunicação.
  5. Maturidade 5 – Melhoria Contínua – Aqui existe excelência na comunicação entre humanos e máquinas e a sintaxe dos comandos é estendida para suportar conversações mais sofisticadas, até mesmo com uso de recursos de processamento de linguagem natural (NLP). O processo é continuamente aperfeiçoado e todo o time participa do processo do enriquecimento da aplicação. Os times de desenvolvimento e operações controlam o seu ambiente de forma muito mais ágil que times convencionais.

 

Recursos de Aprendizado

Alguns livros a respeito são indicados abaixo. O primeiro é uma introdução leve ao tema para os mais apressados. O segundo dá um tratamento um pouco mais extenso ao tema e o terceiro trata de aspectos mais avançados para aqueles que precisam criar e manter bots.

captura-de-tela-2016-12-19-as-19-42-46         captura-de-tela-2016-12-19-as-19-41-49

captura-de-tela-2016-12-19-as-19-35-38

O segundo livro está temporariamente disponível para download a partir do seguinte sítio.

Finalmente, recomendo também este vídeo de 36 minutos que conta a história do ChatOps no GitHub, organização que originalmente cunhou este termo.


E você, já conversou com um robô? Compartilhe aqui as suas experiência com ChatOps no mundo DevOps.

captura-de-tela-2016-12-19-as-19-45-47

 

Maturidade DevOps – Infraestrutura como Código

Conversando com uma pessoa que trabalha em uma grande empresa pública há alguns meses, ouvi o seguinte relato.

“Meu time precisava de um ambiente para a homologação do nosso produto, que já estava com um atraso considerável. Entretanto, ouvi da nossa infraestrutura que a requisição do ambiente de homologação demoraria algumas semanas. A partir deste momento, toda uma cadeia de estresses se estabeleceu de lado a lado, com pressões diversas de pessoas do desenvolvimento e respostas áridas do time de operações. E no final das contas, o nosso time precisou esperar 3 semanas para ter um ambiente liberado. E isso somente tornou o nosso projeto, que já estava ruim, em um pesadelo vivo”, – Gestor Irritado com a sua infraestrutura do século XX

Por mais estranha que esta história pareça, ela é ainda comum nas empresas que visito e nas empresas de meus colegas de TI. E, sim, algo está errado com isso. Com os avanços das últimas duas décadas nas tecnologias de virtualização e conteinerização, a engenharia de automação de infraestrutura pode emergir como uma disciplina.

Infraestrutura Programável

A Infraestrutura como código, ou infraestrutura programável, significa escrever código (que pode ser feito usando um linguagem de alto nível ou qualquer linguagem descritiva) para gerenciar configurações e automatizar o provisionamento da infraestrutura e implantações. Isso não é simplesmente escrever um scripts que sobe e roda uma máquina virtual, mas envolve também o uso de práticas de desenvolvimento de software testadas e comprovadas que já estão sendo usadas no desenvolvimento de aplicativos. Em suma, isso significa que você escreve código para provisionar e gerenciar seu servidor, além de automatizar processos que rodam neste servidor.

Observe o seguinte código abaixo, que pode ser executado no Windows, Linux ou Mac OS/X com uma ferramenta de provisionamento chamada Ansible.

- hosts: server
  sudo: yes
  sudo_user: root

  tasks:

  - name: Instala mysql-server
    apt: name=mysql-server state=present update_cache=yes

  - name: Instala dependencias
    apt: name=python-mysqldb state=present

  - name: Verifica se o mysql está rodando 
    service: name=mysql state=started

  - name: Criar usuario com os privilegios apropriados
    mysql_user: login_user=root login_password="" name={{ mysql_user }} password={{ mysql_password }} priv=*.*:ALL host=% state=present

  - name: Create base de dados AloMundo
    mysql_db: name=alo_mundo state=present

  - name: Copia o dump do SQL para a máquina remota
    copy: src=dumpAloMundo.sql.bz2 dest=/tmp

  - name: Restaura o dump no banco de dados AloMundo
    mysql_db: name=alo_mundo state=import target=/tmp/dump.sql.bz2

Este script (chamado de PlayBook no Ansible) instala o mysql-server na máquina remota (servidor), garante que o mysql está em execução, cria um usuário com a senha, cria o banco de dados alo_mundo, copia um dump sql para a máquina remota e o restaura no banco de dados destino.

Considere agora este exemplo, com o uso da ferramenta Docker.

  
docker pull microsoft/mssql-server-2016-express-window
docker run -d -p 1433:1433 
        -- env sa_password=senha 
        -- isolation=hyperv microsoft/mssql-server-2016-express-windows

Este script baixa um contêiner Docker de um ambiente remoto com um Windows e Microsoft SQL Server e o roda na porta 1433. E este contêiner pode ser rodado em um sistema operacional nativo diferente.

Observe que nos scripts acima você pode eliminar muito trabalho manual e permitir que o provisionamento de ambientes, instalação de softwares, configurações destes software e disparo de servidores seja todo automatizado em scripts.

Nos ambientes mais sistematizados e que requerem práticas ITIL podemos manter toda a governança necessária para o controle da infraestrutura. Ao mesmo tempo, eliminaremos o tedioso e lento trabalho manual que gera filas, atrasos e estresses para os times de TI.

Com esta definição em mãos, vamos caminhar em direção a um modelo de maturidade de infraestrutura como código

  1. Maturidade 1 – Inicial – Aqui não existe uma cultura de configuração e uso de scripts de provisionamento de ambientes. Todo o trabalho de preparação de ambientes é realizado diretamente sobre hardwares reais e isso é sempre repetido para cada nova requisição realizada para o time de infraestrutura. Nesta maturidade, os tempos de atendimento são longos e existe estresse frequente entre o time de desenvolvimento e o time de operações.
  2. Maturidade 2 – Consciente –  Aqui a cultura de virtualização começa a ser experimentada. Os times de operações adotam tecnologias como o Oracle VirtualBox, VMWare, Windows Hypervisor e similares para facilitar o trabalho de criação e configuração das máquinas. Alguns trabalhos são operacionalizados com scripts, mas o trabalho manual é ainda dominante e ainda gera tempos altos de atendimento das requisições.
  3. Maturidade 3 – Gerenciado – Aqui entram em cena ferramentas como Docker, Ansible e Puppet para tornar o trabalho de provisionamento, instalação e configuração de ambientes totalmente automatizados. Os scripts de provisionamento começam a ser escritos e organizados em repositórios de código. Com isso o atendimento de requisições de criação de ambientes é facilitado com tempos de atendimento reduzidos.
  4. Maturidade 4 – Avançado – Neste nível, os scripts são governados e podem ser distribuídos para os times de desenvolvimento para estabelecer ambientes self-service. Temos também o provisionamento dos ambientes de produção (Release Management) completamente controlados por máquinas e com mínima interferência humana. Para isso, são estabelecidos ambientes de nuvens privadas ou públicas para facilitar a implementação de políticas de escalabilidade e alocação de recursos em modelos de pagamento pelo uso. O efeito na redução do trabalho manual nos times de operações é notável.
  5. Maturidade 5 – Melhoria Contínua – Neste nível praticamente todo o trabalho de infraestrutura é gerido por código fonte e ferramentas de provisionamento. Máquinas virtuais, bancos de dados, servidores de aplicação, servidores Web e até mesmo redes (SDN) são configuradas por código fonte. O “hardware” se torna software.

 

Recursos de Aprendizado

Para quem nunca teve contato com a prática da InfraEstrutura como Código, isto pode parecer ficção. Felizmente, esta prática já é realidade em muitas empresas do Brasil. E ela pode ser operacionalizada por ferramentas gratuitas também, na sua empresa inclusive.

Deixo aqui alguns livros a respeito para o interessado em melhorar a gestão da sua infraestrutura e trazê-la para o século XXI. O primeiro explica a prática do IaC em detalhes os três outros livros apresenta ferramentas muito legais para operacionalizar esta prática.

51kktpbssjl    51otkrbt71l-_sx356_bo1204203200_

51piynh5ppl    51mweljjc4l


E como está a prática da infraestrutura na sua empresa? Já no século XXI ou ainda preso em algum túnel do tempo no século XX?

Se você não leu os dois primeiros artigos desta séria de Maturidade DevOps, deixo aqui os links:

Parte 1 – Maturidade DevOps – Qualidade de Código
Parte 2 – Maturidade DevOps – Gestão de Builds e Integração Contínua

 

Maturidade em Práticas DevOps

O termo DevOps se refere a uma coleção de práticas de engenharia de software e  infraestrutura para habilitar times de desenvolvimento, qualidade e operações a entregar e manter software com maior velocidade, qualidade e robustez. Ao mesmo tempo, pode parecer difícil começar uma iniciativa DevOps.  Por onde começar?  Quem devemos envolver? E o que fazer primeiro?

Embora possam existir muitas respostas (corretas e incorretas) para as perguntas acima, uma verdade universal é que isso depende do contexto e maturidade de cada time que esteja implementando as práticas DevOps.

Uma abordagem útil é a realização de um diagnóstico de maturidade em práticas DevOps, que  permite revelar:

  • Quais os pontos fracos e fortes ao longo de cada prática DevOps;
  • Quais as lacunas existentes frente a objetivos estratégicos das áreas de desenvolvimento e operações;
  • Benchmarks de referências entre times, áreas ou organizações;
  • Expectativas com o corpo gestor e diretor da organização;
  • Balizar a empresa para uma futura iniciativa de aumento de maturidade DevOps

Práticas DevOps

Não devemos pensar no DevOps como um movimento binário, mas como uma coleção de práticas básicas e avançadas, cada qual com uma escala de maturidade. Por exemplo, a prática da Qualidade de Código pode ser avaliada isoladamente dentro de um modelo de maturidade.

Como existem diversas práticas DevOps, uma visão simples para avaliar maturidade global ao longo dessas práticas é o uso de um gráfico radial, conforme mostrado na figura abaixo para duas empresas fictícias ABC e XYZ.

captura-de-tela-2016-12-13-as-00-00-32

Cada prática possui um valor entre 1 e 5, que pode ser descrita universalmente da seguinte forma:

  • Maturidade 1 – Inicial – Ausência da prática ou iniciativas ad hoc realizadas isoladamente por algumas pessoas.
  • Maturidade 2 – Consciente –  Prática embrionária no time ou organização. Resultados iniciais e ainda inconsistentes.
  • Maturidade 3 – Gerenciado –  Prática sistematizada pelo time ou organização. Resultados de negócio começam a se tornar visíveis pelo corpo gestor.
  • Maturidade 4 – Avançado –  Prática otimizada pelo time e que se torna parte da cultura da organização. Resultados de negócio sempre visíveis pelo corpo gestor.
  • Maturidade 5 – Melhoria Contínua – Prática em melhoria contínua. Time possui excelência na realização da prática, que foi complementarmente assimilada na cultura da organização.

Um exemplo de avaliação de maturidade –  Prática de Qualidade de Código

Vamos considerar a prática de qualidade de código e colocá-la nesta escala.

  • Maturidade 1 – Inicial – Aqui o time não possui padrões de codificação. O código não é limpo e os codificadores não são limpos. As consequências são funções e métodos com centenas ou milhares de linhas de código, acoplamento excessivo de código, variáveis globais em excesso, códigos duplicados, alta complexidade ciclomática e muitos outros code smells documentados na literatura.
  • Maturidade 2 – Consciente –  Aqui o time possui um padrão estabelecido de codificação. Provavelmente todos já personalizaram este padrão nos seus ambientes (Eclipse, Visual Studio, Web Storm) e usam suas IDEs para garantir conformidade ao padrão. Provavelmente existe também o conceito de revisão por pares para garantir que a cultura do padrão seja seguida na organização. O conceito de débito técnico começa a ser estabelecido.
  • Maturidade 3 – Gerenciado –  Neste nível a revisão por pares começa a ser automatizada, como por exemplo pelo uso de Pull Requests em ferramentas como o Git. Além disso, a liderança técnica do time programa robôs de integração noturna para verificar a qualidade do código e publicar painéis de qualidade contínua. Ferramentas como o SonarQube ou similares começam a ser usadas para comunicar os problemas de forma executiva e gerenciável e monitorar o débito técnico.
  • Maturidade 4 – Avançado –  Aqui o time incorpora atributos não-funcionais como segurança, performance, internacionalização ou acessibilidade na sua avaliação de código. Os relatórios de qualidade são contínuos e com excelente amplitude dos aspectos funcionais e não-funcionais. O uso de ferramentas de qualidade se torna prática comum e desenvolvedores estabelecem “competições do bem” para premiar os desenvolvedores mais limpos.
  • Maturidade 5 – Melhoria Contínua – A prática aqui ganha excelência e o nível é tão avançado que ela pode ser incorporada aos commits de código pelo padrão de SCM Gated Commit. Atém disso, os times aceitam e resolvem os problemas em base diária o débito técnico é pequeno ou é reduzido progressivamente ao longo do tempo.

Recursos de Aprendizado de Qualidade de Código

Se faz sentido para você e o seu time melhorar a qualidade de código no seu time, recomendamos alguns livros clássicos a respeito.

51evx6wfynl     41cqy3lxbwl

captura-de-tela-2016-12-13-as-09-48-2251alcwaoayl-_sx352_bo1204203200_

E se você ainda não tem acesso a estes livros, deixamos aqui alguns sítios com conteúdo de muito valor sobre o tema:


Iremos, ao longo de sete outros posts, descrever como avaliar a sua maturidade para as seguintes práticas:

  • Configuração como código (Infraestrutura como Código)
  • Gestão de Builds (Continuous Integration)
  • Gestão de Releases (Continuous Delivery)
  • Gestão de Testes
  • Testes de Carga, Estresse e Injeção de Falhas
  • Gestão de Configuração
  • Monitoração de Aplicações.

E o seu time, como está na maturidade de qualidade de código? Que práticas você está experimentando para melhorá-la com o seu time. Deixe aqui o seu comentário.

100 Ferramentas para Acelerar a sua Iniciativa DevOps

Fizemos aqui neste blog uma introdução ao pensamento DevOps, o seu valor de negócio e 20 práticas básicas e avançadas. Caso ainda não tenha tido oportunidade de lê-las, sugiro a leitura para ter o contexto do uso das ferramentas aqui propostas.

E é de vital importância lembrar que iniciativas DevOps são ancoradas em três Ps (Pessoas, Práticas e Produtos), nesta particular ordem. Ou seja, não faz nenhum sentido implantar alguma ferramenta muito legal na sua TI se a cultura e a prática não foi trabalhada anteriormente. 

Aviso fornecido e então vamos direto para as ferramentas, separadas por categoria.

1. Ferramentas para aumento da comunicação e orquestração de atividade

A cultura DevOps requer aumento da comunicação entre os times de desenvolvimento, qualidade e operação. Ela também requer um ambiente centralizado para a operação de ferramentas do ciclo de automação de práticas DevOps. E para suportar estas práticas existem ferramentas DevOps específicas para aumento da colaboração entre times.

O IBM Jazz, ServiceNow e o Visual Studio Team Services são exemplos particularamente interessantes neste sentido, buscando fornecer um fluxo automatizado para o ciclo de vida de práticas DevOps. O Slack e HipChat permitem integrar o conceito de conversas entre pessoas e grupos com as tarefas de automação feita via bots. Isso cria uma experiência simples e direta para reforçar os processos e práticas DevOps dentro de um time.

Estas e outras ferramentas são listadas a seguir:

  • Slack
  • HipChat
  • ServiceNow
  • IBM Jazz
  • Microsoft Visual Studio Team Services (VSTS)
  • Microsoft TFS (VSTS que você roda na sua própria infraestrutura)
  • Trello
  • Atlassian Jira
  • Pivotal Tracker

2. Ferramentas de Análise de código fonte

A cultura DevOps requer que desenvolvedores escrevam código de qualidade. Nos últimos anos, foi possível quantificar o que é qualidade de código de forma prática. Termos outrora vagos como complexidade ciclomática, modularidade, coesão alta e acoplamento fraco se tornaram métricas acionáveis em ferramentas simples como o Visual Studio Code Review e o SonarQube. Esta última tem suporte para mais de 20 linguagens e se popularizou nos últimos anos na comunidade de TI. Além disso, práticas de refatoração em tempo de desenvolvimento se tornaram simples também com a IDE JetBrains IntelliJ, JetBrains Resharper para o Visual Studio, Eclipse IDE ou Microsoft Visual Studio Code. E ferramentas como o Git suportam nativamente o conceito de Pull Requests, que simplificam a revisão por pares entre desenvolvedores.

A recomendação é que você inclua alguma das  ferramentas abaixo apontadas no ciclo de desenvolvimento e usem a automação para emitir avisos, defeitos ou até mesmo impedirem o checkin de códigos em casos extremos.

  • Microsoft Visual Studio 2015
  • Microsoft VSCode
  • JetBrains InteliiJ
  • JetBrains Resharper
  • Eclipse IDE
  • SonarQube
  • Git Pull Requests

3. Ferramentas de Gerência de Código Fonte

É impossível trabalhar com a cultura DevOps sem gerir apropriadamente o código fonte. E aqui estamos falando de ferramentas como o Subversion (SVN), Microsoft TFVC (Team Foundation Version Control), Mercurial ou Git. As duas primeiras operam de forma centralizada com um servidor de código, enquanto as duas últimas operam de forma distribuída. Em um SCM distribuído, existe um clone de cada repositório em cada máquina que tenha uma cópia do repositório de código. Em linhas gerais, as ferramentas de SCM distribuídos são conceitualmente melhores pois facilitam a gestão de troncos, automação de política e tem performance melhor que ferramentas de SCM centralizados. O Git, que foi popularizado a partir da experiência da comunidade Linux em manter de forma distribuída o desenvolvimento do seu kernel, se tornou muito popular no Brasil nos últimos anos. Se possível na sua realidade opere um SCM distribuído, seja ele Git ou Mercurial.

Ao escolher um SCM, seja ele distribuído ou centralizado, é importante decidir se ele irá operar em ambiente local ou ambiente de nuvem. O GitHub, BitBucket e o Gitlab são provedores de nuvem populares sobre os ambientes Git e Mercurial. Eles operam com planos sem custo de aquisição com funcionalidades e espaços limitados, mas permitem escalar para espaços maiores e mais funcionalidades com custos pequenos de entrada. Embora alguns gestores ainda temam as nuvens, observamos que a experiência de uso de ambientes de nuvens traz maior simplicidade, maior disponibilidade e menor custo de operação dessas ferramentas.

Seguem aqui algumas recomendações de ferramentas de SCM:
  • SVN
  • Microsoft TFVC
  • Git
  • Mercurial
  • GitHub
  • GitLab
  • Atlassian BitBucket

4. Ferramentas de Automação de Builds

Estas ferramentas são o coração da prática de gestão de builds e normalmente são específicas por tecnologia. A comunidade Java EE utiliza ferramentas como Ant e Maven e mais recentemente começou a adotar o Gradle para os seus processos de build. A comunidade Microsoft usa o MSBuild, que já vem incorporado na IDE do Visual Studio, Microsoft TFS (Team Foundation Server) e também no VSTS (TFS nas nuvens). A comunidade Javascript usa com regularidade ferramentas como o Grunt e o Gulp. Outras ferramentas populares para este fim incluem o Rake (Make do Ruby), Broccoli, SBT e Packer.

Segue um resumo das ferramentas para esta prática DevOps.

  • Maven
  • Gradle
  • MSBuild • Grunt
  • Gulp
  • Rake
  • Broccoli
  • SBT
  • Packer

5. Ferramentas de Integração Contínua

As ferramentas de integração contínua dão suporte ao escalonamento e gestão do processo de builds. Elas normalmente operam sobre as ferramentas de automação de builds e permitem que o desenvolver escalone ações automatizadas de build, sejam elas noturnas (nightly builds), em certos  momentos do dia ou disparadas por commits nos códigos (prática de continuous integration). Elas também permitem rodar outras tarefas tais como execução de suítes de testes, geração de documentação de código e abertura automatizada de defeitos.

O Jenkins é uma ferramenta sem custo de aquisição e bem popular para este tipo de processo. Ela é muito usada por desenvolvedores Java, JavaScript e LAMP. Já a comunidade Microsoft faz uso intenso do Microsoft TFS (Team Foundation Server) e vem adotando recentemente o Microsoft VSTS (Team Services). Esse último opera em nuvem e tem normalmente custo de propriedade reduzido, além de permitir a operação com times de até cinco pessoas sem nenhum custo. O VSTS permite também incorporar builds de aplicações Java, Android, iOS, Xamarin, entre outros e se tornou verdadeiramente uma ferramenta independente de ambiente Windows.

Outras ferramentas comuns para CI incluem o Atlassian Bamboo, Travis CI, IBM Rational Team Concert, Code Ship, Thought Works CruiseControl, CodeShip, TeamCity, GitLab, SolanoCI, Continuum, ContinuaCI e Shippable. Elas já fornecem ambientes de nuvens e algumas permitem você baixar o servidor para operar no seu ambiente se necessário.

Adote na sua iniciativa DevOps uma ferramenta de CI que esteja bem integrada com as suas tecnologias de código fonte e a opere em nuvens se isso não ofender as políticas de segurança da sua organização. Observamos geralmente nos preços destes produtos um custo menor de entrada e propriedade ao adotarmos infraestruturas de nuvens para a execução das práticas de automação de builds e integração contínua.

Segue aqui uma lista de ferramentas para este propósito:
  • Jenkins
  • Microsoft TFS
  • Microsoft VSTS
  • Atlassian Bamboo
  • Travis CI
  • IBM Rational Team Concert
  • Code Ship
  • Thought Works CruiseControl
  • CodeShip
  • TeamCity
  • GitLab
  • SolanoCI
  • Continuum
  • ContinuaCI
  • Shippable

6. Ferramentas de Gestão de Configuração e Provisionamento

Estas ferramentas permitem automatizar todas as suas configurações como código e também provisionar hardwares automaticamente, sendo também muito importantes para suportar releases de produtos (Release Management). Estas ferramentas são chamadas em alguns meios de CCA Tools (Continuous Configuration Automation).Em linhas gerais, elas suportam as seguintes capacidades:

  • permitem o escalonamento temporal do processo de release, que pode ser feito em base noturna (nightly release) ou ativado toda vez que um novo build estiver disponível (continuous deployment ou continuous delivery);
  • permitem escrever a configuração de hardware através de códigos de script;
  • permitem provisionar dinamicamente os ambientes de hardwares;
  • permitem copiar os builds entre os ambientes de hardware provisionados;permitem a conexão a plataformas de nuvens como Amazon EC2, Microsoft Azure, entre outras;
  • permitem configurar dinamicamente os parâmetros da aplicação copiada para os ambientes;
  • permitem estabelecer processos de aprovação antes e/ou depois das cópias dos builds;
  • permitem rodar smoke tests, gerar rótulos (labels) nos releases ou enviar notificações para os interessados no processo.
Na comunidade Microsoft, o VSTS incorporou recentemente um excelente módulo de ReleaseManagement. Ele suporta scripts de infraestrutura como código em um dialeto chamado PowerShell DSC (Desired State Configuration). Em termos simples, ele permite que o desenvolvedor especifique um hardware em um script de código DSC (que é um arquivo JSON). O ambiente VSTS cria automaticamente este ambiente de hardware no Microsoft Azure. Alé disso, o VSTS Release Management controla o fluxo de aprovações, executa as distribuições necessárias dos builds nos ambientes, realiza a configuração dos parâmetros externalizados da aplicação nos ambientes provisionados e também permite rodar testes nos ambientes de produção. Neste segmento de ferramentas estão também os maiores fornecedores de soluções e consultoria DevOps, como por exemplo as empresas Chef e Puppet Enterprises. Outras soluções comuns neste segmento incluem a Ansible, Salt, Vagrant, Terraform, Consul, CF Engine, BMC BladeLogic, BMC Release Process e Serena Release, entre outras.
Um resumo destas ferramentas é fornecido abaixo:
  • Microsoft VSTS Release Managament e Microsoft Azure
  • Chef
  • Puppet
  • Ansible
  • SaltStack
  • BMC BladeLogic
  • BMC Release Process
  • Vagrant
  • Terraform
  • Consul
  • CF Engine
  • XL Release
  • UrbanCode Release
  • Automic
  • Plutora Release
  • Serena Release
7. Ferramentas de Conteinirização
Como operar com dezenas ou centenas de máquinas virtuais para o suporte a provisionamento pode ser caro, algumas ferramentas surgiram no topo das ferramentas de virtualização para facilitar a gestão de ambientes virtualizados. Estas ferramentas são chamadas de ferramentas de conteinirização e operam permitindo que blocos de máquinas virtuais possam ser arranjados conforme necessário para criar novas configurações. Por exemplo, um time pode ter já um ambiente virtual com Oracle Database 11g, Apache Tomcat e Driver JDBC tipo 2 montado. Se um outro time precisa modificar apenas a versão do Driver JDBC para tipo 4 em um outro contexto, ele não precise recriar toda a máquina virtual do zero. Ele especifica as partes necessárias e ferramenta de conteinerizacao monta a nova máquina virtual a partir de fragmentos existentes no repositório. A ferramenta também inclui os novos fragmentos, conforme necessário. Isso gera uma tremenda economia de espaço em disco e tempo para a organização de máquinas virtuais.

O Docker é talvez a ferramenta de maior popularidade neste segmento e tem sido usado para tornar o provisionamento de hardware algo simples, barato e acionável. Outras ferramentas populares neste contexto são o Mesos, Swarm, Kubernetes e Nomad.

A lista destas ferramentas é citada a seguir:

  • Docker
  • Mesos
  • Swarm
  • Kubernetes
  • Nomad

8. Ferramenta de Gestão de Repositórios

Estas ferramentas permitem gerir os repositórios de código e bibliotecas para estabelecer ambientes controlados de desenvolvimento. Isso evita que componentes sejam introduzidos na aplicação de forma indisciplinada e através de cópia de arquivos no sistema de arquivos.

O Docker Hub é uma ferramenta neste sentido e disciplina o uso de máquinas virtuais Docker, nas nuvens ou na própria infraestrutura da empresa. No mundo Microsoft, o Nuget e o Package Management do VSTS são ferramentas usadas para este controle. Já a comunidade JavaScript e Node.JS usa o NPM (Node Package Manager). E vemos a comunidade Java usar ferramentas como o Artifactory e o Nexus para estabelecer bases controladas de bibliotecas e componentes Java.

Uma lista das ferramentas para esse propósito são listadas abaixo:

  • NPM
  • DockerHub
  • Artifactory
  • Nuget
  • Nexus

9. Ferramentas de Automação de Testes

Embora builds possam ser montados apenas com ferramentas de build management, a experiência mostra que builds requerem o uso de automação de testes para aumentar a robustez e confiabilidade do produto sendo gerado. Ou seja, as ferramentas de automação de testes são peças fundamentais no quebra-cabeças DevOps e vão de encontro ao element de testabilidade no dialeto arquitetural.

Algumas destas ferramentas incluem:

  • Automação para testes de unidade do código – JUnit, TestNG, NUnit, Visual Studio Unit Test, Jasmine, Mocha e QUnit.
  • BDD (Behaviour Driven Development) – Cucumber, CucumberJS, e SpecFlow.
  • Automação de testes funcionais – Selenium e Visual Studio Coded UI.
  • Cobertura de Código –JaCoCo e Visual Studio

A lista destas e outras ferramentas é mostrada a seguir:

  • JUnit
  • NUnit
  • TestNG
  • Visual Studio UnitTest
  • Jasmine
  • Mocha
  • QUnit
  • Cucumber
  • CucumberJS
  • SpecFlow
  • Selenium
  • Visual Studio CodedUI
  • JaCoCo

10. Ferramentas de Testes de Performance, Carga e Estresse

Em aplicações Web e móveis, onde a carga de trabalho pode variar com muita intensidade, é recomendado que usemos ferramentas de automação de teste de performance, carga de trabalho e estresse. O JMeter é uma ferramenta popular na comunidade Java, embora também possa ser usada para testar recursos Web como conexões HTTP em qualquer tecnologia. O TestNG, VSTS Web Performance e o VSTS Load Test também são outros exemplos de ferramentas para este fim.

Depois de ter estabelecimento um processo de automação de build e releases, pode ser apropriado inserir um ciclo de testes de performance e estresse no seu processo DevOps.

Uma lista de alguma destas ferramentas é mostrada abaixo:

    • Apache JMeter
    • Apache ab
    • VSTS Web Performance
    • VSTS Load Test

11. Ferramentas de Monitoração de Aplicações e Telemetria

Uma transição suave para a operação pode ser facilitada pelo uso de ferramentas de monitoração de aplicações e telemetria. Em termos simples, estas ferramentas fazem a análise dos elementos físicos dos ambientes de hardware (caixa preta), componentes da aplicação (caixa cinza) e até mesmo o comportamento do código fonte em produção (caixa branca).

A ferramenta NewRelic é um excelente exemplo neste sentido e se popularizou para a monitoração de aplicações Web. Outras ferramentas neste  sentido incluem o Kibana, DataDog, Zabbix, VSTS Application Insights, ElasticSearch e StackState.

Uma listagem destas e outras ferramentas é mostrada a seguir:

  • Kibana
  • DataDog
  • Zabbix
  • VSTS Application Insights
  • ElasticSearch
  • StackState
  • Nagios
 12. Ferramentas de Injeção de Falhas
Nesta categoria estamos falando de ferramentas que permitem injetar falhas em aplicações nos ambientes de produção, como por exemplo o Netflix Simian Army. Esta suíte227, que foi disponibilizada no GitHub, contém ferramentas utilitárias diversas, tais como:
  • Chaos Monkey – Introduz falhas aleatórias em máquinas dos ambientes de produção.
  • Latency Monkey – Introduz demoras artificiais nas comunicações RESTful para simular degradação do serviço e medir se as aplicações clientes respondem apropriadamente.
  • Conformity Monkey – Encontra instâncias que não estão aderentes a melhores práticas e as desligam. Por exemplo, uma melhor prática poderia ser que toda instância deveria pertencer a grupo de escala (auto-scale) no ambiente AWS EC2 da Amazon. Se uma instância é encontrada e não obedece a esta política, ela é terminada.
  • Doctor Monkey – Encontra instâncias que não estejam saudáveis e as desligam. Por exemplo, um sinal de falha na saúde é a CPU operar acima de 70% por mais de 1 hora. Se uma instância é encontrada em um estado não saudável, ela é terminada.
  • Janitor Monkey – Busca e limpa recursos não usados nos ambientes de produção.
  • Security Monkey – Busca vulnerabilidades em máquinas e desliga as instâncias que estejam ofedendo as políticas de segurança.
  • 10-18 Monkey – Detecta problemas de configuração (i10n e 18n) em instâncias que servem a múltiplas regiões geográficas.
  • Chaos Kong – Remove uma região inteira de disponibilidade da Amazon do ambiente de produção.

 13. Plataformas de Nuvens

As plataformas de nuvens possuem um papel importante no ciclo DevOps. Sejam públicas ou privadas, elas permitem tratar a infraestrutura e redes como código e facilitam sobremaneira os processos de gestão de releases. A Amazon WebServices talvez seja o maior expoente deste segmento, com uma rica coleção de serviços de IAAS, PAAS e SAAS para suportar o desenvolvimento e operação de aplicações. Outras soluções populares incluem o Microsoft Azure, RackSpace, Digital Ocean e Google Cloud Platform.

Essas e outras ferramentas são listadas a seguir:

    • Amazon AWS
    • Microsoft Azure
    • RackSpace
    • DigitalOcean
    • Google Cloud Platform

Fechamos o artigo com as famosas leis da automação do Bil Gates, antes que você corra para implantar todas as ferramentas citadas neste post na sua empresa.  🙂

“A primeira lei de qualquer tecnologia é que a automação de um processo eficiente irá aumentar a sua eficiência”, Bill Gates

“A segunda lei de qualquer tecnologia é que a automação de um processo ineficiente irá aumentar a sua ineficiência”,  Bill Gates”

E você, que ferramentas está usando para acelerar o DevOps na sua organização? Compartilhe as suas experiências aqui conosco.

Práticas DevOps Avançadas

Alguns times ágeis já tem práticas básicas implementadas dentro de algumas disciplinas DevOps. Ou outros times podem ter necessidades muito específicas dentro do mundo DevOps, que poderiam ser classificadas como avançadas. Neste contexto, compilo aqui 12 práticas DevOps avançadas de grande auxílio para diversos tipos de times que estejam buscando melhoria contínua de sua maturidade.

1. Testes de Carga

Em aplicações Web, podem haver variações abruptas no perfil de carga da aplicação em produção. Isso se deve a natureza estocástica no comportamento de requisições Web e a natureza do protocolo HTTP. Não é incomum que picos aconteçam e gerem 10x mais carga de trabalho que o uso médio da aplicação. Os sintomas comuns nas aplicações de mercado são longos tempos de resposta e até mesmo indisponibilidade do servidor Web (erros 5xx).

Estes sintomas podem ser minimizados com o uso de testes de carga em aplicações Web. O teste de carga é uma prática que permite gerar uma carga controlada para uma aplicação em um ambiente de testes específico ou homologação e assim estabelecer se um determinado build é robusto e pode ser promovido para ambientes de produção.

2. Testes de Estresse

O teste de estresse é um tipo de teste de carga onde queremos criar fraturas em uma aplicação dentro de um ambiente com parâmetros de hardware previamente estabelecidos. Ele consiste em aumentarmos gradativamente a carga em uma aplicação para saber qual será o primeiro componente a falhar por sobrecarga (ex. Banco de dados, servidor Web ou fila de mensagem). Esta técnica permite que o time de operações possa priorizar a sua atenção em infraestruturas complexas. Ela também permite aos times de desenvolvimento estabelecer os limites de uso da sua aplicação para os seus clientes.

3. Integração Contínua (Continuous Integration)

Depois que a automação dos builds acontece, ela pode ser programada para ser executada em base diária ou até mesmos várias vezes por dia. Quando esta maturidade for alcançada, podemos avançar para que ela seja executada continuamente, i.e., toda vez que um um commit acontecer em um código fonte.

É esperado que esta prática faça pelo menos o seguinte conjunto de passos:

  • promova a recompilação do código fonte do projeto;
  • execute as suites de teste de unidade automatizados do projeto;
  • gere o build do produto;
  • crie um novo rótulo para o build;
  • gere defeitos automatizados para o time se o build falhou por algum motivo.

A prática da integração continua promove as seguintes vantagens:

  • detectar erros no momento que os mesmos acontecem;
  • buscar um ambiente de gestão de configuração minimamente estável de forma continuada;
  • estabelecer uma mudança cultural no paradigma de desenvolvimento, através de feedbacks contínuos para o time de desenvolvimento da estabilidade do build.

4. Implantação Contínua (Continuous Deployment)

Depois que um processo mínimo de integração e implanatção estiver em curso, podemos avançar também para um processo contínuo de implantação nos ambientes intermediários (testes ou homologação). Este processo pode ser controlado por uma ferramenta e normalmente é ativado quando um novo build foi gerado pela ferramenta de automação de builds.

Em linhas gerais, a prática da implantação contínua garante que mesmo conjunto de bits do build é replicado no ambiente do desenvolvedor para ambientes controlados de desenvolvimento e homologação, garantindo a consistência do build em outros ambientes.

Em ambientes rigidamente governados onde existam processos ITIL, DBAs e times independentes de QA, naturalmente irão haver ciclo de pré-aprovações ou pós-aprovações para que as promoções de ambiente ocorram. O fato importante a notar na cultura DevOps é que o ser humano envolvido não copia arquivos ou parametriza aplicações. Ele examina a requisição, o build, parâmetros e as suas evidências de teste. Ao aprovar a solicitação de promoção, um robô irá fazer a movimentação dos builds e a parametrização apropriada da aplicação. Se ele não autorizar a promoção, um defeito é aberto para o solicitante no canal apropriado.

5. Entrega Contínua (Continuous Delivery)

Em termos simples, a entrega continua é o processo de implantação contínua em ambiente de produção. Ela é normalmente ativada por uma ferramenta automatizada quando um novo build for publicado com sucesso no ambiente de homologação. A entrega contínua normalmente envolve:

  • a requisição de aprovação de implantação para o responsável pelo ambiente de produção;
  • a cópia dos arquivos do ambiente de homologação para o ambiente de produção;
  • a verificação do estado da aplicação disponibilizada em produção.

Observe que a entrega contínua não significa que o ambiente de produção é modificado a todo instante. Apenas empresas de serviços de Internet podem e devem fazer isso. A entrega contínua implica que o ambiente de produção pode ser alterado se um novo build estiver disponível e as aprovações necessárias foram dadas para a promoção do build.

A entrega contínua envolve tipicamente a execução de smoke tests, que são testes de sanidade da aplicação. Estes testes verificam minimamente a estabilidade do build colocado em produção e testam cenários funcionais mínimos.

6. Integração Contínua, Implantação Contínua e Entrega Contínua – Entenda as diferenças

A integração continua (Continuous Integration) é o processo de compilar o código em ambiente limpo, rodar testes e outros processos de qualidade e gerar um build, disparado por qualquer modificação no código fonte.

Já a implantação continua (Continuos Deployment) é o processo de promover o build gerado no processo de integração para ambientes intermediários como QA ou homologação.

Finalmente, a entrega continua (Continuous Delivery) é o processo de implantação continua que busca promover os builds para o ambiente de produção.

7. Testes Canários (ou Testes A/B)

Os testes canários são práticas úteis para empresas que praticam a entrega contínua e querem minimizar efeitos colaterais de novas funcionalidades na comunidade de usuários.

Quando um novo produto é colocado em produção pela automação dos releases, pode haver um risco de negócio em liberar as novas funcionalidades para toda a sua comunidade de usuários. Talvez seja necessário fazer um certo experimento de negócio para saber se aquela funcionalidade será realmente útil e se será mantida ou removida do produto.

Estes experimentos controlados, especialmente úteis em startups, podem ser ativados com os testes canários. O termo é devido a uma prática que ocorria nas minerações na Europa há alguns séculos. Mineiros levavam canários em gaiolas para novos veios em suas minas. Eles começam a trabalhar e deixavam os canários perto deles ao longo do dia de trabalho. Se um canário morresse depois de um tempo pequeno naquele ambiente, era porque o ambiente não estava saudável para a atividade humana devido a gases tóxicos. Na cultura DevOps da TI, o teste canário consiste em habilitar novas funcionalidades apenas para um grupo controlado de usuários (os canários). Ou seja, em ambiente de produção a aplicação opera de duas formas distintas para duas comunidades (A/B). Isso pode ser implementado através do padrão de desenho chamado Feature Toogles[1] e permite estabelecer uma prática chamada HDD (Hypothesis Driven Development). Se os canários não gostam do ambiente, a funcionalidade pode ser removida facilmente do produto em ambiente de produção sem intervenção no código fonte.

8. Infraestrutura como Código (IAC)

Times de baixa performance DevOps ainda possuem processos manuais e morosos de acionamento entre desenvolvimento e operações. Um exemplo prático é a criação de uma nova máquina feita do time de desenvolvimento para o time de ops. Em muitas empresas, este tipo de requisição demora horas, dias ou até mesmo semanas para ser realizada.

Quando times alcançam boa maturidade na configuração de elementos como scripts, elas podem avançar e tratar até o mesmo o hardware como código. Através de tecnologias disseminadas nos últimos anos em ambientes Linux, Windows e OS/X, é possível configurar os processos de automaçao de build e automação de releases para criar uma máquina virtual através de um código de script. A infraestrutura como código é prática essencial para aproximar devs e ops, pois ela permite estabelecer para o time de operações confiabilidade apropriada para as novas implantações realizadas em ambientes de produção.

A infraestrutura como código traz ainda como grande benefício estabelecer um protocolo comum entre os times de desenvolvimento e o time de operações. Esta prática elimina a necessidade da criação manual de ambientes físicos, que é moroso, propenso a erros e que causa muito atrito entre times. Ao automatizar esse processo, podemos reduzir brutalmente o tempo de ciclo para entrega de aplicações em produção. A tecnologia do Docker[2] é um excelente exemplo neste sentido.

Através de ferramentas utilitárias como o Power Shell DSC no Windows, Puppet, Chef, entre outras, arquivos de scripts que especificam configurações de máquinas podem ser compilados e então implantados em plataformas de nuvens como a Microsoft Azure ou Amazon EC2. A implantação deste arquivo cria, dinamicamente, uma máquina virtual com a exata especificação informada. Ou seja,  o trabalho de criação manual de uma máquina virtual e sua tediosa configuração é eliminado. Ao invés, criamos e testamos um script em alguma linguagem e o ambiente subjacente se encarrega de fazer o provisionamento das máquinas virtuais no ambiente de produção.

Até alguns anos atrás, somente era possível pensar no IAC se usássemos ambientes de nuvens públicas. Mais recentemente, isso é também possível com tecnologias similares em nuvens privadas com Linux e Windows. Tecnologias como o Pivotal Cloud Foundry e o IBM Bluemix, entre outras, tornaram possíveis fazer IAC em nuvens privadas.

9. Ambientes Self-Service

Em muitas empresas, é comum que um novato demore horas ou até dias para que consiga estabelecer um novo ambiente de trabalho. Isso é devido ao conjunto de passos manuais necessários, falta de procedimentos operacionais e dificuldades implíticas a montagem de ambientes Java EE ou .NET.

A prática de ambientes self-service permite que através de um código de script todo um ambiente de trabalho seja baixado, criado e disponibilizado para habilitar um desenvolvedor no seu trabalho em poucos minutos. Dado que um desenvolvedor tenha uma estação de trabalho com excelente memória RAM e uma rede veloz, é possível operacionalizar esta prática e salvar tempo precioso como o estabelecimento de ambientes de trabalho com confiabilidade e robustez. O Docker, em particular, é uma tecnologia que ganhou popularidade nos últimos anos para apoiar também esta prática.

10. Injeção de Falhas

Uma prática avançada DevOps é injetar defeitos no ambiente de produção de forma explícita. Por exemplo, podemos deliberadamente desligar o acesso ao banco de dados ou outros recursos críticos e forçar a aplicação a falhar. Isso pode parecer bizarro para alguns ou um contrassenso para outros. Mas pode fazer todo o sentido quando estamos buscando ambientes de alta disponibilidade e confiabilidade. Através do uso de procedimentos controlados de desestabilização da aplicação, podemos verificar como a aplicação se recupera de uma falha em ambiente de produção. Algumas perguntas que o time de operações poderia investigar incluem:

  • Ela se recupera automaticamente e retorna para o estado original antes da falha?
  • Ela emite alarmes apropriados para as partes interessadas?
  • Ela fornece mensagens simples e explicativas para os usuários finais?

Esta prática começou a ganhar momento na TI depois que a Netflix publicou[3] o uso desta prática nos seus ambientes de produção e a disponibilização da sua ferramenta de injeção de falhas chamada Simian Army[4]. Conceitualmente, esta prática permite estabelecer um mecanismo de antifragilidade[5] na sua aplicação, tornando-a melhor ao longo do tempo à medida que ela seja estressada.

11. Telemetria

A telemetria é uma forma avançada de monitoração de aplicações em ambiente de produção. Ela permite conhecer mais profundamente os padrões de uso de uma aplicação, variações de carga, acesso, entre outras questões. A Telemetria conta também com um mecanismo intrínseco de capacidade de análise de uso (analytics) que permite aos times conhecer os padrões de acesso e assim evoluir o produto tecnicamente e também do ponto de vista de negócio com mais sabedoria.

12. Planejamento de Capacidade

O planejamento de capacidade envolve o uso de técnicas estatísticas e teoria de filas para conhecer, modelar e simular a carga de trabalho em aplicações e assim estabelecer o hardware mais apropriado para rodar uma aplicação, bem como ter ciência dos limites e potenciais problemas de operação.

Esta técnica pode ser implementada por ferramentas de testes de carga e performance e são especialmente úteis para empresas que trabalhem com cenários desafiantes de cargas de trabalho e busquem o uso de computação elástica em ambientes de nuvens.

[1] http://martinfowler.com/articles/feature-toggles.html

[2] http://docker.com

[3] https://www.infoq.com/br/news/2012/08/netflix-chaos-monkey

[4] https://github.com/Netflix/SimianArmy

[5] A fragilidade significa que algo quebra sob algum estresse, como por exemplo um copo fino solto de certa altura. Já a robustez indica que algo resiste a um estresse sem alterar o seu estado. Mas a antifragilidade vai muito além da robustez e resiliência. Um organismo antifrágil melhora o seu estado depois de submetido a um estresse. Por exemplo, exercícios físicos, até um certo nível, geram estresses em pessoas e a resposta do corpo delas é se tornar melhor com uma melhor densidade óssea e maior massa muscular. A antifragilidade é o oposto matemático da fragilidade. Enquanto a fragilidade é denotada como um número negativo -X, a robustez seria denotada como o número 0 e a antifragilidade seria denotada como um número positivo X. Este conceito é apresentado e discutido no livro AntiFrágil – Coisas que se beneficiam com o caos, de Nicholas Taleb, publicado em 2012.

No próximo post, iremos começar a apresentar ferramentas do ecossistema de DevOps.

 

Práticas DevOps Básicas

Embora não exista um corpo fechado de práticas técnicas DevOps, proponho aqui uma lista de práticas básicas para a implantação desta cultura. A lista aqui apresentada não possui uma ordem de prioridade, que depende da realidade de cada organização e da cultura já instalada nos seus times de desenvolvimento, qualidade e operações.

As práticas DevOps buscam endereçar as melhorias em atributos de qualidade tais como a manutenibilidade, testabilidade, implantabilidade e recuperabilidade. Com estas práticas implementadas, teremos maior garantia que minimizaremos o débito técnico dos produtos de software sendo construídos e aceleraremos a entrega para produção dos produtos.

1.Comunicação Técnica Automatizada

A cultura DevOps busca aproximar pessoas dos times de desenvolvimento, qualidade e operações. E essa aproximação pode ser facilitada com ferramentas de comunicação que aliam o melhor da mensagem instantânea e canais de times com alarmes técnicos automatizados. Por exemplo, ferramentas como o Slack ou HipChat permitem que times com pessoas de desenvolvimento, qualidade e operações possam:

  1. estabelecer conversas texto, aúdio e vídeo em canais privativos e focados;
  2. receber notificações de ferramentas tais como a disponibilização de builds, aprovação de releases ou problemas em produção;
  3. disparar comandos através de bots para a abertura de defeitos, escalonamento de builds ou releases.

2. Qualidade contínua do código

Em muitas empresas, é muito fácil que uma arquitetura definida pelo time de arquitetura seja continuamente violada pelo time de desenvolvimento. O arquiteto normalmente não tem tempo e dedicação para “vigiar” o código fonte e realizar a aderência arquitetural do código ou observar o uso de práticas apropriadas de codificação. O efeito é que a arquitetura executável colocada em produção é muito diferente da arquitetura imaginada pelo arquiteto.

No sentido de minimizar esta lacuna, esta primeira prática lida com a automação da verificação da qualidade de código por ferramentas. Existem atualmente ferramentas sólidas que permitem avaliar o uso das melhores práticas de programação no seu ambiente (Code Metrics Tools) e avaliar a aderência do seu código a uma arquitetura de referência (Architectural Analysis Tools). E essas ferramentas podem ser programadas para rodar a noite ou até mesmo durante o momento do checkin do código pelo desenvolvedor. Existem ainda ferramentas que facilitam o processo de revisão por pares dos códigos fontes (Code Reviews), estabelecendo workflows automatizados e trilhas de auditoria. O recurso de Pull Requests do Git é um exemplo deste mecanismo.

Com esta prática, temos robôs que atuam continuamente para facilitar a análise do código fonte, educar desenvolvedores e estabilizar ou mesmo reduzir o débito técnico instalado.

3. Configuração como Código

Em muitos times, é comum que desenvolvedores façam muitas tarefas manualmente. Exemplos incluem cópias de arquivos entre ambientes, configuração destes ambientes, configuração de senhas, geração de release notes ou a parametrização de aplicações. Esses trabalhos manuais são propensos a erros e podem consumir tempo valioso do seu time com tarefas braçais.

Times atentos devem observar quando algum tipo de trabalho manual e repetitivo começa a acontecer e buscar automatizar isso. A automação da configuração através da escrita de códigos de scripts é um instrumento DevOps importante para acelerar o trabalho de times de desenvolvimento, reduzir erros e garantir consistência do trabalho.

No mundo DevOps, tudo é código!

4. Gestão dos Builds

A gestão de builds (ou Build Management) é prática essencial para garantir que os executáveis da arquitetura sejam gerados de forma consistente, em base diária. Esta prática busca evitar o problema comum do código funcionar na máquina do desenvolvedor e ao memo tempo quebrar o ambiente de produção.

A automação de builds externaliza todas as dependências de bibliotecas e configurações feitas dentro de uma IDE para um script específico e que possa ser consistentemente movida entre máquinas. Embora a automação de builds, na sua definição formal, lide apenas com a construção de um build, a prática comum de mercado é que builds devam executar um conjunto mínimo de testes de unidade automatizados para estabelecerem confiabilidade mínima ao executável sendo produzido.

Esta prática lida ainda com o estabelecimento de repositórios confiáveis de bibliotecas, o que garante governança técnica sobre o conjunto de versões específicas de bibliotecas que estejam sendo usadas para montar uma aplicação.

5. Gestão dos Testes

Organizações de baixa maturidade em automação de testes tem muito mais retrabalho ao longo de um projeto e geram muito mais incidentes em ambientes de produção. Esta prática DevOps buscar melhorar a testabilidade de aplicações e envolve:

  • a criação de testes de unidade de código para as regras de negócio não triviais do sistema e também pontos críticos do código fonte tais como repositórios de dados complexos, controladores de negócio e interfaces com outros sistemas e empresas;
  • a automação da interação com telas com testes funcionais automatizados;
  • testes automatizados de aspectos não-funcionais, como segurança, acessibilidade, performace ou carga.

6. Gestão de Configuração

Muito times já usam ferramentas de controle de versão para organizar o seu código fonte, tais como o SVN, GIT ou Mercurial. Ao mesmo tempo, existem outras preocupações associadas ao trabalho feito por times em uma mesma linha de código. A ausência de políticas automatizadas de gestão de configuração digo aumenta a chance que desenvolvedores desestabilizem os troncos principais dos repositórios e gerem fricção e retrabalho para seus pares.

Neste contexto, as ferramentas de gestão de configuração de código permitem que os repositórios sejam mantidos em estado confiável e que erros comuns sejam evitados através da automação de políticas. Tarefas de gestão de configuração de código tais como a criação de rótulos (labels), geração de versões, mesclagem de troncos de desenvolvimento e a manutenção de repositórios podem ser aceleradas e tornadas mais consistentes com o uso destes recursos.  Como exemplo, o Git suporta o conceito de hooks[1], mecanismo extensível de automação de políticas de gestão de código. Outras ferramentas como o GitLab, VSTS ou Atlassian Bamboo já possuem estes mecanismos embutidos.

7.Gestão dos Releases

A gestão dos releases (Release Management) é uma prática que buscar garantir que o processo de promoção do executável para os ambientes de testes, homologação e produção sejam automatizados e assim tornados consistentes. Isso é importante porque em muitas organizações é difícil colocar um produto em ambiente de produção. A demora para acesso aos ambientes, alto número de passos manuais, a complexidade e a dificuldade de analisar os impactos são comuns. Isso gera atritos, longas demoras e desgates entre times de QA, desenvolvimento e operações. E no fim isso também provoca erros nos ambientes de produção.

Esta prática tem como principais benefícios:

  • reduzir o tempo para entregar um novo build em ambiente de produção através da automação da instalação e configuração de ferramentas e componentes arquiteturais;
  • reduzir erros em implantação causadas por parâmetros específicos que não foram corretamente configurados pelos times de desenvolvimento e operações;
  • minimizar a fricção entre os times de desenvolvimento, QA e operações;
  • prover confiabilidade e segurança no processo de implantar aplicações.

Um ponto de atenção é que a automação de releases não deve recompilar a aplicação. Para garantir consistência, ela deve garantir que o mesmo executável que foi montado na máquina do desenvolvedor (mesmo conjunto de bits) esteja operando em outros ambientes. Ou seja, a automação de releases faz a movimentação dos executáveis entre os ambientes e modifica apenas os parâmetros da aplicação e variáveis de ambiente. Este processo pode também envolver a montagem de máquinas virtuais em tempo de execução do script.

8. Automação da Monitoração de Aplicações

Ao colocarmos um build em ambiente de produção, devemos buscar que o mesmo não gere interrupções nos trabalhos dos nossos usuários. Infelizmente, muitas empresas convivem com incidentes em ambientes de produção causados por falhas nos processos de entrega em produção e desconhecimento de potenciais problemas.

Uma forma de reduzir a chance de incidentes para os usuários finais é implementar a monitoração contínua de aplicações (Application Performance Monitoring). Esta prática permite que agentes sejam configurados para observar a aplicação em produção. Alarmes podem ser ativados para o time de operações se certas condições de uso forem alcançadas ou se erros inesperados surgirem. Isso permite ter ciência de eventuais incidentes com antecedência e tomar ações preventivas para restaurar o estado estável do ambiente de operações.

E, para melhorar a experiência, alguns times já fazem que estes alarmes sejam enviados através de bots para as ferramentas de comunicação tais como o HipChat ou Slack.

E você, que práticas DevOps está usando no seu dia a dia. Como está sendo a experiência com elas? Compartilhe aqui a sua experiência.

No proximo post, compartilho com vocês 12 práticas avançadas do mundo DevOps.