Tutorial DevOps: Docker, Kubernetes e Azure DevOps

Neste artigo, aprenderemos sobre DevOps e como ele é diferente da metodologia Ágil. Também abordaremos algumas ferramentas populares de DevOps e seus papéis no ciclo de vida do DevOps.

Você Aprenderá

• O que é Docker, Kubernetes e Azure DevOps
• O que é DevOps e por que precisamos dele?
• Como o DevOps é diferente do Agile?
• Quais são algumas ferramentas importantes de DevOps?
• Como o Docker ajuda o DevOps?
• Como o Kubernetes ajuda o DevOps?
• Como o Azure DevOps ajuda o DevOps?
• O que é Integração Contínua e Entrega Contínua (CI/CD)?
• O que é Infraestrutura como Código?
• Como o Terraform e o Ansible ajudam o DevOps?

Docker

Docker é uma ferramenta de software de código aberto que é usada para construir, testar e implantar aplicativos conteinerizados. O que é Containerização, a propósito? Containerização é o conceito de agrupar todas as bibliotecas e arquivos junto com o código do aplicativo em uma única unidade chamada “Container”, para que ele possa ser executado em qualquer infraestrutura.

Kubernetes

Kubernetes é um sistema de orquestração de contêineres que gerencia aplicações e serviços conteinerizados. Ele cuida das tarefas realizadas no ambiente conteinerizado, como escalabilidade, implantação, balanceamento de carga, etc. O Kubernetes é portátil, eficiente e econômico, oferecendo recursos como integrações de sistema, suporte baseado em API, etc.

Azure DevOps

Azure DevOps é um produto da Microsoft que fornece uma ampla gama de ferramentas e recursos que tornam o processo de desenvolvimento e implantação de software mais rápido e organizado. Ele oferece um conjunto de processos que permite que desenvolvedores de software, gerentes de projeto e outros colaboradores trabalhem juntos para desenvolver software. Pode ser adicionado aos editores ou IDEs existentes para permitir que a equipe trabalhe de forma eficaz em projetos de todos os tamanhos.

Vamos começar com um caso de uso simples.

Cursos Gratuitos — Aprenda em 10 Passos

• Aprenda Docker em 10 Passos
• Aprenda Kubernetes em 10 Passos
• Aprenda AWS em 10 Passos

O que é DevOps?

Assim como acontece com a maioria dos jargões no desenvolvimento de software, não há uma definição aceita para DevOps.

As definições variam de simples, como a abaixo, a complexas, que podem ocupar uma página inteira de um livro.

DevOps é a combinação de filosofias culturais, práticas e ferramentas que aumenta a capacidade de uma organização de entregar aplicativos e serviços em alta velocidade — Amazon Web Services (AWS)

Em vez de tentar definir DevOps, vamos entender como o desenvolvimento de software evoluiu para DevOps.

Modelo Cascata

O Modelo Cascata é uma metodologia que segue uma abordagem estruturada. Consiste em seis fases: Requisitos, Design, Implementação, Testes, Implantação e Manutenção. Cada fase se baseia na conclusão da anterior. Ele progride por essas etapas sem revisitar processos anteriores, tornando-o um processo linear.

As primeiras décadas do desenvolvimento de software giravam em torno do modelo Cascata, e ele abordava o desenvolvimento de software da mesma maneira que você abordaria a construção de um projeto imobiliário — por exemplo, construir uma ponte.

Você construirá o software em várias fases que podem durar de algumas semanas a alguns meses.

Na maioria dos projetos em cascata, podem se passar meses antes que a empresa veja uma versão funcional de um aplicativo.

Elementos-chave para Construir um Ótimo Software

Ao trabalhar no modelo em cascata por algumas décadas, entendemos alguns elementos-chave no desenvolvimento de software de qualidade:

• Comunicação
• Feedback
• Automação

Importância da Comunicação

A comunicação entre as pessoas é essencial para o sucesso de um projeto de software.

No modelo em cascata, tentamos aprimorar a comunicação preparando documentos de mil páginas sobre Requisitos, Design, Arquitetura e Implantação.

No entanto, com o tempo, descobrimos que:

• A melhor maneira de aprimorar a comunicação dentro de uma equipe é reunir todos e obter uma variedade de habilidades na mesma equipe.
• Equipes multifuncionais – com uma ampla gama de habilidades – funcionam muito bem.

