O que é DevOps? O guia definitivo

Como funciona o DevOps?

DevOps é uma metodologia que visa melhorar o trabalho ao longo do ciclo de vida de desenvolvimento de software. Você pode visualizar um processo DevOps como um loop infinito, compreendendo estas etapas: planejar, codificar, construir, testar, lançar, implantar, operar, monitorar e, por meio de feedback, planejar, o que redefine o loop.

Idealmente, DevOps significa que uma equipe de TI escreve software que atenda perfeitamente aos requisitos do usuário, implemente-o sem perda de tempo e execute de maneira ideal na primeira tentativa. As organizações usam uma combinação de cultura e tecnologia para atingir esse objetivo.

Para alinhar o software com as expectativas, os desenvolvedores e as partes interessadas comunicam-se sobre o projeto, e os desenvolvedores trabalham em pequenas atualizações que são implantadas independentemente umas das outras.

Para evitar tempos de espera, as equipes de TI usam pipelines de CI/CD e outras automações para mover o código de uma etapa de desenvolvimento e implantação para outra. As equipes analisam as alterações imediatamente e podem aplicar políticas para garantir que as versões atendam aos padrões.

É fácil escrever software rapidamente; escrever software que funcione é outra história. Para implantar um bom código na produção, os apoiadores do DevOps usam contêineres ou outros métodos para fazer o software se comportar da mesma maneira, desde o desenvolvimento até o teste e a produção. Eles implementam mudanças individualmente para que os problemas sejam rastreáveis. As equipes contam com o gerenciamento de configuração para obter ambientes consistentes de hospedagem e implantação. Os problemas que descobrem nas operações ao vivo levam a melhorias no código, muitas vezes por meio de investigação post-mortem impecável e canais de feedback contínuos.

Os desenvolvedores podem oferecer suporte a software ativo, o que coloca sobre eles a responsabilidade de abordar as considerações de tempo de execução. Os gerentes de operações de TI podem participar de reuniões de design de software, oferecendo orientação sobre como usar os recursos de forma eficiente e segura. Qualquer um pode contribuir para a realização de autópsias inocentes. Quanto mais esses especialistas colaboram e compartilham habilidades, mais podem promover uma cultura DevOps.

Que problemas o DevOps resolve?

Cada empresa enfrenta seus próprios desafios, mas os problemas comuns incluem lançamentos que demoram muito, software que não atende às expectativas e TI que limita o crescimento dos negócios.

Sem tempos de espera, processos manuais e revisões demoradas, um projeto DevOps passa dos requisitos para o software ativo com mais rapidez. Tempos de ciclo mais curtos podem impedir que os requisitos mudem para que o produto entregue o que os clientes desejam.

DevOps resolve problemas de comunicação e prioridade entre especializações de TI. Para criar software viável, as equipes de desenvolvimento devem compreender o ambiente de produção e testar seu código em condições realistas. Uma estrutura tradicional coloca as equipes de desenvolvimento e operações em silos. Isso significa que os desenvolvedores ficam satisfeitos quando seu código oferece funcionalidade —e se o lançamento falhar na produção, cabe à equipe de operações corrigir os problemas.

Com uma cultura DevOps, os desenvolvedores não recorrem à resposta “funcionou na minha máquina” quando surge um problema. As mudanças implementadas na produção são pequenas e reversíveis. Além disso, toda a equipe entende as mudanças, o que simplifica muito o gerenciamento de incidentes.

Com um processo mais rápido desde a ideia até o software real, as empresas podem aproveitar as oportunidades de mercado. Dessa forma, o DevOps proporciona uma vantagem competitiva às empresas.

A evolução do DevOps

Patrick Debois, consultor de desenvolvimento de software, é responsável pela criação do termo DevOps em 2009 ao nomear uma conferência como DevOps Days. O DevOps resolveu uma deficiência da metodologia ágil de desenvolvimento de software: o desenvolvimento rápido e iterativo de código não levava necessariamente à implantação rápida e iterativa de código.

Simultaneamente ao aprofundamento do Agile nas operações, os administradores de TI ficaram irritados com as etapas de gerenciamento de mudanças, às vezes trabalhosas e excessivamente complexas, na estrutura ITIL. A ITIL defende uma TI estável, confiável e previsível, enquanto o Agile defende a colaboração e a mudança. O DevOps tocou as pessoas de ambos os lados. Na verdade, as organizações podem usar tanto ITIL quanto DevOps, especialmente se adotarem a nuvem.

O conceito de DevOps foi então popularizado com o livro The Phoenix Project em 2013. O Phoenix Project usa uma narrativa fictícia para ilustrar problemas endêmicos e ajudar os gerentes de TI a compreender os conceitos e benefícios da colaboração e das tecnologias compartilhadas.

