Tutorial de DevOps: Docker, Kubernetes e Azure DevOps

Neste artigo, aprenderemos sobre DevOps e como ele é diferente da metodologia Agile. Também cobriremos 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 utilizada para construir, testar e implantar aplicações em contêineres. O que é Containerização, a propósito? Containerização é o conceito de agrupar todas as bibliotecas e arquivos junto com o código da aplicação em uma única unidade chamada “Contêiner”, para que possa ser executada em qualquer infraestrutura.

Kubernetes

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

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 das palavras da moda 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 abranger uma página completa de um livro.

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

Em vez de tentar definir o DevOps, vamos entender como o desenvolvimento de software evoluiu para o 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 abordavam o desenvolvimento de software da mesma forma que você abordaria a construção de um projeto imobiliário — por exemplo, construir uma ponte.

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

Na maioria dos projetos cascata, seriam necessários meses antes que a empresa visse uma versão funcional de um aplicativo.

Elementos Chave para Construir um Ótimo Software

Enquanto trabalhávamos no modelo cascata por algumas décadas, entendemos alguns elementos-chave em torno do desenvolvimento de ótimos softwares:

• 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 Cascata, tentamos melhorar a comunicação preparando documentos de 1000 páginas sobre Requisitos, Design, Arquitetura e Implantação.

Mas, ao longo do tempo, descobrimos que:

• O melhor modo de melhorar a comunicação dentro de uma equipe é reuni-los. E reunir 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 ótimos softwares é 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, pois 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 é crítica. O desenvolvimento de software envolve uma ampla gama de atividades. Fazer as coisas manualmente é lento e propenso a erros. Compreendemos que é essencial sempre procurar oportunidades para introduzir automação.

Tendo compreendido os elementos-chave para desenvolver um ótimo software, vamos ver 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 de valor aos usuários finais rapidamente. Foi o primeiro passo na evolução para implementar nossos aprendizados com uma comunicação aprimorada entre equipes, recebendo feedback e trazendo automação. 

Agile uniu as equipes de negócios e desenvolvimento em uma única equipe, que trabalha para construir um ótimo software em pequenas iterações chamadas Sprints.

Em vez de passar semanas ou meses em cada fase do desenvolvimento, Agile foca em levar pequenos requisitos chamados histórias de usuário pelo ciclo de desenvolvimento em poucos dias, às vezes no mesmo dia.

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

Agile uniu as equipes de negócios e desenvolvimento.

• 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 dos negócios, chamado de 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 fazer uma correção de curso e permanecer no caminho correto.

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

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ócios. Isso melhora a comunicação entre pessoas que precisam trabalhar juntas para construir um ótimo software.

Ágil e Automação

Em quais áreas de automação as equipes ágeis se concentram?

Os produtos de software podem ter uma variedade de defeitos:

• Defeitos funcionais significam que o produto não funciona conforme o esperado.
• Defeitos técnicos tornam a manutenção do software difícil. 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 acionam 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 contínua em um Pipeline de Integração Contínua. Jenkins, uma ferramenta de 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 uma empresa 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 o feedback é considerado enquanto se priorizam as histórias de usuário para o próximo sprint. Resultado: o produto final que a equipe constrói é algo que a empresa deseja.

Outro fator importante que possibilita feedback imediato é a integração contínua. Digamos que eu faça um commit de algum código no controle de versão. Dentro de 30 minutos, recebo feedback se meu código causa uma falha em um teste unitário ou em um teste 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 se concentrar em melhorar a comunicação entre equipes de negócios e desenvolvimento, e focar em encontrar uma variedade de defeitos precocemente, o Ágil levou o desenvolvimento de software a um novo nível.

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

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

Novos desafios surgiram.

Evolução das Arquiteturas de Microsserviços

Começamos a nos movimentar em direção a uma arquitetura de microsserviços, e começamos a construir várias APIs pequenas 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 obter visibilidade sobre o que está acontecendo com os microsserviços se tornou importante.

Estava na 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.