Importância do Feedback Precoce

Obter feedback rapidamente é importante. Construir um ótimo software é tudo sobre obter feedback rápido.

• Estamos construindo um aplicativo que atende às expectativas do negócio?
• Seu aplicativo terá problemas se for implantado em produção?

Você não quer descobrir isso depois de alguns meses. Você quer descobrir o mais cedo possível, porque quanto mais cedo encontrarmos um problema, mais fácil será corrigi-lo.

Descobrimos que as melhores equipes de software são estruturadas para possibilitar feedback rápido.

Importância da Automação

A automação é fundamental. O desenvolvimento de software envolve uma ampla gama de atividades. Fazer as coisas manualmente é lento e propenso a erros. Entendemos que é essencial sempre procurar oportunidades para introduzir automação.

Tendo entendido os elementos chave para desenvolver um ótimo software, vamos olhar como evoluímos para Agile e DevOps.

Evolução para Agile

Agile é uma abordagem que enfatiza o progresso incremental, feedback frequente e a capacidade de responder a requisitos em mudança ao longo do ciclo de desenvolvimento. Agile promove equipes multifuncionais que trabalham em ciclos de desenvolvimento curtos, o que favorece a melhoria contínua e entrega valor rapidamente aos usuários finais. Foi o primeiro passo na evolução para implementar nossos aprendizados com uma comunicação aprimorada entre as equipes, obtendo feedback e trazendo automação.

Agile reuniu as equipes de negócios e desenvolvimento em uma só equipe, que trabalha para construir ótimos softwares em pequenas iterações chamadas Sprints.

Ao invés de passar semanas ou meses em cada fase do desenvolvimento, Agile foca em pegar pequenos requisitos chamados histórias de usuários através do ciclo de desenvolvimento em poucos dias, às vezes dentro do mesmo dia.

Como o Agile Melhorou a Comunicação Entre as Equipes?

Agile trouxe as equipes de negócios e desenvolvimento juntas.

• As empresas são responsáveis por definir o que construir. Quais são os requisitos?
• O desenvolvimento é responsável por construir um produto que atenda aos requisitos. O desenvolvimento inclui todos os envolvidos no design, codificação, teste e embalagem do seu software.

No Agile, um representante do negócio, chamado Product Owner, está sempre presente com a equipe, e a equipe entende claramente os objetivos do negócio.

Quando a equipe de desenvolvimento não entende os requisitos e está seguindo pelo caminho errado, o Product Owner os ajuda a corrigir o curso e permanecer no caminho correto.

Resultado: O produto final que a equipe constrói é algo que o negócio quer.

Outro fator importante é que as equipes ágeis têm habilidades multifuncionais: habilidades de codificação (frontend, API e bancos de dados), habilidades de teste e habilidades de negócio. Isso melhora a comunicação entre as pessoas que precisam trabalhar juntas para construir um ótimo software.

Ágil e Automação

Quais são as áreas de automação nas quais as equipes ágeis se concentram?

Produtos de software podem ter uma variedade de defeitos:

• Defeitos funcionais significam que o produto não funciona conforme o esperado.
• Defeitos técnicos dificultam a manutenção do software. Por exemplo, problemas de qualidade de código.

Em geral, as equipes ágeis estão focadas em usar automação para encontrar defeitos técnicos e funcionais o mais cedo possível.

As equipes ágeis também se concentram extensivamente na qualidade do código. Ferramentas como SONAR são usadas para avaliar a qualidade do código das aplicações.

É suficiente ter ótimos testes de automação e ótimas verificações de qualidade de código? A chave é executar esses processos com frequência. As equipes ágeis enfatizam a Integração Contínua, onde os commits no controle de versão disparam uma série de ações. Isso inclui a execução de Testes Unitários, Testes de Automação e Verificações de Qualidade de Código, todos integrados de forma transparente em um Pipeline de Integração Contínua. Jenkins, uma ferramenta CI/CD amplamente adotada durante a era ágil inicial, desempenhou um papel fundamental na orquestração desses processos automatizados.

Como o Ágil Promoveu Feedback Imediato?

O fator mais importante é que um negócio não precisa esperar meses para ver o produto final. No final de cada sprint, o produto é apresentado a todas as partes interessadas, incluindo equipes de arquitetura e negócios. Todo feedback é considerado ao priorizar as histórias de usuário para o próximo sprint. Resultado: o produto final que a equipe constrói é algo que o negócio deseja.