Os primeiros proponentes do DevOps incluíam estes atores-chave:

• Debois e seu colaborador Andrew Clay Shafer;
• autores do Projeto Phoenix , Gene Kim, Kevin Behr e George Spafford;
• Paul Hammond e John Allspaw, pioneiros influentes do Flickr;
• os pioneiros da entrega contínua Jez Humble e Dave Farley;
• o defensor da conteinerização John Willis; e
• organizadores do Relatório State of DevOps, incluindo Alanna Brown e Nicole Forsgren.

À medida que o DevOps se tornou popular, as organizações formalizaram suas abordagens. A Retailer Target criou o método de treinamento DevOps Dojo, por exemplo. Os fornecedores elogiaram os recursos de habilitação de DevOps em ferramentas, desde chatbots de colaboração até suítes de CI/CD integradas em serviços em nuvem. “Engenheiro DevOps” logo surgiu como um título de trabalho.

O DevOps continua a evoluir, à medida que a inteligência artificial surge para ajudar em tudo, desde a criação de código até o gerenciamento de incidentes. IA para DevOps (ou AIOps ) significa automação mais inteligente e prazos de entrega ainda mais curtos, incluindo traduções perfeitas das necessidades de negócios para ofertas de tecnologia —mas ainda existem muitas barreiras antes que isso se torne realidade.

Embora o DevOps tenha alcançado um status generalizado, nem todos que o adotam são totalmente convertidos para o DevOps. Muitos confiam numa abordagem DevOps para projetos de TI geradores de receitas, onde vêem um retorno do investimento em ferramentas e competências de ponta. Para muitos serviços internos de TI que são relativamente estáveis e maduros, o DevOps não oferece benefícios significativos.

Metodologias, princípios e estratégias

O DevOps está associado ao desenvolvimento ágil de software porque profissionais ágeis promoveram o DevOps como uma forma de estender a metodologia à produção. A abordagem foi até rotulada como uma contracultura às práticas de gerenciamento de serviços de TI defendidas no ITIL. DevOps não possui uma estrutura oficial.

Para refinar suas estratégias, as organizações devem compreender os contextos relacionados de DevOps, desenvolvimento ágil e em cascata, engenharia de confiabilidade de sites (SRE) e SysOps, e até mesmo as variações dentro de DevOps.

DevOps versus Cascata. O desenvolvimento em cascata compreende uma série de etapas e portões em uma progressão linear em direção à produção. Suas fases são requisitos, análise, design, codificação e implementação, testes, operação e implementação e manutenção. Nas equipes Waterfall, o desenvolvimento testa o novo código em um ambiente isolado para garantia de qualidade (QA) e, se os requisitos forem atendidos, libera o código para operações para uso na produção. As operações de TI implantam diversas versões ao mesmo tempo, com controles abrangentes. O suporte é responsabilidade das operações. As abordagens em cascata resultam em longas esperas entre os lançamentos de software. Como as equipes de desenvolvimento e operações trabalham separadamente, os desenvolvedores nem sempre estão cientes dos obstáculos operacionais que impedem o funcionamento do código conforme planejado.

O modelo DevOps alinha os esforços de desenvolvimento, controle de qualidade e operações de TI com menos portas e um fluxo de trabalho mais contínuo. Por exemplo, algumas das responsabilidades da equipe de operações passam do processo de entrega de aplicativos para a equipe de desenvolvimento. As operações de TI fornecem feedback para melhorar o código. Em vez de etapas fechadas, o DevOps é baseado em desenvolvimento contínuo, integração contínua, entrega contínua e processos de monitoramento.

DevOps versus desenvolvimento ágil. Agile é uma abordagem de desenvolvimento de software definida no Manifesto Ágil. As equipes ágeis se concentram em ciclos rápidos e incrementais de criação e entrega de código, conhecidos como sprints . Cada sprint se baseia no anterior, tornando o software muito flexível e adaptável às mudanças de requisitos. A visão original de um projeto pode se perder ao longo deste ciclo.

O DevOps surgiu do sucesso do Agile em melhorar a velocidade de desenvolvimento e da constatação de que as desconexões entre as equipes de desenvolvimento e operações —bem como entre a TI e o lado comercial da organização— dificultavam significativamente a entrega de software Agile aos usuários.

Em um fluxo de trabalho somente Agile, as equipes de desenvolvimento e operações têm metas e liderança separadas. Quando uma organização usa DevOps e Agile juntos, as equipes de desenvolvimento e operações gerenciam o código durante todo o ciclo de vida de desenvolvimento de software. Embora o trabalho ágil seja frequentemente formalizado com uma estrutura, como o Scrum, o DevOps não possui uma estrutura.

