O que é DevOps?

O conceito de DevOps – Development + Operation não é algo novo no mundo do desenvolvimento de software. Esta junção das duas palavras serve para indicar uma (re)união das práticas de desenvolvimentos com as de operação significando um fluxo contínuo sem hand-offs na entrega de um feature ou sistema.

Confira no texto de Marcelo Walter, líder do Agile Team da Objective, empresa parceira Liferay, os principais insights para compreender como surgiu o DevOps e insights valiosos para você obter sucesso nesta estratégia.

Um pouco de história…

Nos anos 90, em busca de uma falsa eficiência, processos de desenvolvimento foram redesenhados em função do tipo de trabalho a ser realizado. Responsabilidades foram definidas por práticas e não mais por entregas de valor. Tal modelo, baseado na indústria de manufatura, esperava que cada parte de um fluxo, trabalhando de forma especializada, fizesse com que o todo fosse mais eficiente gerando alta produtividade e qualidade ao final.

Nasciam assim os silos de Analistas, Devs BackEnd, Devs FrontEnd, Testers, Operação, etc. Ou seja, grupos que são extremamente eficientes na execução de suas atividades mas raras vezes possuem compromisso ou mesmo conhecimento do valor entregue ao final do processo.

Foi um modelo altamente formal e que trouxe um erro fundamental desde a concepção: desenvolvimento de software não tem analogia com produção industrial, pois não geram como produto entregas repetíveis ou provenientes de um conjunto similar de matérias primas (contextos iniciais).

Processos de construção de software são, na realidade, muito mais análogos a artesãos que empregam ações criativas organizadas para alcançar um resultado plenamente conhecido somente depois de pronto.

Infelizmente, tal modelo errôneo ainda potencializou seu impacto negativo pois justificava o seu fracasso como insuficiência de mais formalismo. Ou seja, para tentar ‘corrigir’ o resultado desastroso, aplicava-se mais prescrições, definições, protocolos e, assim, afastava ainda mais cada um do compromisso com o valor do que estava sendo feito.

Foi a Era do Processo pelo Processo.

Com o advento do mindset ágil de desenvolvimento, aliado ao movimento de foco no valor do cliente como força motora de qualquer negócio, uma luz se iluminou. Finalmente percebeu-se a incapacidade de modelos de silos conseguirem realmente entregar valor alinhado às expectativas mutantes dos usuários.

As principais armadilhas

Embora pareça óbvio e natural a reunificação do processo de desenvolvimento com operação, tal ação tem sido dolorosa para a maioria das empresas, especialmente em grandes organizações. Isso se deve pela alta especialidade que se buscou nas últimas décadas em atividades específicas, aliada à departamentalização destas. Na tentativa de romper tais barreiras, muitos líderes acabam tomando respostas não assertivas, que se traduzem em armadilhas:

1. Especialistas DevOps

O termo DevOps não deveria ser empregado para um profissional em específico. Cultura DevOps significa a capacidade de integrar a entrega junto com o desenvolvimento, ou seja, uma característica que um time deve ter e não determinadas pessoas. Assim, a busca deveria ser por pessoas capazes de, em time, entregarem seu desenvolvimento direto em produção. Especialistas devem priorizar a disseminação deste conhecimento para o time e o time ser o responsável pela entrega em si.

2. DevOps Team

Outro erro bem comum encontrado em muitas organizações é a criação de ‘times de DevOps’. Ou seja, criam times responsáveis por automatizar processos e suportar ferramentas utilizadas pelo time de desenvolvimento. Essa prática, da mesma forma que a armadilha citada anteriormente, não congrega o compromisso de integração do desenvolvimento com a entrega.

O ideal é que tal cultura esteja dentro de cada time de desenvolvimento e estes sejam os responsáveis pelas automações dos processos. É claro que esforços conjuntos entre os times são muito importantes para a eficiência, mas isso deve ser conduzido com o uso de guildas ou mesmo de projetos próprios de desenvolvimento.

3. Otimização Local

Muitas empresas acabam utilizando a cultura DevOps aplicando alto grau de automação como apoio às iniciativas ágeis dentro de alguns times específicos ou projetos. Tal abordagem, se aplicada a contextos restritos, provoca um efeito contrário ao que se espera: ao realizar a otimização local, invocam-se gargalos nas demais áreas ou mesmo casos de starvation (interrupções por falta de requisitos).

Estes cenários podem gerar mais conflitos ou distúrbios que por vezes causam o efeito contrário ao esperado, piorando a condição geral do time ou do projeto, em vez de melhorar.

Os 5 passos essenciais

Quando falamos em DevOps muitas dúvidas imediatamente aparecem: Como começar? Como tornar sustentável? Como escalar? Como evitar desperdícios?