Outro fator importante que possibilita feedback imediato é a integração contínua. Digamos que eu faça um commit de código no controle de versão. Em 30 minutos, recebo feedback se meu código causa uma falha nos testes unitários ou nos testes de integração. Receberei feedback se meu código não atender aos padrões de qualidade de código ou não tiver cobertura de código suficiente nos testes unitários.

O Ágil foi bem-sucedido? Sim. Com certeza. Ao focar na melhoria da comunicação entre as equipes de negócios e de desenvolvimento, e ao focar na identificação de uma variedade de defeitos precocemente, o Ágil levou o desenvolvimento de software para o próximo nível.

Tive uma experiência maravilhosa trabalhando com algumas equipes incríveis usando Agile. Engenharia de software, que para mim representa todos os esforços na construção de software, desde os requisitos até colocar aplicativos em produção, pela primeira vez, foi tão agradável quanto programar.

Mas a evolução para por aí? Não.

Novos desafios surgiram.

Evolução das Arquiteturas de Microsserviços

Começamos a nos mover em direção a uma arquitetura de microsserviços, e começamos a construir vários pequenos APIs em vez de construir grandes aplicações monolíticas.

Qual era o novo desafio?

As operações se tornaram mais importantes. Em vez de fazer um lançamento monolítico por mês, você está fazendo centenas de pequenos lançamentos de microsserviços toda semana. Depurar problemas em vários microsserviços e ter visibilidade do que está acontecendo com os microsserviços se tornou importante.

Era hora de uma nova palavra da moda no desenvolvimento de software. DevOps.

Emergência do DevOps

Qual era o foco do DevOps?

O foco do DevOps era melhorar a comunicação entre as equipes de desenvolvimento e operações.

• Como tornamos as implantações mais fáceis?
• Como tornamos o trabalho da equipe de operações mais visível para a equipe de desenvolvimento?

Como o DevOps Aprimorou a Comunicação Entre as Equipes?

O DevOps aproximou as equipes de operações das equipes de desenvolvimento.

• Nas empresas mais maduras, equipes de desenvolvimento e operações trabalhavam como uma equipe. Eles começaram a compartilhar objetivos comuns e ambas as equipes começaram a entender os desafios enfrentados pela outra equipe.
• Nas empresas, nos estágios iniciais da evolução do DevOps, um representante da equipe de operações pode estar envolvido nos sprints – reuniões e retrospectivas.

Quais São as Áreas de Automação nas Quais as Equipes de DevOps se Concentram?

Além das áreas de foco do Agile – Integração Contínua e automação de testes – as equipes de DevOps estavam focadas em ajudar a automatizar várias atividades da equipe de operações, como provisionamento de servidores, configuração de software em servidores, implantação de aplicativos e monitoramento de ambientes de produção. Alguns termos-chave são implantação contínua, entrega contínua e infraestrutura como código.

A implantação contínua é sobre implantar continuamente uma nova versão do software em ambientes de teste. Em organizações ainda mais maduras como Google e Facebook, a entrega contínua ajuda a implantar continuamente software em produção – talvez centenas de implantações de produção por dia.

Infraestrutura como código trata sua infraestrutura da mesma forma que você trata o código de sua aplicação. Você cria sua infraestrutura – servidores, balanceadores de carga e banco de dados – de forma automatizada usando configuração. Você controlaria a versão de sua infraestrutura – para que possa rastrear as mudanças em sua infraestrutura ao longo do tempo.

Como o DevOps Promoveu o Feedback Imediato?

DevOps reúne equipes de operações e desenvolvimento. Como operações e desenvolvimento fazem parte do mesmo time, toda a equipe entende os desafios associados às operações e ao desenvolvimento.

• Quaisquer problemas operacionais recebem atenção rápida dos desenvolvedores.
• Quaisquer desafios em colocar o software em produção recebem atenção precoce da equipe de operações.

DevOps incentiva integração contínua, entrega contínua e infraestrutura como código.

• Devido à entrega contínua, se eu fizer uma alteração de código ou uma alteração de configuração que possa quebrar um teste ou um ambiente de staging, eu saberia dentro de algumas horas.
• Devido à Infraestrutura como Código, os desenvolvedores podem auto provisionar ambientes, implantar código e encontrar problemas por conta própria sem ajuda da equipe de operações.