DevOps versus SRE. A engenharia de confiabilidade de sites surgiu ao mesmo tempo que Agile e DevOps. Iniciado no início dos anos 2000 no Google, é essencialmente uma abordagem focada na programação e automatização do ciclo de vida de desenvolvimento de software. Os problemas devem ser resolvidos de forma a evitar a sua recorrência. As tarefas rotineiras devem ser minimizadas.

A caixa de ferramentas do SRE se assemelha muito à do DevOps. Ambas as disciplinas visam a melhoria contínua. Os engenheiros de SRE e DevOps buscam abolir os silos entre o desenvolvimento e as operações. Embora o DevOps também possa ser estendido às partes interessadas do negócio, o SRE geralmente permanece dentro dos limites dos processos de TI.

DevOps versus SysOps. SysOps normalmente denota que um administrador de TI ou equipe de TI gerencia a implantação de produção e o suporte para um grande aplicativo distribuído, como um produto SaaS. Assim como aqueles que adotam o DevOps, as equipes de SysOps devem ser versadas em automação e computação em nuvem , bem como em outras tecnologias que permitam que os aplicativos tenham um bom desempenho em escala. As equipes de SysOps solucionam problemas de interrupções e incidentes de TI, monitoram problemas de desempenho, aplicam regras de segurança e otimizam operações.

Eles também se concentram em alta disponibilidade, tolerância a falhas, segurança e desempenho, assim como outros administradores de TI. Embora os profissionais de SysOps provavelmente usem algumas ferramentas de desenvolvimento e entendam os processos de desenvolvimento, seu trabalho não está tão interligado ao desenvolvimento como em um trabalho de DevOps. No entanto, as funções SysOps podem existir em organizações DevOps e SRE.

DevSecOps versus BizDevOps versus GitOps. Algumas organizações expandem o escopo do DevOps para incluir outras funções ou departamentos. No DevSecOps, o planejamento, a análise, os testes e as revisões de segurança ocorrem continuamente durante todo o ciclo do DevOps. O BizDevOps se concentra em conectar executivos, proprietários de aplicativos e outras partes interessadas do negócio com a equipe técnica, que desenvolve, testa e oferece suporte ao software. Embora se possa dizer que mais colaboração é melhor do que menos, estes colaboradores devem partilhar contributos eficazes, oportunos e precisos.

Outra variação do DevOps, ou uma facção diferente do mesmo movimento, é o GitOps. GitOps, nomeado por seu foco no repositório homônimo e na tecnologia de controle de versão, defende o controle de origem declarativo sobre a infraestrutura e o código do aplicativo. Tudo sobre software, desde requisitos de recursos até ambiente de implantação, vem de uma única fonte de verdade.

Benefícios e desafios do DevOps

Os benefícios do DevOps incluem o seguinte:

• menos silos e maiores comunicações entre grupos de TI;
• tempo de lançamento de software no mercado mais rápido;
• melhoria rápida baseada em feedback;
• menos tempo de inatividade;
• melhoria de todo o processo de entrega de software através de builds, validações e implantação;
• menos trabalho doméstico, graças à automação;
• Processos de desenvolvimento simplificados através de maior responsabilidade e propriedade do código no desenvolvimento; e
• papéis e habilidades mais amplos.

No entanto, os desafios do DevOps são abundantes:

• Mudanças organizacionais e departamentais de TI, incluindo novas habilidades e funções;
• ferramentas e plataformas dispendiosas, incluindo formação e apoio para as utilizar de forma eficaz;
• desenvolvimento e proliferação de ferramentas informáticas;
• automação desnecessária, frágil ou insegura;
• dimensionar DevOps em vários projetos e equipes;
• implementação mais arriscada devido a uma mentalidade de fracasso rápido e generalização do trabalho versus especialização;
• conformidade regulamentar, especialmente quando é necessária a separação de funções; e
• novos gargalos.

Adoção de DevOps

As transformações do DevOps não acontecem da noite para o dia. Muitas empresas começam com um projeto piloto – uma aplicação simples onde podem se familiarizar com novas práticas e ferramentas. Para adoção de DevOps em larga escala, tente avançar em etapas.

Inicialmente, DevOps pode significar um compromisso das equipes de desenvolvimento e operações de TI em compreender as preocupações e limites tecnológicos que existem em cada etapa do projeto de software. Combine os KPIs a serem melhorados, como tempos de ciclo mais curtos ou menos erros na produção. Estabeleça as bases para processos contínuos por meio da comunicação entre funções de trabalho.

