Eu fiz / criei muitas apresentações relacionadas ao SCM e agora estou tentando "atualizar" para um sucessor do DevOps.

O que eu sempre tento fazer nas minhas apresentações é criar um slide de introdução que de alguma forma inclua a mensagem que eu quero entregar (e que depois elaborei no restante da minha apresentação). Ao fazer isso, tento responder à minha própria pergunta como "O que seriam de 1 a 3 frases que eu gostaria de usar se tivesse 10 a 20 segundos (apenas!) Para explicá-lo a alguém novo? * "

Eu pensei que sabia o que o DevOps realmente significa e do que se trata. Mas eu já vi alguns usos / contextos bizarros do DevOps (mesmo no DevOps.SE ...). Isso me faz pensar se talvez o que eu acho que seja o DevOps, esteja completamente errado.

Então, o que geralmente é aceito como a definição de DevOps?

DevOps em poucas palavras

Da Wikipedia :

DevOps (um composto cortada de " software DEV olvimento " e " tecnologia da informação OP peração S ") é um termo usado para se referir a um conjunto de práticas que enfatizam a colaboração e comunicação de ambos os desenvolvedores de software e tecnologia da informação (TI) profissionais Ao automatizar o processo de entrega de software e alterações na infraestrutura.

Seu objetivo é estabelecer uma cultura e um ambiente em que a construção , o teste e a liberação de software possam acontecer de forma rápida, frequente e mais confiável.

Da visão geral :

Diagrama de Venn mostrando o DevOps como a interseção do desenvolvimento (engenharia de software), operações e garantia de qualidade (QA)

Embora não exista uma "ferramenta" única para o DevOps, mas um conjunto de ferramentas, também conhecido como uma cadeia de ferramentas do DevOps :

Ilustração mostrando estágios em uma cadeia de ferramentas do DevOps

Ilustrações do DevOps

Abaixo estão algumas citações de algumas das perguntas sobre o DevOps.SE , que parecem encaixar / confirmar parte da descrição do DevOps acima:

• From ' Qual é a diferença entre SRE e DevOps? ':

  ... O DevOps é sobre manutenção de código ...

• De (uma resposta para) ' Como faço para contratar um bom DevOps, adequado à minha empresa? ':

  ... É comum acreditar que "DevOps" é um papel em uma empresa. A palavra apenas denota uma mudança organizacional nas empresas de software ...

• De ' Minha organização precisa adotar o Agile Soft. Dev. antes de adotar o DevOps? ':

  ... ainda existem organizações que não praticam Agile no desenvolvimento de software, que podem estar interessadas em adotar o DevOps ...

DevOps NÃO é uma função

Abaixo estão algumas citações de algumas das perguntas sobre o DevOps.SE , que parecem ilustrar que o DevOps NÃO é uma função:

• De (uma resposta para) ' Qual é a diferença entre o Sysadmin e o DevOps Engineer? ':

  ... O DevOps não é uma função (quando usado como tal, é mais um chavão do que uma função real).

• De (uma resposta para) ' Como faço para contratar um bom DevOps, adequado à minha empresa? ':

  ... É comum acreditar que "DevOps" é um papel em uma empresa. A palavra apenas denota uma mudança organizacional nas empresas de software ...

Pratico e aconselho no DevOps como consultor com diferentes clientes há quase cinco anos, antes de meu cargo atual, desempenhei funções no desenvolvimento de software, operações na Web e administração de sistemas. Na minha experiência pessoal , o DevOps tem muitos sabores.

Padrões de organização

Antipadrões do DevOps:

• NoOps e NoDevs - não estritamente DevOps no sentido mais estrito; no entanto, essas equipes criam e operam software sem uma linha divisória entre Desenvolvimento e Operações. Os desafios dessas equipes se resumem à maturidade. As equipes de desenvolvimento podem ser desenvolvedores de software especializadas, mas operadores iniciantes e vice-versa.

• The DevOps Bridge - é aqui que uma ou mais equipes têm a responsabilidade de trabalhar com as equipes de desenvolvimento e " produzi- las" para torná-las operacionais. O desafio se resume a agora que existem duas transferências, ou seja, Desenvolvimento → DevOps e DevOps → Operações.

• A equipe do DevOps - isso pode, sem dúvida, funcionar se a equipe tiver a responsabilidade de criar ferramentas que suportem o modelo operacional habilitado para DevOps; no entanto, provavelmente deve ser chamado de "equipe de ferramentas" ou "equipe da plataforma".

Padrões do DevOps:

• DevOps incorporado - mais conhecido como Platform Engineering, pelo qual existe alguém dentro da equipe responsável por fornecer automação, ferramentas e infraestrutura para o provisionamento e implantação da solução, às vezes também incluindo a operação do software - em minha mente , é o último que é realmente representativo do DevOps.

• DevOps institucionalizado - onde uma equipe de projeto é responsável pelo desenvolvimento e operação de um pacote de software, criando propriedade compartilhada e loops de feedback positivo.

Práticas

A prática real do DevOps se baseia em várias outras práticas, a saber:

• Entrega ágil
• Integração contínua
• Entrega Contínua
• Implantação Contínua

Cada uma das práticas acima se baseia na outra, é possível não seguir uma prática; no entanto, isso significa que um ciclo de feedback importante está faltando, o que pode ser indicativo de uma "oportunidade perdida". O principal diferencial entre seguir outras práticas e o DevOps é a operação do software em produção .

As Três Maneiras