Vejo o Agile e o DevOps como duas fases que nos ajudam a melhorar como construímos ótimos softwares. Eles não competem entre si, mas juntos nos ajudam a construir produtos de software incríveis.

Na minha opinião, o objetivo do Agile e do DevOps juntos é fazer coisas que:

• Promovam a comunicação e o feedback entre negócios, desenvolvimento e equipes de operações
• Facilitem os pontos problemáticos com automação.

Uma História de DevOps

Aqui está um exemplo de história:

• Você é o desenvolvedor destaque em uma equipe e precisa fazer uma correção rápida.
• Você vai para um repositório do GitHub.
• Você rapidamente faz o check-out do projeto.
• Você rapidamente cria seu ambiente local.
• Você faz uma mudança. Você a testa. Você atualiza os testes de unidade e de automação.
• Você a comita.
• Você recebe um e-mail dizendo que foi implantado no QA.
• Alguns testes de integração são executados automaticamente.
• Sua equipe de QA recebe um e-mail pedindo aprovação. Eles fazem um teste manual e aprovam.
• Seu código está ao vivo em produção em poucos minutos.
• Você pode pensar que este é um cenário ideal. Mas, você sabia que isso é o que acontece em empresas inovadoras como Netflix, Amazon e Google dia após dia?

Esta é a história do DevOps.

DevOps = Desenvolvimento + Operações

DevOps é uma evolução natural do desenvolvimento de software. DevOps NÃO É APENAS uma ferramenta, um framework ou apenas automação. É uma combinação de tudo isso.

DevOps foca em pessoas, processos e produtos. A parte humana do DevOps é toda sobre cultura e criação de uma ótima mentalidade — uma cultura que promove comunicação aberta e valoriza feedback rápido, uma cultura que valoriza software de alta qualidade.

O Agile ajudou a fechar a lacuna entre as equipes de negócios e desenvolvimento. As equipes de desenvolvimento entenderam as prioridades do negócio e trabalharam com o negócio para entregar as histórias que proporcionam mais valor primeiro; no entanto, as equipes de dev e ops não estavam alinhadas.

Elas tinham objetivos diferentes.

• O objetivo da equipe de desenvolvimento é levar o maior número possível de novas funcionalidades para a produção.
• O objetivo da equipe de operações era manter o ambiente de produção o mais estável possível.

Como você pode ver, se levar as coisas para a produção é difícil, dev e ops estão desalinhados.

O DevOps tem como objetivo alinhar as equipes de dev e ops com metas compartilhadas.

A equipe de dev trabalha com a equipe de ops para entender e resolver desafios operacionais. A equipe de ops faz parte do time scrum e compreende as funcionalidades em desenvolvimento.

Como podemos tornar isso possível? Derrubando a parede entre dev e ops!

Reunindo Dev e Ops

Opção 1

Nas empresas DevOps maduras, dev e ops trabalham como parte do mesmo time scrum e compartilham as responsabilidades um do outro.

Opção 2

No entanto, se você está nos estágios iniciais da evolução do DevOps, como fazer para que dev e ops tenham objetivos comuns e trabalhem juntos?

Aqui estão algumas coisas que você pode fazer:

• Faça a equipe de desenvolvimento compartilhar algumas responsabilidades da equipe de operações. Por exemplo, a equipe de dev pode assumir a responsabilidade pelos novos lançamentos durante a primeira semana após a implantação em produção. Isso ajuda a equipe de desenvolvimento a entender os desafios enfrentados pelas operações ao colocar novos lançamentos em produção e ajuda todos a se unirem e encontrar soluções melhores.
• Outra coisa que você pode fazer é envolver um representante da equipe de operações nas atividades scrum. Envolve-os nas reuniões diárias e nas retrospectivas.
• A próxima coisa que você pode fazer é tornar os desafios enfrentados pela equipe de Operações mais visíveis para a equipe de Desenvolvimento. Quando você enfrentar desafios nas operações, faça com que as equipes de desenvolvimento façam parte das equipes que trabalham em soluções.

De qualquer forma que você seguir, encontre maneiras de quebrar a barreira e reunir as equipes de desenvolvimento e operações.

Outra opção interessante surge devido à automação. Ao usar Infraestrutura como Código e permitir autoaprovisionamento para desenvolvedores, você pode criar uma linguagem comum que as equipes de operações e desenvolvimento entendem — código.