• Em empresas mais maduras, as equipes de desenvolvimento e operações trabalharam como uma só equipe. Elas começaram a compartilhar objetivos comuns e ambas as equipes passaram a entender os desafios que a outra equipe enfrentava.
• Nas empresas, nas fases iniciais da evolução do DevOps, um representante da equipe de operações pode estar envolvido nos sprints — reuniões diárias e retrospectivas.

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

Além das áreas de foco do Agile — Integração Contínua e automação de testes — as equipes DevOps se concentraram 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. Algumas terminologias chave são implantação contínua, entrega contínua e infraestrutura como código.

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

A infraestrutura como código trata de tratar sua infraestrutura como você trata seu código de aplicação. Você cria sua infraestrutura — servidores, balanceadores de carga e banco de dados — de uma maneira automatizada usando configuração. Você controlaria a versão da sua infraestrutura — para que possa rastrear as alterações de sua infraestrutura ao longo do tempo.

Como o DevOps promoveu 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 rápida atenção dos desenvolvedores.
• Quaisquer desafios em colocar o software em produção recebem a atenção precoce da equipe de operações.

O DevOps incentiva a 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.
• Por conta da Infraestrutura como Código, os desenvolvedores podem autoprovisionar ambientes, implantar código e encontrar problemas por conta própria sem precisar da ajuda da equipe de operações.

Eu vejo o Ágil 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.

No que me diz respeito, o objetivo do Ágil e do DevOps juntos é fazer coisas que:

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

Uma História de DevOps

Aqui está um exemplo de história:

• Você é o desenvolvedor estrela em uma equipe e precisa fazer uma correção rápida.
• Você vai para um repositório do GitHub.
• Você rapidamente faz o checkout do projeto.
• Você rapidamente cria seu ambiente local.
• Você faz uma alteração. Você testa. Você atualiza os testes unitários e de automação.
• Você o submete.
• 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 solicitando aprovação. Eles fazem um teste manual e aprovam.
• Seu código está ao vivo em produção em questão de minutos.
• Você pode pensar que este é um cenário ideal. Mas, você sabe que isso é o que está acontecendo 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 todos esses elementos.

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

O ágil ajudou a fechar a lacuna entre os negócios e as equipes de desenvolvimento. As equipes de desenvolvimento compreenderam as prioridades dos negócios e trabalharam com os negócios para entregar as histórias que proporcionam mais valor primeiro; no entanto, as equipes de desenvolvimento e operações não estavam alinhadas.

Eles tinham objetivos diferentes.

• O objetivo da equipe de desenvolvimento é levar o maior número possível de novos recursos para 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.

DevOps visa alinhar as equipes de dev e ops com objetivos compartilhados.

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

Como podemos tornar isso possível? Quebre a barreira entre dev e ops!

Reunindo Dev e Ops

Opção 1

Em empresas de DevOps maduras, dev e ops trabalham como parte da mesma equipe scrum e compartilham as responsabilidades uns dos outros.

Opção 2

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

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

• Faça com que a equipe de desenvolvimento compartilhe algumas das responsabilidades da equipe de operações. Por exemplo, a equipe de dev pode assumir a responsabilidade por novos lançamentos na primeira semana após a implantação na produção. Isso ajuda a equipe de desenvolvimento a entender os desafios enfrentados pelas operações ao levar novos lançamentos ao vivo e os ajuda a se unir e encontrar melhores soluções.
• Outra coisa que você pode fazer é envolver um representante da equipe de operações nas atividades do scrum. Envolva-os em reuniões rápidas e 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 quaisquer desafios nas operações, inclua as equipes de desenvolvimento nos times que trabalham nas soluções.

De qualquer maneira que você escolher, encontre formas de quebrar a barreira e unir a equipe de desenvolvimento e operações.

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

Um Caso de Uso de DevOps

Considere a imagem abaixo:

Esta imagem mostra dois fluxos de trabalho simples

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

Isso parece complexo?

Vamos dividir e tentar entendê-los.

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

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

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

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

