O que é realmente DevOps?

Existem muitas definições para DevOps, a mais simples delas considera DevOps o modelo de organização de equipe única capaz de desenvolver e operar de forma contínua uma aplicação de software, apoiada por um conjunto de ferramentas que permitem em sequência e automaticamente a integração, teste e entrada em produção de código (como se de um pipeline se tratasse), onde o código, após várias etapas de aprovação, entra em produção, constituindo uma nova release.

Neste post, tentarei compartilhar a minha definição e algumas considerações pessoais sobre as implicações de decidir organizar a sua equipe de desenvolvimento num modelo DevOps.

DevOps também se define por um ciclo de trabalho contínuo, executado por uma única equipe, permitindo: a definição do produto, desenvolvimento do produto e operaçao ou manutenção desse mesmo produto. Estas três áreas, em colaboração, contribuem para o valor do produto em interações contínuas de feedback, inspeção, correção e melhoria do produto.
Na perspectiva do desenvolvimento, isso implica a continua integração de código, testes contínuos e a contínua entrada em produção, garantindo o modelo de desenvolvimento contínuo.
A implementação de DevOps exige investimento numa cadeia de ferramentas de software, mas é necessário ter disciplina para não fragmentar o conjunto de ferramentas de software inicialmente planeado para apoiar o desenvolvimento continuo. Manter um vasto conjunto de aplicações para garantir o pipeline automatizado pode tornar-se muito confuso, caro e difícil de manter um cenário em que cada equipe decida sobre o seu modus operandi, nao respeitando o conjunto de predefinido centralmente.
O DevOps também pode ser considerado um meio para atingir o fim: impulsionar a transformação Agile, a colaboração eficientedentro da equipa e entre equipas no desenvolvimento conjunto de produtos, a modernização de aplicações e uma forma de migrar aplicações para a Cloud.

DevOps é também o objetivo técnico de uma transformação Agile. Os ciclos contínuos de DevOps aumentam o valor entregue ao cliente, originando produtos de melhor qualidade, aumentando a produtividade da equipe e a sua motivação gracas à constatacao de terem uma capacidade de entrega independente, em ciclos disciplinados.

Porque ter uma equipe altamente qualificada durante o processo de transição para DevOps?

Quando organizamos uma Equipe de Desenvolvimento e queremos que se tornem auto-suficientes e independentes, precisamos ter certeza de que eles têm as competências necessárias para definirem os requisitos do produto, planearam a sua implementação considerando interdependências e cenários de complexidade incremental, exigindo flexibilidade de arquitetura e segurança para manter a integridade dos dados, garantindo o melhor desempenho possível e a melhor user experience. Será um desafio reunir uma equipe com estas capacidades, mas isto permitirá certamente atingir as metas de DevOps.

Planear DevOps

Implementar um processo e agrupar uma equipa DevOps é normalmente um processo demorado, exigindo mudanças em diferentes áreas da organização: processos, funções e fundamentalmente em níveis de qualidade para produzir e implantar software.

Essas razões exigem dos gestores e executivos uma permanente atualização de resultados e priorização do Roadmap estratégico de implementação do plano de transição para  DevOps. Este Roadmap deve responder a algumas questões:

  • O que pretendo atingir ao implementar o processo de desenvolvimento num modo DevOps? Mais qualidade? Velocidade na resposta a questões críticas? Velocidade a apresentar resultados a partir da implementação? Melhor gestão do processo de Build e Release? Melhor colaboração entre os diferentes níveis de suporte? etc…
  • Em que aplicações faz realmente sentido implementar DevOps?

Quando coloca estas questões, deve levar em consideração:

  • Complexidade das aplicações: será que faz sentido migrar de arquiteturas monolíticas em aplicações locais para aplicações na Cloud com modernas arquitecturas por exemplo baseadas em micro-serviços. Será que há capacidade de investimento para isso? Refactoring? Identificacao dos serviços prioritários?
  • Integração de sistemas legacy versus Transformação Digital
  • Brownfield / Greenfield – Se tomarmos o exemplo da indústria financeira, com muitas dessas aplicações monolíticas locais,  a mudança e o investimento em DevOps é grande, moroso e possivelmente doloroso.

Não há uma receita para um plano de transição para DevOps

Não há receita para um plano de transição de DevOps, é uma decisão séria. Como disse antes, isso implica mudanças profundas e custos. A minha recomendação é:
  • Analise a complexidade e a dependência do seu negócio relativamente às aplicacoes por onde pretende começar o processo de DevOps;
  • Pense sobre a prioridade e os serviços que fazem mais sentido adaptar, obtendo maior eficiência e redução de risco relativamente a ter uma aplicação crítica bloqueada durante uma o processo transição para o DevOps.
  • Avalie se vale a pena fazer grandes alterações na arquitetura em plataformas antigas ou apenas manter o sistema funcionando de uma forma elegante.
  • Faça mudanças cuidadosamente e aprenda mudança atrás mudanca se vale a pena continuar.
  • Talvez no seu negócio não faça sentido ter releases continuas, sem se comunicar e treinar antecipadamente os utilizadores para as novas funcionalidades. Pense nisso!

 

Medindo o Impacto

Em algumas organizações, a preparação planear o Roadmap de transição para DevOps é uma tarefa muito difícil, exigindo investimento e know-how, o que muitas vezes não está disponivel. Se por um lado deve planear com antecedência, também deve desenvolver um plano de DevOps com metas de curto prazo, inspecionando e corrigindo o mesmo regularmente.

Dirija o plano DevOps de uma forma holística, planei no curto prazo. A arquitetura flexível permitirá que você se adapte ou corrija mais rapidamente em seu produto.

Deixar uma resposta

Este site utiliza o Akismet para reduzir spam. Fica a saber como são processados os dados dos comentários.