No The Phoenix Project, Gene Kim e seus co-autores descrevem as três maneiras do DevOps :

Sistemas a pensar

O First Way enfatiza o desempenho de todo o sistema, em oposição ao desempenho de um silo de trabalho ou departamento específico - isso pode ser uma divisão tão grande (por exemplo, Desenvolvimento ou Operações de TI) ou tão pequena quanto um colaborador individual (por exemplo, , desenvolvedor, administrador do sistema).

Na minha experiência, começar a fazer com que os desenvolvedores considerem preocupações operacionais e requisitos não funcionais alcança esse objetivo. Isso faz parte dos aspectos culturais do DevOps.

Amplificação de Loops de Feedback

A segunda maneira é criar os loops de feedback da direita para a esquerda. O objetivo de quase qualquer iniciativa de melhoria de processo é reduzir e ampliar os loops de feedback para que as correções necessárias possam ser feitas continuamente.

Eu geralmente alcanço isso através da Integração / Entrega / Implantação Contínua e monitoramento e alerta compartilhados, portanto, ele se encaixa muito bem no componente de ferramentas do DevOps.

Cultura de Experimentação e Aprendizagem Contínuas

A Terceira Via trata da criação de uma cultura que promove duas coisas: experimentação contínua, correr riscos e aprender com o fracasso; e entender que repetição e prática são os pré-requisitos para o domínio.

Isso se encaixa muito no espaço da cultura , embora dependa fortemente de ferramentas e processos para permitir que a cultura cresça.

Ouvi muitas, diferentes definições de DevOps. Eles incluem:

• Desenvolvedores que lidam com tarefas de operações
• Uma pessoa que trabalha duas vezes mais (na mesma quantidade de tempo)
• Desenvolvedores e equipes de operações trabalhando uns com os outros
• As operações funcionam para ferramentas de desenvolvedor (na linha de "Web Ops")
• Um cargo para alguém que cria e mantém ferramentas de desenvolvedor
• O uso da automação nas operações
• O uso de nuvens públicas em operações
• Um trabalho que combina aspectos de operações, desenvolvimento e garantia de qualidade
• Um trabalho que envolve ajudar as equipes de desenvolvimento e operações a trabalharem juntas
• Uma filosofia de quebrar barreiras entre equipes
• Tratar infraestrutura como código
• O que você obtém quando ex-engenheiros de software entram em operação
• Um chavão completamente sem sentido

Não há consenso público sobre o que realmente é o DevOps . Alguns anos atrás, tivemos problemas semelhantes com o "Agile", e isso tem uma definição escrita .

Ao apresentar seus conceitos a um recém-chegado, eu me concentrei em apresentá-los, em vez de aplicar um rótulo, ou eles acabarão ouvindo definições conflitantes e confusos. Por exemplo, se você estiver tentando falar sobre infraestrutura como código , diga a eles que você está falando sobre infraestrutura como código. Quanto mais específico você for, melhor, pois mesmo com definições acordadas, a maioria das empresas se concentra mais em certas partes de uma filosofia.

A definição que eu sempre uso nessa situação é a seguinte:

“Uma cultura de criação de software que enfatiza a comunicação e a colaboração entre as equipes de desenvolvimento e operações de software, automatizando o processo de entrega de software e as mudanças na infraestrutura. O objetivo do DevOps é tornar o processo de criação, teste e implantação de software o mais frequente, rápido e possível. ”

No entanto, juntamente com a definição, também é importante que eles entendam POR QUE precisamos do DevOps. Diga a eles que o DevOps atenua os defeitos do software mais rapidamente, permite melhor gerenciamento de recursos, menos erros humanos, melhor controle de versão, ambiente operacional estável etc.

No artigo de pesquisa científica a seguir para explorar exatamente essa questão, "O que é DevOps", a definição derivada proposta de DevOps é:

O DevOps é uma metodologia de desenvolvimento que visa preencher a lacuna entre Desenvolvimento (Dev) e Operações (Ops), enfatizando a comunicação e colaboração, integração contínua, garantia de qualidade e entrega com implantação automatizada, utilizando um conjunto de práticas de desenvolvimento.

[Jabbari et al.] "O que é DevOps?: Um estudo de mapeamento sistemático de definições e práticas" (2016)

Devops é a prática de desenvolvimento de gravação de aplicativos cujo domínio comercial é operações. Onde a maioria do desenvolvimento de aplicativos se concentra na criação de aplicativos que prestam serviços financeiros, de saúde, logística ou vídeos para gatos, os devops se concentram em aplicativos que permitem compilações, implantações, monitoramento e coleta de métricas.

O objetivo primordial deve sempre ser permitir que os tomadores de decisão se tornem tomadores de decisão . Imagine o aplicativo móvel do seu banco. Quando você solicita uma transferência, isso acontece quando você aperta o botão. Você tomou uma decisão e a tomou . A mesma coisa com suas operações. Quando a pessoa apropriada decide que algum trabalho está pronto para ser implantado na produção, deve poder pressionar um botão e o item "Coisas certas acontecem". Da mesma forma, eles devem ter todas as informações necessárias para tomar decisões comerciais corretas.

Não se trata de dar às pessoas de negócios acesso shell aos servidores - esse é um objetivo confuso com a implementação. Trata-se de fornecer as alavancas e alavancas corretas com as informações certas e os trilhos de proteção certos para as pessoas certas, para que os tomadores de decisão sejam tomadores de decisão.