Olá, Habr! Apresento a sua atenção uma tradução do artigo "As origens do DevOps: o que há em um nome?" por Steve Mezak.

Dependendo do seu ponto de vista, o DevOps celebrará seu nono ou décimo aniversário este ano. Em 2016, o relatório State of the Cloud da RightScales observou que 70% das pequenas e médias empresas estão adotando práticas de DevOps. Todos os indicadores que compõem essa pontuação aumentaram desde então. Enquanto o DevOps se prepara para entrar na sua segunda década, seria ótimo dar um passeio no passado e retornar às origens do DevOps – e até mesmo às origens do próprio nome.

Antes de 2007: uma cadeia perfeita de eventos

Antes de 2007, uma série de circunstâncias deu origem ao que hoje é conhecido como DevOps.

Magro já provou ser a melhor prática. Também conhecido como Sistema de produção Toyota, o Lean Manufacturing se esforça para otimizar os processos na área de produção. (A propósito, a gestão da Toyota foi inicialmente inspirada nos métodos originais de linha de montagem introduzidos pela Ford Motor Company). Melhoria continua é o mantra da manufatura enxuta. Na prática, os seguintes caminhos são constantemente avaliados:

1. Manter os níveis de estoque de matérias-primas e produtos acabados ao mínimo. Manufatura enxuta significa uma quantidade mínima de estoque de matérias-primas para produzir bens e uma quantidade mínima de produtos acabados aguardando para serem encomendados ou enviados.
2. Minimizando a fila de pedidos. Idealmente, os pedidos recebidos passam imediatamente para o estado concluído. A principal métrica para a manufatura enxuta será sempre o tempo desde o recebimento do pedido até a entrega.
3. Maximizando a eficiência do processo de produção. A reengenharia de processos e a automação aprimorada estão se combinando para produzir produtos o mais rápido possível. Cada área de produção ao longo de todo o percurso (corte, soldagem, montagem, testes, etc.) é avaliada quanto a ineficiências.

No mundo da TI, os métodos tradicionais do modelo cascata de desenvolvimento de software já deram lugar a métodos iterativos rápidos, como Ágil. A velocidade era o grito de guerra, mesmo que a qualidade às vezes fosse prejudicada na busca por um rápido desenvolvimento e implantação. Da mesma forma, a computação em nuvem, em particular Infraestrutura como serviço (IaaS) e Plataforma como serviço (PaaS) provaram ser soluções maduras em processos e infraestrutura de TI.

Finalmente, kits de ferramentas começaram recentemente a aparecer para Integração contínua (CI). A ideia das ferramentas de CI nasceu e foi apresentada por Gradi Booch em 1991 em seu Método Booch.

2007-2008: Belga decepcionado

O consultor belga, gerente de projetos e práticas ágeis, Patrick Debois, aceitou uma nomeação de um ministério do governo belga para ajudar na migração do data center. Em particular, ele esteve envolvido em testes de certificação e prontidão. Suas responsabilidades exigiam que ele coordenasse e construísse relacionamentos entre equipes de desenvolvimento de software e equipes de servidores, bancos de dados e operações de rede. A sua frustração com a falta de coesão e os muros que separam os métodos de desenvolvimento e operação deixaram-no amargurado. O desejo de melhorar de Desbois logo o levou à ação.
Na conferência Agile de 2008 em Toronto, Andrew Schaefer propôs moderar uma reunião informal especialmente organizada para discutir o tópico "Infraestrutura ágil"E apenas uma pessoa veio discutir o assunto: Patrick DeBois. Sua discussão e troca de ideias avançaram o conceito de administração de sistemas ágeis. Nesse mesmo ano, DeBois e Schaefer criaram o grupo de administrador de sistemas ágeis de sucesso moderado no Google.

2009: O caso da cooperação entre Dev e Ops

Na conferência O'Reilly Velocity, dois funcionários do Flickr, o vice-presidente sênior de operações técnicas John Allspaw e o CTO Paul Hammond, fizeram a agora famosa apresentação "10 implantações por dia: colaboração de desenvolvimento e operações no Flickr".

A apresentação foi um drama, com Allspaw e Hammond reencenando as complexas interações entre representantes de Desenvolvimento e Operações durante o processo de implantação de software, completa com acusações e recriminações do tipo “Não é meu código, são todos os seus computadores!” A sua apresentação confirmou que a única opção sensata é que as atividades de desenvolvimento e implantação de software sejam contínuas, transparentes e totalmente integradas. Com o tempo, esta apresentação tornou-se lendária e agora é historicamente vista como um marco seminal quando a indústria de TI começou a exigir a metodologia conhecida hoje como DevOps.

2010: DevOps nos Estados Unidos da América

Com um número crescente de seguidores, a conferência DevOpsDays foi realizada pela primeira vez nos Estados Unidos, em Mountain View, Califórnia, imediatamente após a conferência anual Velocity. Avançando para 2018, há mais de 30 conferências DevOpsDays agendadas, incluindo dezenas nos Estados Unidos.

2013: Projeto "Fênix"

Para muitos de nós, outro momento digno de nota na história do DevOps foi a publicação do livro “The Phoenix Project” de Gene Kim, Kevin Behr e George Safford. Este romance conta a história de um gerente de TI que se encontra em uma situação desesperadora: ele tem a tarefa de resgatar um projeto crítico de comércio eletrônico que deu errado. O misterioso mentor do gestor – membro do conselho de administração apaixonado por métodos de manufatura enxuta – sugere novas formas para o personagem principal pensar em TI e desenvolvimento de aplicações, antecipando o conceito de DevOps. A propósito, “The Phoenix Project” nos inspirou a escrever o livro “Outsource or else...” sobre uma história de negócios semelhante em que um vice-presidente de software usa DevOps durante o desenvolvimento de um novo produto terceirizado importante.

DevOps para o futuro

Vale a pena descrever o DevOps como uma jornada, ou talvez uma aspiração, em vez de um destino final. O DevOps, assim como a manufatura enxuta, busca melhoria contínua, aumento de produtividade e eficiência e até implantação contínua. As ferramentas automatizadas para dar suporte ao DevOps continuam a evoluir.

Muito foi alcançado desde o início do DevOps na última década e esperamos ver ainda mais em 2018 e nos anos seguintes.

Fonte: habr.com