Abaixo, você encontra alguns dos passos que fundamentais para o início da implantação de uma cultura DevOps em organizações, independente do tamanho destas. São os passos iniciais para que as demais práticas estejam embasadas e o crescimento seja algo contínuo, duradouro e com a melhor entrega de valor.

1. Comece pelo Fim – Testes Automatizados formam a base

A automação de testes foi uma das primeiras práticas criadas no advento das metodologias de transformação ágil. Contudo, ainda hoje, pouquíssimas empresas a empregam de forma eficaz. As automações e práticas DevOps dependem fortemente de que uma cultura de testes automatizados esteja presente na empresa. Comece com o que se tem hoje:

a. Implemente testes automatizados sobre bugs encontrados. Nenhum bug considera-se corrigido até ter um teste automatizado para reproduzi-lo

b.Implemente testes automatizados somente nas novas features desenvolvidas

c. Automatize os testes do legado de forma progressiva. Somente quando houver necessidade de alteração destes

d. Utilize schema evolution (técnica para criação automatizada de base de dados) para que seus testes não dependam de bases prévias

e. Adote frameworks que permitam robustez para a criação de scripts de testes

f. Não foque em testes que envolvam robôs ou telas do sistema. Ao contrário, testes unitários e funcionais são extremamente mais rápidos de construir, executar e são também mais robustos (fáceis de manter e escalar).

2. Evolua com consistência – Implemente pequenas mudanças, valide e defina

Para ter sucesso na aplicação de práticas DevOps, não tente mudar tudo de uma vez. Ao contrário, implemente apenas um processo/automação, passe a monitorar e medir este e depois vá para uma segunda evolução.

Tal qual os passos para a implantação de testes automatizados, cresça de forma consistente.

A regra é simples: para cada processo ou automação aplicada, todos os membros do time passam a utilizar este para que o mesmo seja realmente valoroso e estressado de forma a obter o melhor benefício. Se o time não conseguir evoluir com a melhoria, reconsidere e descarte. Não mantenha coisas que não tragam valor para o time.

3. One Click Principle – Padronização gera robustez 

Processos e automações são bastante sensíveis em ambientes heterogêneos. Por mais que se aceite ou até se valorize a independência dos times, quando esta se traduz em configurações individuais, isso se torna muito danoso para a inserção de práticas DevOps.

Para controlar isso, invista no desenvolvimento de mecanismos ‘One Click’, ou seja, sistemas capazes de, com apenas um click, montar uma estação completa e deixá-la operacional. Também com estes sistemas é possível montar ambientes de servidores, banco de dados, servidores de testes, e todo o conjunto de artefatos necessários para o ambiente de desenvolvimento utilizado. A padronização também fortalecerá a robustez uma vez que não fará mais sentido a frase ‘works on my machine’ uma vez que todos compartilham de uma mesma configuração e ambiente.

4. Ao Infinito e Além - Tudo na Nuvem

O advento da computação em nuvem tornou-se um grande aliado na evolução da cultura DevOps. A replicação de ambientes virtuais é muito mais rápida, segura e robusta. Além disso, evolução de memória, processamento, espaço e conectividade também deixaram de ser problemas críticos.

Invista sem medo nesta tecnologia. Existem diversas opções oferecidas e muitas ferramentas já prontas para facilitar os controles.

Com um bom controle, é possível deixar toda essa infraestrutura num custo real mais baixo que os de infra onsite e com a capacidade de escalabilidade praticamente infinita.

Não somente ambientes de produção, mas mesmo o desenvolvimento pode se utilizar destes benefícios e abrir os horizontes para práticas antes impossíveis. Imagine por exemplo você ter um ambiente completo de produção replicado para cada desenvolvedor e renovado a cada feature que este desenvolver.

5. Qualitividade – Autonomia, tempo e responsabilidade

O termo ‘qualitividade’ foi criado na Objective para indicar o tempo que cada um gasta para melhorar a sua própria produtividade. Não é o tempo para o desenvolvimento de produtos, mas sim melhorias para tornar o tempo produtivo o mais eficiente possível.

Para as práticas DevOps, isso é fundamental: todos os desenvolvedores terem disponibilidade para que possam ajudar na melhoria de seus próprios processos.

Quanto? Comece com 20% e vá aumentando de acordo com a necessidade.

Em observações vimos que 40% do tempo investido em melhorias é o que traz o maior benefício em termos de produtividade e qualidade para equipes de alta performance.

Este se traduz em melhoria direta para eficácia pois permite que o tempo real de desenvolvimento seja realmente valoroso e focado no que importa para a satisfação do cliente.

Texto originalmente publicado no blog da Objective