Um Caso de Uso de DevOps

Considere a imagem abaixo:

Esta imagem apresenta dois fluxos de trabalho simples

1. Infraestrutura como Código usando Terraform e Azure DevOps para provisionar clusters Kubernetes.
2. Implantação Contínua de microsserviços usando Azure DevOps para construir e implantar imagens Docker para microsserviços em clusters Kubernetes.

Isso soa complexo?

Vamos decompor e tentar entendê-los.

Vamos começar com #2 — Implantação Contínua primeiro.

#2: Implantação Contínua de DevOps com Azure DevOps e Jenkins

Qual é a utilidade de ter ótimos testes e verificações de qualidade de código se você não os executa com frequência?

Qual é a utilidade da automação de implantação se você não implanta software com frequência suficiente?

Assim que um desenvolvedor comita código no sistema de controle de versão, os seguintes passos são executados:

• Testes Unitários
• Verificações de Qualidade de Código
• Testes de Integração
• Empacotamento de Aplicativos — Construindo uma versão implantável do aplicativo. Ferramentas — Maven, Gradle, Docker
• Implantação de Aplicativos — Colocando novos aplicativos ou novas versões do aplicativo ao vivo
• Um e-mail para a equipe de testes testar o aplicativo

Assim que houver aprovação da equipe de testes, o aplicativo é imediatamente implantado no próximo ambiente.

Isso é chamado de implantação contínua. Se você implanta continuamente até a produção, é chamado de entrega contínua.

As ferramentas de CI/CD mais populares são Azure DevOps e Jenkins.

#1: Infraestrutura como Código com Terraform

Antigamente, costumávamos criar ambientes e implantar aplicativos manualmente.

Toda vez que você cria um servidor, isso precisa ser feito manualmente.

• A versão do software precisa ser atualizada
• Correções de segurança precisam ser instaladas manualmente

Você faz manualmente, e os seguintes são os resultados:

• Alta chance de erros
• Os ambientes de replicação são difíceis

Infraestrutura como Código

Infraestrutura como Código — trate a infraestrutura da mesma forma que o código do aplicativo.

Aqui estão algumas das coisas importantes a entender com Infraestrutura como Código:

• A equipe de infraestrutura se concentra em trabalhos de valor agregado (em vez de trabalho rotineiro)
• Menos erros e rápida recuperação de falhas
• Os servidores são consistentes (evita derivação de configuração)

As ferramentas de IaC mais populares são Ansible e Terraform.

Normalmente, estes são os passos em IaC:

• Provisionamento de Servidores (Habilitado pela Nuvem) a partir de um modelo
• Instalar software
• Configurar software

Provisionamento de Servidor

Normalmente, ferramentas de provisionamento são usadas para provisionar servidores e preparar o novo servidor com capacidades de rede. As ferramentas de provisionamento mais populares são Cloud Formation e Terraform.

Usando o Terraform, você pode provisionar servidores e o restante da sua infraestrutura, como balanceadores de carga, bancos de dados, configuração de rede, etc. Você pode criar servidores usando imagens pré-criadas criadas com ferramentas como Packer e AMI (Amazon Machine Image).

Gerenciamento de Configuração

Ferramentas de gerenciamento de configuração são usadas para:

• Instalar software
• Configurar software

As ferramentas populares de gerenciamento de configuração são Chef, Puppet, Ansible e SaltStack. Estas são projetadas para instalar e gerenciar software em servidores existentes.

Papel do Docker e do Kubernetes no DevOps

No mundo de microsserviços, alguns microsserviços podem ser construídos com Java, outros com Python e outros com JavaScript.

Diferentes microsserviços terão maneiras diferentes de construir aplicações e implantá-las em servidores. Isso dificulta o trabalho da equipe de operações. Como podemos ter uma maneira semelhante de implantar vários tipos de aplicações? Entram os containers e o Docker.

Usando o Docker, você pode criar imagens de microsserviços — independentemente da linguagem. Você pode executar essas imagens da mesma maneira em qualquer infraestrutura. Isso simplifica as operações.

Kubernetes adiciona a isso ajudando a orquestrar diferentes tipos de contêineres e implantá-los em clusters.

Kubernetes também fornece:

• Descoberta de serviços
• Balanceamento de carga
• Configuração centralizada

Docker e Kubernetes facilitam o DevOps.

