Mês: dezembro 2016

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

~ Marco Mendes ~ Deixe um comentário

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

~ Marco Mendes ~ 1 comentário

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 DevOps – Gestão de Builds e Integração Contínua

~ Marco Mendes ~ 4 Comentários

Este é o segundo post da série sobre maturidade em práticas DevOps. E aqui vamos discutir a maturidade na gestão de builds e integração contínua, prática nuclear dentro do mundo DevOps.

Antes de discutirmos a maturidade, é necessário esclarecer o que é um build. Na prática DevOps, um build é  um código executável gerado a partir de  instruções automatizadas e precisas de compilação a partir do código fonte e que atenda a um critério mínimo de testes.

Observe que esta definição tem duas implicações práticas:

  1. O código executável precisa ser gerado a partir de um arquivo chamado de definição de build para que possa ser compilado em qualquer ambiente. Isso evita a síndrome do desenvolvedor lambão que diz para você – “Na minha máquina compila”.
  2. O código executável deve passar com sucesso por uma suíte de testes automatizados para garantir sua estabilidade mínima (chamados de smoke tests). E isso evita a segunda síndrome do seu colega de trabalho, o desenvolvedor lambão, que diz para você – “Na minha máquina funciona”.

Com essa definição posta, podemos definir a nossa escala de maturidade.

  1. Maturidade 1 – Inicial – Aqui não existe uma cultura de builds. A compilação está acoplado às IDES como o Eclipse ou Visual Studio e é totalmente dependente destes ambientes. É comum que códigos compilem ou rodem em máquinas específicas apenas. Neste estágio também não observamos uma suíte de automação de testes que buscam garantir a qualidade do build.
  2. Maturidade 2 – Consciente –  Aqui a cultura de builds começa a ser instalada. Ferramentas como o Make, Maven, Gradle, Rake, Nuget e MSBuild começam a ser utilizadas pelo time para eliminar dependências de máquina na compilação. Isso permite que o código seja compilado com facilidade em qualquer máquina. Neste nível o time também introduz um suíte mínima de testes de fumaça (smoke tests) para garantir a estabilidade do build.
  3. Maturidade 3 – Gerenciado – Aqui os builds começam a ser executados em intervalos regulares em ambientes dedicados (ambientes de integração). Ferramentas como o Jenkins, GitLab, IBM Racional Team Concert, Ansible, Microsoft TFS ou Microsoft VSTS entram em cena para baixar do repositório os códigos fontes, compilar e testar os builds. Falhas na geração dos builds geram defeitos automatizados para o time de desenvolvimento. Neste nível também observamos uma maior cobertura  das suítes de testes (desejável maior que 20% do código fonte) e verificação automatizada das métricas de qualidade de código.
  4. Maturidade 4 – Avançado – Aqui temos um incremento na frequência de execução do build. Os builds começam a ser executados várias vezes por dia e operam até mesmo em ambientes paralelos com objetivos distintos (ex. Ambiente de build para testes de performance e ambiente de Build para testes funcionais). A cobertura do código fonte é agora expressiva e normalmente passa de 50% do código fonte e inclui testes funcionais e outros tipos de teste como performance, usabilidade ou segurança.
  5. Maturidade 5 – Melhoria Contínua – Aqui o time está tão avançado que ele começa a experimentar a prática da integração contínua (continuous integration), que formalmente definida é o processo de geração de builds disparado por modificações no código fonte. Em outros times, existem também políticas automatizadas que impedem o commit de código fonte que provoque quebra nos builds (padrão Gated Commit).

Podemos entender esta escala de maturidade a partir de dois fatores: frequência de execução e número de processos de qualidade executados. Um time com baixa maturidade não executa builds com frequência e não possui processos automatizados de qualidade que garantam o build gerado. Já um time de alta maturidade faz isso várias vezes por dia e cobre muitos processos técnicos tais como: testes de unidade, testes de tela, testes de integração, testes de segurança, testes de usabilidade, testes de performance, verificação da qualidade do código e até mesmo conformidade arquitetural a padrões pré-estabelecidos.

Naturalmente, este é um assunto denso e requer disciplina e tempo para ser implementado. Mas os resultados são notáveis e pagam, com juros, o esforço investido.

Recursos de Aprendizado

Se você deseja avançar a maturidade do seu time nesta importante prática, deixo aqui um conjunto importante de livros que são hoje referência para desenvolvedores profissionais. Os dois primeiros são específicos sobre a prática de Gestão de Builds, Integração Contínua e assuntos correlatos como a Entrega Contínua (Continuous Delivery). Temos aqui também dois livros sobre ferramentas populares – Jenkins e Microsoft VSTS. E finalmente dois livros sobre DevOps, sendo que o último é escrito na forma de uma história, o que torna a leitura bastante agradável.

51o9tzpyaul     41db4qikfil-_sx348_bo1204203200_
51ufxhdzvfl     41x0usghmnl-_sy346_

51mcvngdt6l   5170sr05qal

E você, ainda convive com desenvolvedores lambões? Ou já começou a aumentar a maturidade de gestão de builds no seu ambiente. Compartilhe aqui a sua experiência com esta prática.

 

Maturidade em Práticas DevOps

~ Marco Mendes ~ 4 Comentários

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

~ Marco Mendes ~ Deixe um comentário

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.