DevOps é uma metodologia de desenvolvimento de software que acelera o fornecimento de aplicações e serviços de alta qualidade, combinando e automatizando o trabalho das equipes de desenvolvimento de software e de operações de TI.
Com ferramentas e práticas compartilhadas, incluindo atualizações pequenas, mas frequentes, o desenvolvimento de software se torna mais eficiente, mais rápido e mais confiável.
Por definição, o DevOps, operações de desenvolvimento, descreve tanto um processo de desenvolvimento de software quanto uma mudança na cultura organizacional que promove a coordenação e a colaboração entre as equipes de desenvolvimento e operações de TI, dois grupos que tradicionalmente praticavam separadamente um do outro ou em silos.
Na prática, os melhores processos e culturas de DevOps vão além das práticas e operações de desenvolvimento para incorporar contribuições de todos os participantes do aplicativo no ciclo de vida de desenvolvimento de software. Esse grupo inclui engenharia de plataforma e infraestrutura, segurança, conformidade, governança, gerenciamento de riscos, linha de negócios, usuários finais e clientes.
Os princípios de DevOps representam o estado atual da evolução do processo de entrega de software durante os últimos 20 anos. O processo de entrega progrediu de lançamentos gigantescos de código em toda a aplicação a cada vários meses ou até mesmo anos, para atualizações iterativas menores de recursos ou funcionais, lançadas com frequência diária ou várias vezes por dia.
Em última análise, o DevOps visa atender à demanda cada vez maior dos usuários de software por novos recursos frequentes e inovadores e por desempenho e disponibilidade ininterruptos.
Se o software é importante, então a eficiência da entrega do software é importante. Leia o relatório para obter insights sobre como melhorar a eficiência geral do seu ciclo de vida DevOps.
Registre-se para receber o guia sobre nuvem híbrida
Antes de 2000, a maioria dos softwares era desenvolvida e atualizada usando a metodologia cascata, uma abordagem linear para projetos de desenvolvimento em larga escala. As equipes de desenvolvimento de software passaram meses desenvolvendo grandes corpos de novos códigos que afetaram a maior parte ou todo o ciclo de vida do aplicativo. Como as mudanças foram tão extensas, eles passaram vários meses integrando esse novo código à base de código.
Em seguida, as equipes de garantia de qualidade (QA), segurança e operações passaram ainda mais meses testando o código. O resultado foram meses ou até anos entre as versões do software e, muitas vezes, vários patches significativos ou correções de bugs entre as versões também. Essa abordagem de big bang para a entrega de recursos geralmente era caracterizada por planos de implantação complexos e arriscados, intertravamentos difíceis de programar com sistemas upstream e downstream e a grande esperança da TI de que os requisitos comerciais não tivessem mudado drasticamente nos meses que antecederam a entrada em produção ou a versão de disponibilidade geral (GA).
Para acelerar o desenvolvimento e melhorar a qualidade, as equipes de desenvolvimento começaram a adotar metodologias ágeis de desenvolvimento de software no início dos anos 2000. Essas metodologias são iterativas em vez de lineares e se concentram em fazer atualizações menores e mais frequentes na base de código do aplicativo. Entre essas metodologias de DevOps estão integração contínua e entrega contínua (CI/CD).
Na CI/CD, partes menores do novo código são mescladas na base de código em intervalos frequentes e, em seguida, automaticamente integradas, testadas e preparadas para implementação no ambiente de produção. O Agile modificou a abordagem big bang em uma série de pressões menores, que também compartimentalizaram os riscos.
Quanto mais eficazmente essas práticas de desenvolvimento ágil aceleravam o desenvolvimento e a entrega de software, mais elas expunham as operações de TI ainda isoladas, o provisionamento de sistemas, a configuração, os testes de aceitação, o gerenciamento e o monitoramento, por exemplo, como o próximo gargalo no ciclo de vida da entrega de software.
Portanto, o DevOps cresceu a partir do ágil. Ela adicionou novos processos e ferramentas que estendem a iteração contínua e a automação de CI/CD para o restante do ciclo de vida de entrega de software. E implementou uma estreita colaboração entre desenvolvimento e operações em todas as etapas do processo.
O ciclo de vida do DevOps (às vezes chamado de pipeline de entrega contínua, quando retratado de forma linear) é uma série de processos de desenvolvimento iterativos e automatizados, ou fluxos de trabalho, executados dentro de um ciclo de vida de desenvolvimento maior, automatizado e iterativo, projetado para otimizar a entrega rápida de software de alta qualidade. Os nomes dos fluxos de trabalho e o número de fluxos de trabalho diferem dependendo de quem você pergunta, mas geralmente incluem essas oito etapas.
Nesse fluxo de trabalho, as equipes definem novos recursos e funções para a próxima versão, com base no feedback e estudos de caso priorizados dos usuários, bem como nas contribuições de todas as partes interessadas internas. O objetivo da etapa de planejamento é maximizar o valor comercial do produto, produzindo uma lista de pendências de recursos que aumentam o valor do produto.
Essa é a etapa de programação, em que os desenvolvedores codificam e criam recursos novos e aprimorados com base em histórias de usuários e itens de trabalho no backlog. É comum uma combinação de práticas como desenvolvimento orientado por testes (TDD), programação em pares e revisões de código por pares. Os desenvolvedores geralmente usam suas estações de trabalho locais para executar o loop interno de escrever e testar o código antes de enviá-lo para o pipeline de entrega contínua.
Nesse fluxo de trabalho, o novo código é integrado à base de código existente, depois testado e empacotado para lançamento e implementação. As atividades comuns de automação incluem mesclar alterações de código em uma cópia principal, verificar esse código em um repositório de código-fonte e automatizar a compilação, o teste de unidade e o empacotamento em um arquivo executável. A melhor prática é armazenar o resultado da fase de CI em um repositório binário para a próxima fase.
As equipes usam testes, geralmente testes automatizados, para garantir que o aplicativo atenda aos padrões e requisitos. A abordagem clássica de DevOps inclui uma fase de teste discreta que ocorre entre a construção e o lançamento.
No entanto, o DevOps avançou de tal forma que certos elementos de teste podem ocorrer no planejamento (desenvolvimento orientado por comportamento), desenvolvimento (teste de unidade, teste de contrato), integração (varreduras de código estático, varreduras de CVE, linting), implantação (teste de fumaça, teste de penetração, teste de configuração), operações (teste de caos, teste de conformidade) e aprendizado (teste A/B).
O teste contínuo é uma forma poderosa de identificação de riscos e vulnerabilidades e oferece uma oportunidade para a TI aceitar, mitigar ou corrigir riscos. Além disso, o teste shift-left é uma abordagem no desenvolvimento de software que enfatiza a movimentação das atividades de teste no início do processo de desenvolvimento. Essa abordagem gera melhor qualidade do produto, melhor cobertura de testes, ciclos de feedback contínuos e um tempo de lançamento no mercado mais rápido.
O primeiro dos estágios de operação, o estágio de lançamento, é o último antes de os usuários acessarem o aplicativo. Nesse fluxo de trabalho, a saída da compilação em tempo de execução (da integração) é implantada em um ambiente de tempo de execução, geralmente um ambiente de desenvolvimento em que testes de tempo de execução são realizados para fins de qualidade, conformidade e segurança.
Se erros ou defeitos forem encontrados, os desenvolvedores têm a chance de interceptar e corrigir quaisquer problemas antes que qualquer usuário os veja. Normalmente, existem ambientes para desenvolvimento, teste e produção, com cada ambiente exigindo portas de qualidade progressivamente mais rigorosas. Quando os programadores corrigirem todos os problemas identificados e o aplicativo atender a todos os requisitos, a equipe de operações confirmará que ele está pronto para implantação e o compilará no ambiente de produção.
A implementação ocorre quando o projeto passa para um ambiente de produção onde os usuários podem acessar as alterações no aplicativo. A infraestrutura é instalada e configurada (geralmente usando infraestrutura como código) e o código do aplicativo é implantado. Uma boa prática para implantação em um ambiente de produção é implantar primeiro em um subconjunto de usuários finais e, eventualmente, em todos os usuários, uma vez estabelecida a estabilidade.
Se a entrega de recursos em um ambiente de produção for caracterizada como "Dia 1", então, quando os recursos estiverem sendo executados na produção, as operações do "Dia 2" terão início. O monitoramento do desempenho, do comportamento e da disponibilidade dos recursos ajuda a garantir que eles agreguem valor aos usuários.
Nesse estágio, as equipes verificam se os recursos estão funcionando sem problemas e se não há interrupções no serviço, garantindo que a rede, o armazenamento, a plataforma, a computação e as posturas de segurança estejam saudáveis. Se ocorrerem problemas, as equipes de operações identificam o incidente, alertam o pessoal adequado, solucionam problemas e aplicam correções.
Trata-se da coleta de feedback de usuários e clientes sobre recursos, funções, desempenho e valor comercial para o planejamento de melhorias e recursos na próxima versão. Isso também inclui qualquer item de aprendizado e lista de pendências das atividades de operações que possam ajudar os desenvolvedores a evitar proativamente a recorrência de incidentes conhecidos. Este é o ponto em que ocorre o "contorno" da fase de planejamento que impulsiona a melhoria contínua.
Existem dois outros fluxos de trabalho contínuos importantes no ciclo de vida:
Enquanto as metodologias em cascata e as implementações ágeis “aderem” aos fluxos de trabalho de segurança após a entrega ou implantação, o DevOps se esforça para incorporar a segurança desde o início (planejamento), quando os problemas de segurança são mais fáceis e menos dispendiosos de resolver, e são executados continuamente durante o restante do ciclo de desenvolvimento. Essa abordagem à segurança é conhecida como deslocamento para a esquerda. Algumas organizações tiveram menos sucesso na mudança para a esquerda do que outras, o que levou ao surgimento do DevSecOps (desenvolvimento, segurança e operações).
Também é melhor abordar questões regulatórias controle, risco e conformidade (GRC) no início e durante todo o ciclo de vida do desenvolvimento. Os setores regulamentados geralmente são obrigados a fornecer um certo nível de observabilidade, rastreabilidade e acesso à forma como os recursos são entregues e gerenciados em seu ambiente operacional de tempo de execução.
Isso requer planejamento, desenvolvimento, teste e aplicação de políticas no pipeline de entrega contínua e no ambiente de execução. A auditabilidade das medidas de conformidade é importante para comprovar a conformidade com auditores terceirizados.
Os líderes de negócios geralmente concordam que os métodos de DevOps não funcionam sem um compromisso com a cultura DevOps, ou seja, uma abordagem organizacional e técnica diferente para o desenvolvimento de software.
No nível organizacional, o DevOps requer comunicação contínua, colaboração e responsabilidade compartilhada entre todas as partes interessadas na entrega de software. Isso inclui equipes de desenvolvimento de software e operações de TI, com certeza, mas também equipes de segurança, conformidade, governança, risco e linha de negócios, para inovar rápida e continuamente e focar na qualidade desde o início.
Normalmente, a melhor maneira de conseguir isso é quebrar os silos e reorganizar o pessoal em equipes de DevOps multifuncionais e autônomas que possam trabalhar em projetos do início ao fim (do planejamento ao feedback) sem fazer transferências ou esperar pela aprovação de outras equipes. No contexto do desenvolvimento ágil, a responsabilidade compartilhada e a colaboração são a base de um foco compartilhado no produto com resultados valiosos.
Em nível técnico, o DevOps exige um compromisso com a automação que mantém os projetos em andamento dentro e entre os fluxos de trabalho. Também requer feedback e medição que permite às equipes acelerar continuamente os ciclos e melhorar a qualidade e o desempenho do software.
Promover uma cultura de colaboração e remover silos aproxima o trabalho de programadores e equipes de operações, o que aumenta a eficiência e reduz as cargas de trabalho devido à combinação de fluxos de trabalho. Como os programadores e as equipes de operações compartilham muitas responsabilidades, há menos surpresas à medida que os projetos avançam. As equipes de DevOps sabem exatamente em qual ambiente o código é executado à medida que o desenvolvem.
As equipes de DevOps entregam novos códigos com mais rapidez por meio de maior colaboração e da criação de lançamentos mais focados (e mais frequentes) usando uma arquitetura de microsserviços. Esse processo gera melhorias, inovações e correções de erros no mercado mais cedo.
Também permite que as organizações se adaptem mais rapidamente às mudanças do mercado e atendam melhor às necessidades dos clientes, resultando em maior satisfação do cliente e vantagem competitiva. O processo de lançamento de software pode ser automatizado com a entrega contínua e a integração contínua.
A entrega contínua e a integração contínua incluem testes automatizados para ajudar a garantir a qualidade e a confiabilidade das atualizações de software e infraestrutura. O monitoramento e o registro em log verificam o desempenho em tempo real.
A automação, incluindo infraestrutura como código, pode ajudar a gerenciar o desenvolvimento, os testes e a produção, além de permitir um dimensionamento mais rápido com maior eficiência.
O DevSecOps integra integração, entrega e implementação contínuas ao processo de desenvolvimento para que a segurança seja integrada desde o início, em vez de ser adaptada. As equipes criam testes e auditorias de segurança em fluxos de trabalho usando a infraestrutura como código para ajudar a manter o controle e rastrear a conformidade.
Uma abordagem de DevOps pode ajudar a melhorar a satisfação no trabalho, automatizando tarefas rotineiras e repetitivas e permitindo que os funcionários se concentrem em um trabalho mais gratificante que gera valor para os negócios.
As demandas da cultura DevOps e DevOps priorizam as ferramentas que oferecem suporte à colaboração assíncrona, integram perfeitamente fluxos de trabalho DevOps e automatizam todo o ciclo de vida do DevOps o máximo possível.
As categorias de ferramentas de DevOps incluem:
As ferramentas de gerenciamento de projetos permitem que as equipes criem um backlog de histórias de usuários (requisitos) que formam projetos de codificação, divida-os em tarefas menores e acompanhem as tarefas até a conclusão. Muitas ferramentas oferecem suporte a práticas ágeis de gerenciamento de projetos, como Scrum, Lean e Kanban, que os desenvolvedores trazem para o DevOps. As opções populares de código aberto incluem o GitHub Issues e o Jira.
Esses são ambientes de codificação com controle de versão que permitem que vários desenvolvedores trabalhem na mesma base de código. Os repositórios de código devem se integrar às ferramentas de CI/CD, teste e segurança, de modo que, quando o código for confirmado no repositório, ele possa passar automaticamente para a próxima etapa. Os repositórios de código-fonte aberto incluem o GitHub e o GitLab.
São ferramentas que automatizam a finalização, construção, teste e implementação de código. Jenkins é a ferramenta de código aberto mais popular nesta categoria; muitas alternativas anteriores de código aberto, como o CircleCI, agora estão disponíveis apenas em versões comerciais.
Para ferramentas de implantação contínua (CD), o Spinnaker se estende entre o aplicativo e a infraestrutura como camadas de código. ArgoCD é outra opção popular de código aberto para CI/CD nativo do Kubernetes.
Isso inclui ferramentas de software, bibliotecas e melhores práticas para automatizar testes unitários, contratuais, funcionais, de desempenho, usabilidade, penetração e segurança. As melhores dessas ferramentas oferecem suporte a vários idiomas. Alguns usam inteligência artificial (IA) para reconfigurar automaticamente os testes em resposta às mudanças no código. A extensão de ferramentas e estruturas de teste é ampla. As estruturas populares de automação de testes de código aberto incluem Selenium, Appium, Katalon, Robot Framework e Serenity (anteriormente conhecido como Thucydides).
As ferramentas de gerenciamento de configuração (também conhecidas como ferramentas de código) permitem que engenheiros de DevOps configurem e provisionem infraestrutura totalmente versionada e totalmente documentada, executando um script. As opções de código aberto incluem Ansible (Red Hat), Chef, Puppet e Terraform. O Kubernetes executa a mesma função para aplicações em contêineres.
As ferramentas de monitoramento ajudam as equipes de DevOps a identificar e resolver problemas do sistema. Eles também coletam e analisam dados em tempo real para revelar como as alterações no código afetam o desempenho do aplicativo. As ferramentas de monitoramento de código aberto incluem Datadog, Nagios, Prometheus e Splunk.
Essas ferramentas coletam feedback dos usuários, seja por meio de mapeamento de calor (registro das ações dos usuários na tela), pesquisas ou emissão de tickets de autoatendimento.
O nativo em nuvem é uma abordagem para criar aplicativos que usam tecnologias básicas de computação em nuvem. As plataformas de nuvem ajudam a permitir o desenvolvimento, a implementação, o gerenciamento e o desempenho consistentes e ideais de aplicativos em ambientes públicos, privados e multinuvem.
Atualmente, as aplicações nativas em nuvem são normalmente:
- Construídas usando microsserviços: Componentes fracamente acoplados e implantáveis de forma independente que têm seu próprio stack autocontido e se comunicam entre si por meio de APIs REST, fluxo de eventos ou agentes de mensagens.
- Implementado em contêineres: unidades de código executáveis que contêm todos os códigos, tempos de execução e dependências do sistema operacional necessárias para executar o aplicativo. Para muitas organizações, os contêineres são sinônimos dos contêineres Docker, mas outros estão disponíveis.
- Operado (em escala) usando Kubernetes: uma plataforma de orquestração de contêineres de código aberto para agendar e automatizar a implementação, o gerenciamento e o dimensionamento de aplicações em contêineres.
De muitas maneiras, o desenvolvimento nativo em nuvem e o DevOps foram feitos um para o outro. Por exemplo, desenvolver e atualizar microsserviços, ou seja, a entrega iterativa de pequenas unidades de código para uma pequena base de código, é um ajuste perfeito para os ciclos rápidos de liberação e gerenciamento de DevOps. Seria difícil lidar com a complexidade de uma arquitetura de microsserviços sem a implementação e operação de DevOps.
Uma pesquisa recente da IBM com desenvolvedores e executivos de TI descobriu que 78% dos usuários atuais de microsserviços esperam aumentar o tempo, o dinheiro e o esforço investidos na arquitetura, e 56% dos não usuários provavelmente adotarão microsserviços nos próximos dois anos.
Ao empacotar e corrigir permanentemente todas as dependências do sistema operacional, os contêineres permitem ciclos rápidos de CI/CD e implantação, porque toda integração, teste e implantação ocorrem no mesmo ambiente. A orquestração do Kubernetes executa as mesmas tarefas de configuração contínua para aplicativos em contêineres que Ansible, Puppet e Chef executam para aplicações não em contêineres.
A maioria dos principais provedores de computação em nuvem, incluindo AWS, Google, Microsoft Azure e IBM Cloud, oferece algum tipo de solução de pipeline de DevOps gerenciado.
DevSecOps é um DevOps que integra e automatiza continuamente a segurança durante todo o ciclo de vida do DevOps — do início ao fim, do planejamento ao feedback e de volta ao planejamento novamente.
Outra maneira de dizer isso é que o DevSecOps é o que o DevOps deveria ser desde o início. Mas dois dos desafios iniciais, significativos (e por um tempo insuperáveis) da adoção do DevOps foram integrar a experiência em segurança em equipes multifuncionais (um problema cultural) e implementar a automação da segurança no ciclo de vida do DevOps (um problema técnico). A segurança passou a ser vista como uma equipe do não e como um gargalo caro em muitas práticas de DevOps.
O DevSecOps surgiu como um esforço específico para integrar e automatizar a segurança como originalmente pretendido. No DevSecOps, a segurança é um cidadão e um stakeholder de primeira classe, juntamente com o desenvolvimento e as operações, e traz segurança para o processo de desenvolvimento com foco no produto.
A engenharia de confiabilidade do site (SRE) usa técnicas de engenharia de software para automatizar tarefas de operações de TI, como gerenciamento de sistemas de produção, gerenciamento de mudanças, resposta a incidentes e até mesmo resposta a emergências, que os administradores de sistemas podem executar manualmente. A SRE busca transformar o administrador de sistema clássico em um engenheiro.
O objetivo do SRE é semelhante ao objetivo do DevOps, mas é mais específico: o SRE tem como objetivo equilibrar o desejo da organização de um desenvolvimento rápido de aplicações com sua necessidade de atender aos níveis de desempenho e disponibilidade especificados em contratos de nível de serviço (SLAs) com os clientes.
Os engenheiros de confiabilidade do site alcançam esse equilíbrio determinando um nível aceitável de risco operacional causado pelos aplicativos, chamado de orçamento de erro, e automatizando as operações para atender a esse nível.
Em uma equipe de DevOps multifuncional, o SRE pode servir como uma ponte entre o desenvolvimento e as operações. O SRE fornece as métricas e as ferramentas de automação de que as equipes precisam para enviar alterações de código e novos recursos por meio do pipeline de DevOps o mais rápido possível, sem violar os termos dos SLAs da organização.
À medida que a variedade de tarefas que podem ser automatizadas aumenta, mais funções são adicionadas ao DevOps, o que gera várias variações do DevOps. E à medida que o DevOps prova seus muitos benefícios, o investimento empresarial aumenta.
De acordo com a Verified Market Research, o mercado de DevOps foi avaliado em USD 10,96 bilhões em 2023 e deve atingir USD 21,13 bilhões até 2031, crescendo a um CAGR de 21,23% de 2024 a 2031.
Para ajudar a garantir o sucesso do DevOps, as empresas estão adotando cada vez mais:
Inteligência artificial para operações de TI traz IA e aprendizado de máquina para automatizar e simplificar as operações de TI, possibilitando uma rápida análise de grandes quantidades de dados.
O BizDevOps traz unidades de negócios para colaborar no processo de desenvolvimento de software junto com o desenvolvimento e as operações. Também conhecida como DevOps 2.0, essa mudança cultural acelera o processo e leva a soluções mais fortes que se alinham aos objetivos da unidade de negócios.
Outra maneira de criar novas eficiências é com a conteinerização, onde um aplicativo e suas dependências são encapsulados em um pacote simplificado e portátil que é executado em praticamente qualquer plataforma.
Adicionar mais funções de segurança no início do desenvolvimento impulsionou o DevSecOps. A segurança não é mais uma consideração tardia.
O GitOps se concentra em armazenar o código do aplicativo em um repositório Git para que ele tenha controle de versão, esteja disponível para vários membros da equipe e seja totalmente rastreável e auditável. Essas medidas ajudam a aumentar a eficiência, a confiabilidade e a escalabilidade.
Enquanto as ferramentas tradicionais de monitoramento fornecem visibilidade, as plataformas de observabilidade fornecem uma compreensão mais profunda de como um sistema está se saindo e, mais importante, o contexto—o porquê por trás do desempenho. Além de fornecer esse entendimento abrangente, a observabilidade permite que todas as partes interessadas acessem os dados de que precisam para criar soluções e criar aplicativos melhores.
Serverless é um modelo de execução e desenvolvimento de aplicações de computação em nuvem para que os desenvolvedores criem e executem códigos de aplicação sem precisar provisionar nem gerenciar servidores e infraestruturas de back-end. Nas arquiteturas serverless, os desenvolvedores escrevem o código do aplicativo e o implementam em contêineres gerenciados por um provedor de serviços de nuvem.
Adote um poderoso software de DevOps para criar, implantar e gerenciar aplicativos nativos da nuvem ricos em segurança em vários dispositivos, ambientes e nuvens.
Automatize seu processo de entrega de software para aumentar a produtividade e a eficiência operacionais.
Transforme aplicativos de missão crítica para ambientes de nuvem híbrida com estabilidade, segurança e agilidade.
Em um cenário em constante mudança, inove com mais rapidez, reduza os custos operacionais e transforme as operações de TI (ITOps) com uma plataforma de AIOps que oferece visibilidade dos dados de desempenho e das dependências em vários ambientes.
Leia sobre como a modernização de seus ambientes de aplicações de mainframe proporcionará melhores resultados comerciais.
Acesse um relatório exclusivo de analistas da Gartner e saiba como a IA para TI melhora os resultados de negócios, leva ao aumento da receita e reduz custos e riscos para as organizações.
Este IBM Redpaper discute estratégias e soluções de arquitetura que aceleram a modernização de aplicações de mainframe aproveitando ambientes de nuvem híbrida. Especificamente, consulte o capítulo 5 para obter informações sobre a modernização do DevOps corporativo.
Saiba mais sobre o Wazi Deploy, que adiciona uma opção de implementação de aplicativo com script de código aberto ao extenso conjunto de ferramentas de desenvolvimento do IBM Developer for z/OS Enterprise Edition.
Explore um programa de adoção antecipada de valor agregado projetado para estabelecer parcerias com clientes durante estágios distintos que acreditamos serem necessários para qualquer transformação DevOps.
Junte-se à comunidade DevSecOps para ficar por dentro das últimas tendências e tópicos Z.