Plataformas em obsolescência que são gerenciadas por meio de processos manuais e morosos podem custar caro. É possível apresentar estudos a gerência baseados em horas perdidas em trabalho repetitivo e retrabalho causado por erro humano, em favor da introdução de técnicas modernas que utilizam ferramentas de automação e containeres. O resultado é um processo mais previsível com mínima intervenção de pessoas para se fazer o deploy com mais frequência e com maior confiabilidade.
Michael Jenkins, engenheiro de sistemas sênior na Walt Disney Company falou sobre a inserção de conceitos mais modernos em processos legados na Craft 2017. O InfoQ fez a cobertura da conferência com sessões de Q/A, resenhas e artigos.
Para mudar um processo legado a primeira coisa necessária é um estudo de caso. O artigo Injecting Modern Concepts into Legacy Processes de Michael Jenkins dá uma ideia de como fazer isso.
Uma forma de superar o fascínio por novas ferramentas e encontrar a ferramenta certa, é pensar nos aspectos mais problemáticos. O que está atrapalhando seu trabalho como desenvolvedor ou administrador de sistemas? O que tem quebrado frequentemente ao ponto que consertar isso se torna uma rotina dolorosa? Essa nova ferramenta ou tecnologia irá solucionar esses problemas? Se sim, como?
Além de pensar em corrigir problemas existentes, obter métricas que possam demonstrar como as coisas podem melhorar. Por exemplo, se um deploy manual leva horas, mas pode ser encurtado para alguns minutos com uma ferramenta de automação, isso é um aspecto que torna sua proposta interessante. Métricas também disponibilizam fatos para apoiar suas afirmações e responder as perguntas.
No final, será necessário montar um estudo de caso para responder o por quê mudanças são necessárias e como a produtividade pode aumentar.
O InfoQ entrevistou Michael Jenkins sobre como incluir técnicas modernas em processos legados.
InfoQ: Quais são os problemas principais de processos legados?
Michael Jenkins: Existem dois problemas principais com processos legados: débito técnico e trabalho manual. Muito frequentemente nossos processos legados estão ligados a uma versão específica de software ou sistema operacional e até mesmo hardware específico. Esse débito técnico torna mais difícil implementar melhorias nesse processo. Além disso, é muito comum que processos legados envolvam vários passos que requerem intervenção manual. Nesse caso, erro humano ocorre e pode causar problemas que poderiam ter evitados por meio da automação. De forma contrária aos processos manuais, quando liberamos desenvolvedores e administradores de sistemas de gerenciar tarefas manuais, eles ganham mais tempo para inovar.
InfoQ: Como é possível criar um 'estudo de caso' para modificar um processo?
Jenkins: A melhor maneira de se criar um 'estudo de caso' é focar nas partes do processo que custam muito na forma de tempo perdido ou lucratividade perdida. Isso pode ser difícil para alguns desenvolvedores e administradores, porque eles podem não saber o valor da aplicação ou sistema que eles gerenciam para a organização. Um aspecto que eles podem ter noção, é o tempo perdido por trabalhos repetitivos ou retrabalhos causados por erros humanos. Se eles puderem justificar a necessidade de implantar mudanças para a sua gerência, em termos de horas perdidas com problemas que acontecem frequentemente e que possam ser evitados, isso se torna uma boa base para um 'estudo de caso'. A gerência poderá interpretar as horas perdidas como custos desnecessários para a organização. Analogamente, se desenvolvedores ou administradores estiverem familiarizados com quaisquer dados relacionados ao faturamento proporcionado pela aplicação ou produto que eles trabalham, seria possível estimar o custo para a organização em ter aquela aplicação fora de operação.
InfoQ: Como socializar as mudanças para envolver as pessoas nesse processo?
Jenkins: Pode ser difícil envolver a equipe, caso a pessoa que inicia o processo aparente estar denunciando problemas e expondo a equipe a críticas, mas não precisa ser desta forma. Sugiro utilizar canais de comunicação já existentes como: reuniões com equipe ou individuais com líderes e gerentes. Desenvolvedores e administradores podem compartilhar suas experiências relacionadas aos problemas que precisam ser resolvidos; na verdade estes problemas serão a raiz do 'estudo de caso'. Por exemplo, eles podem disponibilizar o número de horas que eles despenderam resolvendo problemas que ocorrem repetidamente e impedindo que tarefas mais produtivas. Se a pessoa que estiver propondo as mudanças estiver disposta, a proposta pode ser compartilhada. Se o trabalho estiver sendo realizado em equipe, também pode ser útil obter informações com os membros da equipe. Em algumas situações o processo legado afeta múltiplas áreas da organização. Se esse for o caso, pode haver pessoas de outras equipes que podem suportar a iniciativa e demonstrar que existe ganho nos vários departamentos. A melhor abordagem e compartilhar experiências e encontrar aliados.
No seu blog, Jenkins dá um exemplo de como as equipes de operações e desenvolvimento podem colaborar e utilizar gerenciamento de desempenho da aplicação (Application Performance Management - APM) para investigar áreas em que melhorias são necessárias.
Adicionar APM pode aumentar a percepção sobre como a aplicação funciona e sobre o desempenho da infraestrutura envolvida. Se um problema ocorre e acarreta a interrupção do serviço, ambos desenvolvedores e administradores podem utilizar essa informação para identificar o que deu errado e criar um plano de ação que previna que este tipo de problema ocorra novamente.
Com o objetivo de identificar e resolver problemas, desenvolvedores e administradores de sistemas podem compartilhar um interesse comum e colaborar nesse sentido.
InfoQ: Foi apresentado como uma empresa evolui de um processo de deployment manual para automatizado. Quais foram os maiores obstáculos e como foram tratados?
O maior obstáculo foi não ter dividido o processo atual de build. Algumas pessoas gostam de comparar isso com "trocar os pneus de um carro em movimento" ou algo parecido com isso. De fato precisamos compreender quais partes do processo podem ser automatizadas e como elas podem ser trabalhadas em direção ao objetivo final sem quebrar nada. Lidamos com isso ao começar pensando pequeno e encontrando as partes do processo que poderiam ser alteradas, enquanto outras permaneceram inalteradas. Com o passar do tempo, pudemos partir para outra parte e para outra até que o processo todo fosse retrabalhado. Por exemplo, nosso processo de deploy era o mesmo para três aplicações diferentes hospedadas em três ambientes de produção diferentes. Devido a erros nos nomes dos servidores ou outros erros, não era incomum para um administrador de sistemas fazer o deploy de código nos servidores errados. Para resolver isso utilizamos a URL do repositório como uma entrada para o processo de deploy, automatizando a seleção do servidor a ser atualizado. Isso resolveu o problema. Após selecionar os servidores corretos, a próxima parte do processo de deploy pode ser automatizado. E assim por diante até que o processo estivesse o mais automatizado possível.
InfoQ: Quais benefícios eles tiveram por mudar o processo legado?
O maior benefício foi um processo previsível e consistente de deployment, pois agora a única variável de entrada necessária é a URL do repositório de código. Já que todos os passos subsequentes do processo foi automatizado, erro humano foi eliminado. Com a interação humana mantida em níveis mínimos, aqueles pontos em que erros poderiam desestabilizar o deployment foram removidos. Os benefícios advindos disso foram menor quantidade de tempo despendido em correções ou retrocessos de deployments e a possibilidade de se fazer o deploy mais frequentemente e de forma mais confiável. Isso liberou os administradores de sistemas, de modo que eles puderam inovar mais e contribuir em outras áreas.