DevOps: Reduzindo o time-to-market

Um mergulho nos detalhes do DevOps: Busque pela definição de DevOps e você provavelmente encontrará relação com uma coleção de outras buzzwords como “agilidade”, “administração de sistemas” e “lean”, que na verdade não te dizem nada. A proposta desse texto é trazer uma conceituação um pouquinho melhor do que esse apanhado retornado nas ferramentas de busca.

A ideia central por trás do DevOps é colocar os times de desenvolvimento e operações trabalhando juntos, sob uma mesma cultura, práticas, ferramentas e linguagens. Isso talvez soe óbvio, mas pense por um instante sobre como isso tradicionalmente é feito.

Responsabilidades Time de Operações

O time de operações é responsável por manter as coisas funcionando, garantindo confiança e alta disponibilidade. A forma mais simples de garantir isso, é prevenindo mudanças nos ambientes. O trabalho dos desenvolvedores é justamente o contrário, criar mudanças. Desde o início, os motivadores destas duas áreas sempre foram desalinhados. Os primórdios do movimento DevOps está ligado à ideia de derrubar os muros que historicamente sempre separaram estas duas equipes.

Por anos, talvez até décadas, administradores de sistemas têm escrito pequenos scripts – bash, perl, awk e sed – para automatizar operações repetitivas e de setups. Estes scripts são códigos, mesmo que estes códigos não sigam as mesmas práticas utilizadas pelos desenvolvedores. Normalmente eles não tem requisitos, processos formais de testes ou de deploy. Provavelmente nem estarão no controle de versão.

A importância da padronização dos códigos

Sem padrões, estes códigos são escritos em linguagens de programação diferentes das utilizadas nos códigos das aplicações. Possivelmente, fazendo até coisas que os desenvolvedores gostariam de reutilizar, porém eles sequer sabem que estes códigos existem. Se as duas áreas estivessem de fato trabalhando juntos, ao invés das rixas atuais, eles poderiam compartilhar conhecimentos, práticas e até mesmo seus códigos.

Automatizar as atividades manuais do time de infraestrutura é uma habilidade natural dos desenvolvedores este talvez seja um bom ponto de partida para iniciar a jornada do DevOps.

Conceito

Dispara o Build. Executa o Deploy. Manda rodar os testes unitários. Realiza testes automáticos de integração de ponta a ponta. Sobe máquinas virtuais. Todos estes processos são simples de serem definidos, a ponto dos sysadmins terem guias de implantação, FAQs e wikis de onde podem copiar, colar e substituir variáveis no trabalho do dia a dia.

Desenvolvedores automatizam coisas, isso é o que eles fazem. Então, por que não combinar o papel dos desenvolvedores (automação) com o de operações (deploy e sustentação)? Sobrepor estes papéis – automatizando testes e atividades do time de operações que fazem sentido, é a ideia básica do DevOps. Isso contraria ideias convencionais de processos de TI e de engenharia, onde termos como “separação de responsabilidades” levam a pensar que DevOps é uma coisa ruim. Da mesma forma que documentos de processos baseados no modelo cascata levam a pensar que Scrum ou processos ágeis também não são bons. Então é isso.

Formas de fazer DevOps:

Uma abordagem é simplesmente alternar desenvolvedores nos times de operações durante algumas semanas ou meses. A teoria é que programadores dentro dos times de operações colocarão os códigos-fonte no repositório, automatizarão tarefas rotineiras de forma inteligente, criarão bibliotecas de código reutilizáveis, substituirão a instalação de máquinas físicas por máquinas virtuais, criadas a partir de códigos, e assim por diante.

Outra forma de se fazer isso, é aumentar as responsabilidades de suporte dos times de desenvolvimento. Por exemplo, um time de desenvolvimento poderia assumir toda a responsabilidade, de compilação, promoção e suporte, alternando desenvolvedores na tarefa de suporte, a cada duas semanas.

Isso daria aos desenvolvedores uma ampla exposição sobre como seus códigos funcionam fora de suas máquinas, e também os ajudaria a sentir o peso de dar suporte nos códigos que escreveram. (Um pequeno grupo de operações ainda seria necessário para suportar os servidores de produção e banco de dados.)

Gerando builds automáticos:

Ferramentas de integração contínua são provavelmente as mais populares e mais utilizadas. Algumas empresas já estão gerando builds automáticos, porém os benefícios vão muito além dos passos de compilação. Pode incluir o registro de logs e a sinalização dos builds de acordo com os branchs, mantendo rastreabilidade entre código, demanda, build, testes, bugs, etc.

Uma vez que as atividades de build tenham sido completadas, é possível também executar os testes unitários – o tempo todo – e, então, de fato, implantar o software nos ambientes de desenvolvimento, teste e homologação. Ferramentas de integração contínua podem executar serviços web ou testes automatizados de interface para validar que as principais funcionalidade continuam funcionando com a integração do novo código. Isso ainda não é continuous delivery – o código não está sendo promovido automaticamente para o ambiente de produção a cada commit.

É importante encontrar rapidamente falhas para corrigir o mais rapidamente possível e limitar seus danos. Encontrar o problema quando ele é exposto a uma pequena parcela de usuários nem sempre pode ser possível – mas monitoramento visual pode ajudar.

Há uma grande quantidade de informações nos logs dos servidores – sobre o tempo de resposta de solicitações e quantidade de erros 404 e 500 o sistema está enfrentando. Ao visualizar essas falhas em gráficos, talvez usando ferramentas open source como o Graphite, os times pode ver os problemas assim que eles acontecem, agindo na solução.

Uma vez que o trabalho esteja completo, os passos de promoção para produção podem ser automatizados, sendo disparados a partir de controlados por páginas Web – ou, pelo menos, por linhas de comando. Quando o servidor de integração contínua executa um build, o sistema de continuous deployment precisa de ir apenas um passo além, para produção.

Deploys disparados por um clique de botão, permitem corrigir bugs com um clique de botão, que combinado com monitoramento do ambiente de produção, reduzir drasticamente o time-to-live (TTL) de um defeito.

Reduzindo o time-to-market:

Config flag é um mecanismo para reduzir ainda mais o time-to-live. Ao invés de ter que alterar o código de produção, o desenvolvedor muda seu código e coloca um bloco “if (feature) { }” em torno do novo código. Para desativar a funcionalidade, o desenvolvedor muda um arquivo no disco que armazena as flags como ligado ou desligado. Como isso não é uma alteração de código, não tem necessidade de executar novo build e deploy.

Imagine uma flag de configuração ainda mais específica, que diz quais usuários podem ter acesso às funcionalidades – assim, a funcionalidade pode ser habilitada apenas para funcionários, então seu acesso estendido também para a família dos funcionários, então para beta testes e clientes dispostos a assumir riscos e, então para clientes mais frequentes, e finalmente para o mercado corporativo e usuários avessos ao risco.

Os times podem disponibilizar novas funcionalidades de forma gradual, monitorando o sistema e pedindo feedbacks contínuos para os usuários – antes de liberar o acesso para o grande público. Enquanto a forma de implementar config flags pode variar, uma das opções chamada “Teste em Produção”, é descrita em detalhes no livro de 2008 “How We Test Software at Microsoft.”

As ideias descritas acima são em sua maioria conceitos; há muitas maneiras de implementá-las, utilizando tanto ferramentas comerciais quanto open source. Uma tática comum é criar parque de servidores virtuais em uma nuvem pública ou privada. Novos builds são criados, mas não implementados – então, o sistema altera o balanceamento de carga para a nova máquina. Isso cria um “flip” de serviço desconhecido para o usuário, e mantém o sistema antigo em volta, pelo menos por alguns minutos, no caso de algo bastante errado acontecer.

Configurar um conjunto de máquinas, reais ou virtuais, requer uma grande quantidade de scripts e automação – duas ferramentas foram projetadas para ajudar nessas atividades, e são comumente associadas com DevOps, são elas a Chef e a Puppet.

Talvez a coisa mais decepcionante de história do DevOps é a ideia de que DevOps é um novo papel, ou que ele cria um terceiro time, “a equipe de DevOps”. Enquanto alguns desenvolvedores podem optar por fazer automação de build/deploy ou trabalho de infraestrutura, a ideia era fazer com que as duas áreas trabalhassem em conjunto – e não criar mais um papel especializado que cuida de detalhes que sejam obscuros demais para outras pessoas entenderem ou se preocuparem.

Fonte: Computer World