DevOps de novo sim :)

Por que todos ainda não adotaram DevOps, pelo menos do jeito certo?

Na parte 1 discutimos porque adotar DevOps e prometi que seguiríamos para algo mais concreto, mas antes uma pesquisa rápida, na sua organização:

• Quanto tempo, em média, leva para que uma solução de software chegue aos seus usuários?
• Com que frequência você entrega software em produção?
• Sobre as suas entregas de software, quantas delas apresentou alguma falha?
• E quanto tempo, em média, leva para corrigir essas falhas?

Se você estiver com dificuldades para responder essas perguntas, isso é perfeitamente normal, você ainda não tem DevOps!

De onde saíram essas perguntas? Essas são as quatro métricas chave desenvolvidas pela Dora, agora Google, na pesquisa realizada e publicada anualmente "State of DevOps".

O relatório “State of DevOps” se tornou, nos últimos anos, uma referência para avaliar o desempenho das empresas em relação as práticas do DevOps.

Quer saber mais sobre como a comunidade tem adotado DevOps?

Conheça mais sobre a iniciativa da Dora/Google e avalie seu desempenho em relação a indústria em beta.devops-research.com.

Você também pode ajudar participando do questionário da Developers Economics, o "State of the Developer Nation".

Se você não tem resposta para essas perguntas, lembre-se do ditado corporativo que diz “se você não mede, não pode gerenciar” - Peter Drucker. O que não é medido não pode ser melhorado e uma parte importante do DevOps está relacionanda aos ciclos de feedback e melhoria contínua.

Mas primeiro, como está seu código-fonte? Onde ele está? Como ele é compilado? Seus códigos-fonte são ativos (assets), mas tem pouco valor se você não conseguir executá-los.

No livro “Entrega Contínua, Como entregar software de forma rápida e confiável”, Humble e Farley definem o objetivo do livro:

O principal problema enfrentado pelos profissionais da área de desenvolvimento de software é: como transformar uma boa ideia em um sistema e entregá-lo aos usuários o quanto antes? Este livro mostra como resolver esse problema.

E realmente cumpre a promessa, recomendo como livro de cabeceira, mas quero destacar os princípios que os autores observaram:

• Crie um processo de confiabilidade e repetitividade de entrega de versão;
• Automatize quase tudo;
• Mantenha tudo sob controle de versão.

Os três princípios estão interligados. Para criar um processo confiável é necessário minimizar as intervenções manuais, o que leva a automação e ao controle de versão, então a primeira coisa que deveríamos nos preocupar é localizar e armazenar nosso código em um repositório e, em seguida, conhecer/definir um processo completo para compilar, configurar, implantar e testar a aplicação.

Pode parecer simples, mas se você está em um ambiente corporativo, com dezenas de equipes, tecnologias e sistemas mais velhos que você, isso pode ser um grande desafio.

Para minimizar esses desafios, a escolha de uma plataforma de CI/CD é importante e quando digo uma, quero dizer apenas uma. Múltiplas plataformas são um pesadelo para governança, segurança e manutenção, o que faz da escolha um desafio por si só, mas seja qual for o esforço valerá a pena.

É ideal que a plataforma esteja integrada com seu repositório, que forneça ferramentas de fluxo de trabalho (pipelines) e permita extrair os dados que você precisará para criar as métricas. Porém nem todas as métricas estarão no repositório ou pipeline, algumas virão da ferramenta de gestão, como quando a estória está com situação de pronta para a equipe desenvolver, outras virão da ferramenta de ITSM, como número de defeitos, gestão de mudança, etc.

Encontrar uma plataforma que tenha estas características já foi uma tarefa árdua, hoje em dia plataformas como Azure DevOps, CircleCI, GitLab, GitHub, para citar algumas, fornecem boa parte das ferramentas, integrações e informações que você precisa.

Plataformas de entrega contínua são commodities e você não deve gastar tempo administrando infraestrutura para mantê-las, escolha uma empresa que você confie e compre como serviço, essa é uma peça crítica da sua infraestrutura de desenvolvimento e não precisa consumir esforço dos seus desenvolvedores.

Outra questão que exigirá um razoável esforço é a padronização, utilizar uma única plataforma é um começo, mas será necessário usar os recursos da plataforma para manter coerência entre os pipelines. A criação de modelos de pipelines por linguagem, modelo de grupo de tarefas para segurança, testes e outras etapas importantes pode simplificar a adição de novas tarefas.

Um bom levantamento do processo de entrega do seu software, com a participação de todas as áreas envolvidas, incluindo gestão de mudança, irá oferecer uma oportunidade de criar um fluxo de trabalho que permitirá minimizar a intervenção humana sem perda de confiabilidade, tornando o processo de entrega uma tarefa simples e rápida.

A escolha de uma plataforma, seja qual for, é essencial, mas será necessário que seus desenvolvedores a dominem, automatizem tudo que for possível e padronizem o máximo. Não salte etapas, principalmente as de teste e segurança, sem elas o seu processo de entrega de software simplesmente não será confiável. Lembre-se, sem métricas não há como gerenciar o seu processo e melhorá-lo.

DevOps não é mais uma questão de opinião, é a forma profissional de entregar software de qualidade. Essa noção de processo bem controlado, com desvios mínimos de qualidade é uma realidade bastante tangível em outras indústrias, mas ainda algo a ser conquistado no desenvolvimento de software por causa da sua natureza única. Conforme nossa responsabilidade aumenta, com usos cada vez mais amplo do software, a margem para erros diminui a ponto de se tornar irresponsável não perseguir padrões mínimos de qualidade.

Na próxima parte discutiremos alguns desafios para implantar um processo no Azure DevOps para os pipelines de aplicação e infraestrutura.