Métricas Importantes de DevOps

As seguintes são algumas das métricas importantes de DevOps que você pode acompanhar e melhorar ao longo do tempo.

• Frequência de Implantação — Com que frequência as aplicações são implantadas em produção?
• Tempo para o Mercado — Quanto tempo você precisa para levar uma funcionalidade da codificação à produção?
• Taxa de Falhas de Novos Lançamentos — Quantos dos seus lançamentos falham?
• Tempo de Resposta para Correções — Quanto tempo você precisa para fazer uma correção em produção e liberá-la?
• Tempo Médio de Recuperação — Quanto tempo você leva para recuperar seu ambiente de produção de um problema maior?

Melhores Práticas de DevOps

Gerenciamento de Projetos Ágeis

O gerenciamento de projetos ágeis é uma abordagem iterativa para desenvolver aplicações de software. Através dessa prática, as equipes podem aumentar a velocidade de desenvolvimento e responder bem às variadas necessidades dos clientes. A metodologia ágil é diferente do método tradicional Waterfall, onde havia longos ciclos de lançamento. O ágil utiliza os frameworks Scrum e Kanban para entregar o software de acordo com as necessidades do cliente.

Usando o Conjunto Certo de Ferramentas

Desenvolvedores de software e administradores de sistema precisam escolher e usar o conjunto certo de ferramentas DevOps em cada estágio do ciclo de vida DevOps para construir aplicações de alto valor.

Abaixo estão alguns exemplos de ferramentas que engenheiros DevOps, administradores de sistema e outros interessados podem usar:

1. Ferramentas como Jira podem ajudar a equipe a separar tarefas em partes menores e mais gerenciáveis, aumentando assim a produtividade da equipe.
2. Ferramentas como Jenkins e Bitbucket podem ajudar a automatizar fluxos de código desde o teste até a fase de implantação.
3. Ferramentas como Slack, GetFeedback, etc. podem ajudar as equipes DevOps a integrar ferramentas de chat com plataformas de pesquisa para coletar e revisar feedback em tempo real.

Integração Contínua/Entrega Contínua

A Integração Contínua (CI) e a Entrega Contínua (CD) são práticas modernas de desenvolvimento de software que ajudam as organizações a enviar software rapidamente e de forma eficaz. Com a CI, os desenvolvedores fazem commit continuamente do código do aplicativo em um repositório compartilhado várias vezes. Com a CD, o código é entregue à produção de forma rápida e sem problemas. CD também garante que a integração ocorra sem atrasos ou falhas.

Integrando Segurança

Segurança é uma parte importante do processo de desenvolvimento de software. No mundo atual, onde os crimes cibernéticos e incidentes de violação de dados estão em ascensão, as organizações estão percebendo a importância de integrar a segurança em seus sistemas. No passado, a segurança geralmente era considerada nas últimas fases do ciclo de vida do desenvolvimento de software, mas com o advento do DevSecOps, a segurança está sendo considerada e integrada desde o primeiro dia do desenvolvimento de aplicações.

Observabilidade

Observabilidade é importante ao desenvolver aplicações complexas que utilizam arquiteturas de microsserviços e nuvem. A observabilidade ajuda as equipes de DevOps a entender a estrutura complexa de diferentes aplicações (microsserviços, aplicativos de nuvem, etc.) e ajuda a atender às necessidades futuras do ambiente. Observabilidade com Kubernetes e Splunk são algumas das melhores plataformas de observabilidade.

Sinais de Maturidade DevOps

Como você mede a maturidade das suas implementações DevOps?

• O tempo levado do processo de desenvolvimento à implantação deve ser globalmente satisfatório
• Determinar a frequência do novo código implantado
• O Tempo Médio de Recuperação (MTTR) de um incidente ou evento inesperado deve ser o mais baixo possível
• Implantações bem-sucedidas devem superar as implantações com falhas
• Lançamentos mais rápidos e confiáveis devem gerar alto Retorno sobre o Investimento (ROI).

As Melhores Práticas de Transformação DevOps

• O apoio da liderança é fundamental
• Envolve custos iniciais
• Estabeleça COEs para ajudar as equipes
• Escolha a aplicação e equipe certas
• Comece pequeno
• Compartilhe aprendizados (boletins, comunicação, COEs)
• Estimule as pessoas com mentalidade de exploração e automação
• Reconheça as equipes de DevOps