Assim que um desenvolvedor comita o 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 — Construir uma versão implantável da aplicação. Ferramentas — Maven, Gradle, Docker
• Implantação de Aplicativos — Colocar novas aplicações ou novas versões da aplicação em produção
• Um e-mail para a equipe de testes testar a aplicação

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ê implantar 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 de DevOps como Código com Terraform

No passado, costumávamos criar ambientes e implantar aplicações manualmente.

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

• A versão do software precisa ser atualizada
• Patches de segurança precisam ser instalados 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 da aplicação.

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

• A equipe de infraestrutura se concentra em trabalhos de valor agregado (em vez de trabalhos de rotina)
• Menos erros e recuperação rápida de falhas
• Os servidores são consistentes (evita desvio 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 deixar o novo servidor pronto 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 de gerenciamento de configuração populares são Chef, Puppet, Ansible e SaltStack. Estas são projetadas para instalar e gerenciar software em servidores existentes.

Papel do Docker e Kubernetes no DevOps

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

Diferentes microsserviços terão diferentes formas de construir aplicativos e implantá-los em servidores. Isso torna o trabalho da equipe de operações difícil. Como podemos ter uma forma semelhante de implantar vários tipos de aplicativos? Entram os contêineres e o Docker.

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

O Kubernetes adiciona a isso ajudando a orquestrar diferentes tipos de containers e implantando-os em clusters.

O Kubernetes também fornece:

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

O Docker e o 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 um recurso da codificação para a produção?
• Taxa de Falha de Novos Lançamentos — Quantos dos seus lançamentos falham?
• Tempo de Resolução — Quanto tempo você precisa para fazer uma correção de produção e liberá-la para a produção?
• Tempo Médio de Recuperação — Quanto tempo você leva para recuperar seu ambiente de produção de um problema importante?

Práticas Recomendadas de DevOps

Gestão Ágil de Projetos

A gestão ágil de projetos é uma abordagem iterativa para desenvolver aplicações de software. Através dessa prática, equipes podem melhorar a velocidade de desenvolvimento e responder bem às necessidades variadas dos clientes. A metodologia ágil é diferente do método tradicional em cascata, no qual havia longos ciclos de lançamento. O ágil utiliza os frameworks Scrum e Kanban para entregar o software conforme as necessidades do cliente.

Usando o Conjunto Certo de Ferramentas

Desenvolvedores de software e administradores de sistemas precisam escolher e utilizar o conjunto certo de ferramentas DevOps em cada etapa do ciclo de vida do DevOps para construir aplicativos de alto valor.

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

1. Ferramentas como Jira podem ajudar a equipe a segmentar tarefas em partes menores e mais gerenciáveis, o que ajuda a aumentar a produtividade da equipe. 
2. Ferramentas como Jenkins e Bitbucket podem ajudar a automatizar fluxos de código desde os testes até a fase de implantação.
3. Ferramentas como Slack, GetFeedback, etc., podem ajudar 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 commitam continuamente o código do aplicativo em um repositório compartilhado várias vezes. Com a CD, o código é entregue à produção rapidamente e sem problemas. A CD também garante que a integração aconteça sem atrasos ou problemas.

Integrando Segurança

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

A 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 em nuvem, etc.) e ajuda a atender às necessidades futuras do ambiente. A observabilidade do Kubernetes e o Splunk estão entre as melhores plataformas de observabilidade.

Indicadores de Maturidade do DevOps

• Como você mede a maturidade das suas implementações do DevOps?
• O tempo decorrido desde o processo de desenvolvimento até a implantação deve ser globalmente satisfatório
• Determinar a frequência da nova implantação de código
• O Tempo Médio de Recuperação (MTTR) de um incidente ou evento inesperado deve ser o mais baixo possívelAs implantações bem-sucedidas devem superar as falhas.
• Lançamentos mais rápidos e confiáveis devem resultar em alto Retorno sobre o Investimento (ROI).

Práticas Recomendadas para 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 informativos, comunicação, COEs)
• Estimule as pessoas com mentalidade de exploração e automação
• Reconheça as equipes DevOps