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.

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.

     

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:

• Código Limpo, Robert Martin
• Codificadores Limpos, Robert Martin
• Refatoração, Martin Fowler
• Ferramenta Sonar Qube
• Ferramenta Source Monitor

---

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.