Avalie as ferramentas existentes para desenvolvimento e operações de TI. Identifique lacunas, como uma etapa que é sempre realizada manualmente ou uma ferramenta sem API para conexão com outras ferramentas. Considere padronizar um processo DevOps em toda a empresa. Com um pipeline, os membros da equipe podem passar de um projeto para outro sem precisar treinar novamente. Os especialistas em segurança podem reforçar o pipeline e o gerenciamento de licenças é facilitado. A desvantagem dessa abordagem é que as equipes de DevOps abrem mão da liberdade de usar o que funciona melhor para elas.

A organização agora tem uma mentalidade DevOps, métricas para monitorar o sucesso e ferramentas capazes. Concentre-se nas melhores práticas, no compartilhamento de conhecimento e no desenvolvimento de habilidades para continuar melhorando. Otimize ferramentas e tecnologias, identificando obstáculos e lacunas que afetam seus KPIs.

As organizações podem usar o modelo de maturidade DevOps para orientar sua adoção:

• Inicial. As equipes estão isoladas; O trabalho é reativo e feito com processos ad hoc e opções de ferramentas.
• Definido. Um projeto piloto define uma abordagem DevOps, processos e ferramentas básicas. É uma prova de conceito.
• Administrado. A organização expande a adoção do DevOps com lições aprendidas no piloto. Os resultados do piloto podem ser repetidos com diferentes membros da equipe e tipos de projetos.
• Medido. Com processos e ferramentas implementados, as equipes compartilham conhecimento e refinam práticas. A automação e a conectividade de ferramentas aumentam e os padrões são aplicados por meio de políticas.
• Otimizado. A melhoria contínua ocorre. O DevOps pode evoluir para diferentes conjuntos de ferramentas ou processos para atender aos casos de uso. Por exemplo, os aplicativos voltados para o cliente têm uma frequência de lançamento mais alta e os aplicativos de gerenciamento financeiro seguem as práticas de DevSecOps.

Ferramentas de desenvolvimento e operações

DevOps é uma mentalidade, não um conjunto de ferramentas. Mas é difícil fazer qualquer coisa numa equipe de TI sem as ferramentas certas. Em geral, os profissionais de DevOps contam com pipeline de CI/CD, contêineres e hospedagem em nuvem . As ferramentas podem ser distribuições de código aberto, proprietárias ou de tecnologia suportada.

Repositórios de código. Repositórios de código-fonte controlados por versão permitem que vários desenvolvedores trabalhem no código. Os desenvolvedores revisam o código e podem reverter para uma versão anterior do código, se necessário. Essas ferramentas mantêm um registro das modificações feitas no código-fonte. Sem rastreamento, os desenvolvedores podem ter dificuldade em acompanhar quais alterações são recentes e quais versões do código estão disponíveis para os usuários finais.

Em um pipeline de CI/CD, uma alteração de código confirmada no repositório de controle de versão aciona automaticamente as próximas etapas, como análise de código estático ou testes de unidade e construção. As ferramentas para gerenciamento de código-fonte incluem Git e GitHub.

Depósitos de artefatos. O código-fonte é compilado em um artefato para teste. Repositórios de artefatos permitem resultados baseados em objetos e controlados por versão. O gerenciamento de artefatos é uma boa prática pelos mesmos motivos que o gerenciamento de código -fonte controlado por versão . Exemplos de repositórios de artefatos incluem JFrog Artifactory e Repositório Nexus.

Mecanismos de pipeline CI/CD. CI/CD permite que as equipes de DevOps validem e entreguem aplicativos ao usuário final com frequência por meio da automação durante todo o ciclo de vida de desenvolvimento. A ferramenta de integração contínua inicializa processos para que os desenvolvedores possam criar, testar e validar código em um repositório compartilhado quantas vezes forem necessárias, sem trabalho manual. A entrega contínua estende essas etapas automatizadas por meio de testes em nível de produção e configurações de gerenciamento de lançamento. A implantação contínua vai um passo além e invoca testes, configuração e provisionamento, bem como recursos de monitoramento e possíveis reversões. Ferramentas comuns para CI, CD ou ambos incluem Jenkins, GitLab e CircleCI.

Containers. Os contêineres são tempos de execução isolados para software em um sistema operacional compartilhado. Os contêineres fornecem uma abstração que permite que o código funcione da mesma forma em diferentes infraestruturas subjacentes, do desenvolvimento ao teste e preparação e, em seguida, à produção. Docker é o software de criação de contêineres mais conhecido, enquanto a Microsoft oferece opções específicas de contêineres do Windows. Orquestradores de contêineres, como o Kubernetes e as distribuições comerciais do Kubernetes, Red Hat OpenShift e Amazon Elastic Kubernetes Service, implantam, escalam e mantêm contêineres automaticamente.

