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:
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.
