Eric Knorr, Infoworld/EUA
Publicada em 16 de fevereiro de 2017 às 11h48 em CIO
Se você ainda está intrigado sobre DevOps, permita-me fazer uma recomendação: Leia " The Devops Handbook ", de Gene Kim, Jez Humble, Patrick Debois e John Willis. É um livro cuidadosamente elaborado, preenchido com estudos de caso e conselhos práticos destinados a ajudá-lo a aumentar a produtividade na aplicação do DevOps.
Apenas uma seção é dedicada ao que os autores chamam de "técnicas práticas para o fluxo" do desenvolvimento às operações, também conhecido como entrega contínua. As outras seções abordam a coleta e incorporação de feedbacks do monitoramento de aplicativos - e, mais importante, a construção de aprendizagem contínua e experimentação na cultura das empresas. Segurança e conformidade também são tópicos abordados pelos autores.
Isso reflete com precisão a amplitude da tendência DevOps. Como dizem os autores, "Devops transforma o trabalho de tecnologia, assim como Lean transformou para sempre o trabalho de fabricação na década de 1980 ... Mas não é apenas um imperativo tecnológico. É um imperativo organizacional". O motor da transformação digital. Pressuposto para produzir uma empresa moderna e ágil.
Devops nas trincheiras
Mas a maioria dos profissionais de TI quer mesmo é saber sobre detalhes da entrega contínua, porque é impossível alcançar ganhos de produtividade DevOps sem automação e workflows melhorados. Recentemente falei com Armon Dadgar, co-fundador da Hashicorp, famosa por seu software Vagrant para criação de ambientes de desenvolvimento portátil. Ele quebra DevOps em sete elementos essenciais: construir, testar, empacotar, fornecer, manter seguro, implantar e monitorar.
Ora, você necessitaria desses mesmos elementos no método waterfall (em cascata). Então, o que há de diferente no DevOps? Ele diz: "O objetivo do DevOps é paralelizar o máximo possível. Esses sete passos são necessários e suficientes, mas não precisam ser feitos seqüencialmente". No método em cascata, o pessoal de operações processa o provisionamento e a implantação; os profissionais de segurança bloqueiam o(s) ambiente(s) em que os aplicativos serão executados; e desenvolvedores se ocupam de construir, testar e empacotar os aplicativos.
Dadgar também diz que os desenvolvedores devem ser responsáveis pelo monitoramento de aplicativos para cumprir um princípio-chave do DevOps - ou seja, os desenvolvedores devem manter a responsabilidade pelas aplicações em produção, em vez de delegar a tarefa aos profissionais de operações.
De acordo com Dadgar, um ponto crítico é o elemento de provisionamento. Especialmente em um mundo cada vez mais híbrido, onde é comum ter cinco provedores SaaS diferentes, outros de PaaS e IaaS híbrido. Como você provisionar e gerenciar essa complexidade, especialmente quando não há integração entre os fornecedores e seus produtos?
Para permitir um fluxo de trabalho paralelo neste novo mundo heterogêneo, Dadgar sugere a "desintermediação de todo o trabalho com software.A Hashicorp tem seu próprio conjunto de ferramentas para os sete elementos, mas eles são projetados para serem misturados e combinados com ferramentas que os clientes já podem ter.
Apesar de ter co-fundado a Hashicorp, Dadgar acredita que "DevOps é mais processo do que ferramenta. Acho que é isso que se perde no modo como está representado. Há uma fixação em ferramentas porque as ferramentas são fáceis, ao passo que é muito difícil mudar o processo organizacional. "
p
A visão realista
Qualquer tendência popular de TI eventualmente torna-se ridícula. DevOps já foi ridicularizado por colocar um fardo pesado para os desenvolvedores, por criar expectativas irrealistas sobre dev e ops finalmente se dando bem, e assim por diante.
Quando você começa, percebe claramente que DevOps é mais filosofia do que metodologia. Seu sucesso depende da cultura organizacional e as pessoas envolvidas mais do que das ferramentas ou receitas usadas passo a passo. Uma passagem particularmente reveladora do "The Devops Handbook" coloca assim:
"Temos um segredo sujo para revelar. Em muitos dos nossos estudos de caso, após a realização dos resultados apresentados, muitos dos agentes de mudança foram promovidos - mas, em alguns casos, houve uma mudança posterior na liderança que resultou em muitas das pessoas envolvidas deixando a empresa, acompanhado os processos de mudanças organizacionais ajudaram a criar".
Tal é a natureza da TI e das organizações em geral. Quando DevOps é feito certo os benefícios podem ser fenomenais. Mas é preciso liderança e uma vontade de assumir riscos e agitar as coisas - e um compromisso sustentado para que essas mudanças persistam.
Como Gene Kim notou na última Conferência de Negócios da DevOs, em novembro, existem cerca de 8 milhões de desenvolvedores e 8 milhões de pessoas no planeta - e, na melhor das hipóteses, 2% a 5% dessa população pode estar usando princípios e práticas de DevOps. Para Kim, dado o enorme potencial de produtividade, isso soa como trilhões de dólares perdidos. Ele pode estar certo.
- See more at: http://cio.com.br/tecnologia/2017/02/16/qual-e-o-verdadeiro-significado-de-devops/#sthash.ieXiIMbI.dpuf
Nenhum comentário:
Postar um comentário