Gerenciamento de configurações. Os sistemas de gerenciamento de configuração permitem que a TI provisione e configure software, middleware e infraestrutura com base em um script ou modelo. A equipe de DevOps pode configurar ambientes de implantação para lançamentos de código de software e aplicar políticas em servidores, contêineres e máquinas virtuais por meio de uma ferramenta de gerenciamento de configuração. As alterações no ambiente de implantação podem ser controladas e testadas quanto à versão, para que as equipes de DevOps possam gerenciar a infraestrutura como código. As ferramentas de gerenciamento de configuração incluem Puppet e Chef.

Ambientes em nuvem. As organizações DevOps muitas vezes adotam simultaneamente a infraestrutura em nuvem porque podem automatizar sua implantação, dimensionamento e outras tarefas de gerenciamento. AWS e Microsoft Azure estão entre os provedores de nuvem mais utilizados. Muitos provedores de nuvem também oferecem serviços de CI/CD.

Supervisão. Além disso, as ferramentas de monitoramento permitem que os profissionais de DevOps observem o desempenho e a segurança das versões de código em sistemas, redes e infraestrutura. Eles podem combinar monitoramento com ferramentas de análise que forneçam inteligência operacional. As equipes de DevOps usam essas ferramentas juntas para analisar como as alterações no código afetam o ambiente geral. As opções são amplas, mas incluem New Relic One, Dynatrace, Prometheus, Datadog e Splunk.

Pipelines DevOps baseados em nuvem. Os provedores de nuvem pública oferecem conjuntos de ferramentas nativas de DevOps para uso com cargas de trabalho em suas plataformas. Uma lista incompleta inclui AWS CodePipeline e CloudFormation, Azure DevOps e Pipelines e Google Cloud Deployment Manager. Os adotantes da nuvem têm a opção de usar esses serviços pré-integrados ou executar ferramentas de terceiros. Por exemplo, uma organização pode usar HashiCorp Terraform ou CloudFormation para criar modelos de infraestrutura como código para suas cargas de trabalho da AWS.

Modelos como serviço. Finalmente, DevOps as a Service é um modelo de entrega para um conjunto de ferramentas que facilita a colaboração entre a equipe de desenvolvimento de software de uma organização e a equipe de operações de TI. Nesse modelo de entrega, o fornecedor reúne um conjunto de ferramentas e lida com integrações para cobrir perfeitamente o processo geral de criação, entrega e manutenção de código.

Habilidades de desenvolvimento e operações

Costuma-se dizer que DevOps é mais uma filosofia ou cultura colaborativa de TI do que uma descrição de cargo ou um conjunto de habilidades estritamente definido. Como a área é tão ampla, os cargos de DevOps são mais adequados para generalistas de TI do que para especialistas.

A função de engenheiro DevOps não corresponde a um único plano de carreira. Os profissionais podem assumir a função com diversas origens. Por exemplo, um desenvolvedor de software pode aprender habilidades operacionais, como configurar infraestrutura de hospedagem, para se tornar um engenheiro de DevOps. Da mesma forma, um administrador de sistema com conhecimento de codificação, scripts e testes pode se tornar um engenheiro de DevOps.

Muitas vagas de DevOps exigem conhecimento de contêineres, nuvem e CI/CD, bem como habilidades interpessoais. Um engenheiro de DevOps também pode precisar alterar processos e resolver problemas organizacionais para alcançar resultados de negócios.

Outros títulos frequentemente encontrados em organizações DevOps incluem o seguinte:

• desenvolvedor de infraestrutura;
• engenheiro de confiabilidade do site;
• engenheiro de construção e lançamento;
• desenvolvedor full-stack;
• especialista em automação; e
• Engenheiro de plataforma CI/CD.

A maioria dos empregos básicos de DevOps exige um diploma em ciência da computação ou área relacionada que cubra codificação, testes de controle de qualidade e componentes de infraestrutura de TI. Cargos de nível superior podem exigir graus avançados em arquitetura de sistemas e design de software. As pessoas nesta carreira também devem expandir seus conhecimentos por meio de livros sobre DevOps e conectar-se com outros membros da comunidade por meio de blogs e conferências.

Não existem certificações DevOps reconhecidas em todo o setor, como existem para estruturas formalizadas como ITIL. O IBM Red Hat oferece certificação DevOps, enquanto o DevOps Institute oferece opções neutras de fornecedor para níveis que vão do básico ao especialista.