DevOps

menu icon

DevOps

O DevOps acelera a entrega de software de qualidade superior combinando e automatizando o trabalho de desenvolvimento de software e equipes de operações de TI.

O que é DevOps?

Por definição, o DevOps descreve um processo de desenvolvimento de software e uma mudança de cultura organizacional que acelera a entrega de software de alta qualidade, automatizando e integrando os esforços das equipes de desenvolvimento e operações de TI, dois grupos que tradicionalmente praticavam separadamente ou em silos.

Na prática, os melhores processos e culturas DevOps vão além do desenvolvimento e das operações para incorporar as entradas de todas as partes interessadas do aplicativo, incluindo plataforma e engenharia de infraestrutura, segurança, conformidade, governança, gerenciamento de risco, linha de negócios, usuários finais e clientes, no ciclo de vida do desenvolvimento de software.

O DevOps representa o estado atual da evolução dos ciclos de entrega de software durante os últimos mais de 20 anos, desde lançamentos de códigos gigantes em todo o aplicativo a cada vários meses ou mesmo anos, a recursos menores iterativos ou atualizações funcionais lançadas tão frequentemente como todos os dias 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 inovadores e frequentes e desempenho e disponibilidade ininterruptos.

Como chegamos ao DevOps

Até pouco antes de 2000, a maioria dos softwares era desenvolvida e atualizada usando a metodologia em cascata, uma abordagem linear para projetos de desenvolvimento em grande escala. As equipes de desenvolvimento de software passavam meses desenvolvendo grandes conjuntos de novos códigos que afetavam a maior parte ou todos os aplicativos. Como as mudanças eram muito extensas, eles passavam 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 passavam mais meses ainda testando o código. O resultado foram meses ou mesmo anos entre os lançamentos de software e, muitas vezes, vários patches significativos ou correções de bugs entre os lançamentos também. E esta abordagem "big bang" para entrega de recursos era frequentemente caracterizada por planos complexos e arriscados de implementação, bloqueios difíceis de agendar com sistemas upstream e downstream e a "grande esperança" de TI de que os requisitos de negócios não tivessem mudado drasticamente nos meses que antecederam o lançamento da produção.

Para acelerar o desenvolvimento e melhorar a qualidade, as equipes de desenvolvimento começaram a adotar metodologias Agile de desenvolvimento de software, que 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. A principal dessas metodologias é a integração e entrega contínua ou CI/CD. Em CI/CD, pedaços menores de novo código são mesclados na base de código a cada uma ou duas semanas e, em seguida, automaticamente integrados, testados e preparados para implementação no ambiente de produção. O método Agile evoluiu a abordagem do “big bang” para uma série de “encaixes menores” que também compartimentaram os riscos.

Quanto mais eficaz são essas práticas de desenvolvimento Agile no aceleração do desenvolvimento e da entrega de software, mais elas expuseram as operações de TI ainda isoladas, provisionamento de sistema, configuração, teste de aceitação, gerenciamento, monitoramento, como o próximo gargalo no ciclo de vida de entrega de software.

Portanto, o DevOps deixou de ser ágil. Ele incluiu novos processos e ferramentas que estendem a iteração contínua e automação de CI/CD para o resto do ciclo de vida de entrega de software. E implementou uma estreita colaboração entre desenvolvimento e operações em cada etapa do processo.

Como o DevOps funciona: O ciclo de vida do DevOps

Gráfico mostrando o caminho do ciclo de vida do DevOps

Figura 1: O ciclo de vida do DevOps

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 ou fluxos de trabalho de desenvolvimento automatizados e iterativos executados dentro de um ciclo de vida de desenvolvimento maior, automatizado e iterativo projetado para otimizar a entrega rápida de software alta qualidade. O nome e o número de fluxos de trabalho podem diferir dependendo de quem você pergunta, mas eles tipicamente se resumem a estes seis:

  • Planejamento (ou ideação). nesse fluxo de trabalho, as equipes buscam novos recursos e funcionalidades na próxima versão, utilizando o feedback priorizado do usuário final e estudos de caso, bem como as contribuições de todas as partes interessadas internas. O objetivo no estágio de planejamento é maximizar o valor de negócio do produto, produzindo uma lista não processada de recursos que, quando entregues, produzem um resultado desejado que tenha valor.
  • Desenvolvimento: esta é a etapa de programação na qual os desenvolvedores testam, codificam e criam recursos novos e aprimorados, com base em histórias de usuário e itens de trabalho na lista não processada. Uma combinação de práticas como o desenvolvimento orientado a testes (TDD), a programação de pares e revisões de código de pares, entre outros são comuns. Os desenvolvedores costumam usar suas estações de trabalho locais para realizar o “loop interno” de escrever e testar o código antes de enviá-lo pelo pipeline de entrega contínua.
  • Integração (ou compilação ou Integração contínua e entrega contínua (CI/CD). Como observado acima, neste fluxo de trabalho o novo código é integrado à base de código existente e, então, testado e empacotado em um executável para implementação. Atividades de automação comuns incluem mesclar mudanças de código em uma cópia "mestre", verificar esse código de um repositório de código-fonte e automatizar a compilação, teste de unidade e empacotamento em um executável. A melhor prática é armazenar a saída da fase de IC em um repositório binário, para a próxima fase.
  • Implementação (geralmente chamada deimplementação contínua). Aqui a saída de compilação do tempo de execução (da integração) é implementada em um ambiente de tempo de execução, geralmente um ambiente de desenvolvimento no qual os testes de tempo de execução são executados para qualidade, conformidade e segurança. Se erros ou defeitos forem encontrados, os desenvolvedores terão a chance de interceptar e corrigir qualquer problema antes que qualquer usuário final os veja. Normalmente existem ambientes para desenvolvimento, teste e produção, com cada ambiente exigindo portões de qualidade progressivamente mais “rígidos”. Uma boa prática para implementação em um ambiente de produção é normalmente implementar primeiro em um subconjunto de usuários finais e, eventualmente, em todos os usuários, uma vez que a estabilidade seja estabelecida.
  • Operações. Se a entrega de recursos em um ambiente de produção é caracterizada como “Dia 1”,então, quando os recursos estão em execução na produção, as operações do “Dia 2” ocorrerão. O monitoramento do desempenho, do comportamento e da disponibilidade dos recursos garante que os recursos sejam capazes de agregar valor aos usuários finais. As operações garantem que os recursos estejam funcionando sem problemas e que não haja interrupções no serviço, garantindo que a rede, o armazenamento, a plataforma, a computação e a postura de segurança estejam saudáveis. Se algo der errado, as operações garantem que os incidentes sejam identificados, o pessoal adequado seja alertado, os problemas sejam determinados e as correções sejam aplicadas.
  • Aprendizagem (às vezes chamado de feedback contínuo). Esta é a coleta de feedback de usuários finais e clientes sobre recursos, funcionalidade, desempenho e valor comercial para levar de volta ao planejamento de melhorias e recursos na próxima liberação. Isso também incluiria qualquer aprendizado e itens de lista não processada das atividades de operações, que poderiam capacitar os desenvolvedores a evitar proativamente quaisquer incidentes anteriores que poderiam acontecer novamente no futuro. Este é o ponto onde acontece o “retorno” à fase de planejamento e nós “melhoramos continuamente!”

Três outros fluxos de trabalho contínuos importantes ocorrem entre esses fluxos de trabalho:

Teste contínuo: ciclos de vida de DevOps Clássicos incluem uma fase discreta de "teste" que ocorre entre integração e implementação. No entanto, o DevOps avançou de forma que certos elementos de teste podem ocorrer em planejamento (desenvolvimento orientado por comportamento), desenvolvimento (teste de unidade, teste de contrato), integração (varreduras de código estático, varreduras CVE, linting), implantação (teste de fumaça, teste de invasão, teste de configuração), operações (teste de caos, teste de conformidade) e aprendizado (teste A/B). O teste é uma forma poderosa de identificação de risco e vulnerabilidade e fornece uma oportunidade para TI aceitar, mitigar ou corrigir riscos.

Segurança: enquanto as metodologias em cascata e as implementações Agile 'aderem' aos fluxos de trabalho de segurança após a entrega ou implementaçã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 continuamente durante todo o restante do ciclo de desenvolvimento. Essa abordagem de segurança é chamada de shift left (que é mais fácil de entender se você observar a Figura 1). Algumas organizações tiveram menos sucesso na execução do shift left do que outras, o que levou à ascensão do DevSecOps (veja abaixo).

Conformidade. A conformidade regulamentar (governança e risco) também é mais bem tratada no início e durante todo o ciclo de desenvolvimento. Os setores regulamentados geralmente são obrigados a fornecer um certo nível de observabilidade, rastreabilidade e acesso de 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 tempo de execução. A capacidade de auditoria das medidas de conformidade é extremamente importante para provar a conformidade para auditores terceirizados.

Cultura DevOps

É geralmente aceito que os métodos DevOps não funcionam sem um compromisso com a cultura DevOps, que pode ser resumida como 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 de entrega de software, equipes de desenvolvimento de software e operações de TI, mas também equipes de segurança, conformidade, governança, risco e linha de negócios, para inovar de forma rápida e contínua e incorporar a qualidade no software desde o início.

Na maioria dos casos, a melhor maneira de fazer isso é quebrar esses silos e reorganizá-los em equipes de DevOps autônomas e multifuncionais que podem trabalhar em projetos de código do início ao fim, planejamento do feedback, sem fazer transferência de responsabilidade ou esperar aprovações de outras equipes. Quando colocadas no contexto do desenvolvimento Agile, a responsabilidade compartilhada e a colaboração são o alicerce de ter um foco do produto compartilhado que tem um resultado valioso.

No nível técnico, o DevOps requer um compromisso com automação que mantém os projetos em movimento dentro e entre os fluxos de trabalho, e para feedback e medição que permitem que as equipes acelerem continuamente os ciclos e melhorem a qualidade e o desempenho do software.

Ferramentas DevOps: Desenvolvendo uma cadeia de ferramentas do DevOps

As demandas de DevOps e da cultura DevOps valorizam as ferramentas que oferecem suporte à colaboração assíncrona, integra perfeitamente os fluxos de trabalho DevOps e automatiza todo o ciclo de vida do DevOps o máximo possível. As categorias de ferramentas DevOps incluem:

  • Ferramentas de gerenciamento de projeto ferramentas que permitem às equipes criar uma lista não processada de histórias de usuários (requisitos) que formam projetos de codificação, dividi-los em tarefas menores e acompanhar as tarefas até a conclusão. Muitos suportam práticas de gerenciamento de projetos ágeis, como Scrum, Lean e Kanban, que os desenvolvedores trazem para o DevOps. Opções populares de software livre incluem GitHub Issues e Jira.
  • Repositórios de código-fonte colaborativos -ambientes de codificação controlados por versão que permitem que vários desenvolvedores trabalhem no mesmo código base. Os repositórios de código devem se integrar com CI/CD, ferramentas de 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. Repositórios de código de software livre incluem GiHub e GitLab.
  • Pipelines de CI/CD ferramentas que automatizam a verificação, desenvolvimento, teste e implementação de código. Jenkins é a ferramenta de software livre mais popular nesta categoria. Muitas alternativas de software livre anteriores, como a CircleCI, agora estão disponíveis apenas em versões comerciais. Quando se trata de ferramentas de implementação contínua (CD), o Spinnaker se estende entre o aplicativo e a infraestrutura como camadas de código. ArgoCD é outra escolha popular de software livre para CI/CD nativo do Kubernetes.
  • Estruturas de automação de teste incluem ferramentas de software, bibliotecas e melhores práticas para automatizar testes de unidade, contrato, funcional, desempenho, usabilidade, invasão e segurança. As melhores ferramentas dessa categoria oferecem suporte a vários idiomas e algumas usam inteligência artificial (IA) para reconfigurar automaticamente os testes em resposta às mudanças no código. A extensão das ferramentas e estruturas de teste é muito ampla! As estruturas de automação de teste de software livre populares incluem Selenium, Appium, Katalon, Robot Framework e Serenity (anteriormente chamado Tucídides).
  • Ferramentas de gerenciamento de configuração (infraestrutura como código) permitem que os engenheiros de DevOps configurem e provisionem infraestrutura totalmente com versão e totalmente documentada executando um script. As opções de software livre incluem Ansible (Red Hat), Chef, Puppet e Terraform. O Kubernetes executa a mesma função para aplicativos conteinerizados (veja 'DevOps e desenvolvimento nativo em cloud', abaixo).
  • Ferramentas de monitoramento estas equipes de DevOps ajudam a identificar e resolver problemas do sistema, elas também reúnem e analisam dados em tempo real para revelar como o código altera o desempenho do aplicativo de impacto. Ferramentas de monitoramento de software livre incluem Datadog, Nagios, Prometheus e Splunk.
  • Ferramentas de feedback contínuo ferramentas que reúnem feedback dos usuários, seja por meio de heatmapping (gravação de ações dos usuários em tela), pesquisas ou emissão de bilhetes de autoatendimento.

DevOps e desenvolvimento nativo em cloud

Nativo em cloud é uma abordagem para desenvolver aplicativos que alavancam tecnologias básicas de computação em cloud. O objetivo do desenvolvimento nativo em cloud é permitir um desenvolvimento, implementação, gerenciamento e desempenho de aplicativo consistente e ideal em ambientes públicos, privados e multicloud.

Hoje, os aplicativos nativos da cloud são tipicamente

  • Desenvolvido usando microsserviços componentes livremente acoplados e implementáveis de forma independente que têm sua própria stack autocontida e se comunicam entre si por meio de APIs REST, fluxo de eventos ou corretores de mensagens.
  • Implementados em contêineres- unidades executáveis de código que contêm todo o código, tempos de execução e dependências do sistema operacional necessários para executar o aplicativo. (Para a maioria das organizações, 'contêineres' é sinônimo de contêineres Docker, mas existem outros tipos de contêineres).
  • Operado (em escala) usando Kubernetes, uma plataforma de orquestração de contêiner de software livre para planejamento e automatização da implementação, gerenciamento e escalonamento de aplicativos conteinerizados.

De muitas maneiras, o desenvolvimento nativo em cloud e o DevOps são feitos um para o outro.

Por exemplo, desenvolver e atualizar os microsserviços, ou seja, a entrega iterativa de pequenas unidades de código a um pequeno código base, é um ajuste perfeito para ciclos rápidos de gerenciamento e liberação de DevOps. E seria difícil lidar com a complexidade de uma arquitetura de microsserviços sem a implementação e operação do DevOps. Uma pesquisa recente da IBM com desenvolvedores e executivos de TI descobriu que 78% dos atuais usuários de microsserviços esperam aumentar o tempo, dinheiro e esforço que investiram na arquitetura, e 56% dos não usuários provavelmente adotarão microsserviços nos próximos dois anos. Para explorar alguns dos benefícios e desafios específicos dos microsserviços que eles citaram, use a ferramenta interativa abaixo:

(Fonte: 'Microservices in the enterprise 2021: Real benefits, worth the challenges'.)

Ao empacotar e corrigir permanentemente todas as dependências do sistema operacional, os contêineres permitem ciclos rápidos de CI/CD e implementação, porque toda integração, teste e implementação ocorrem no mesmo ambiente. E a orquestração do Kubernetes executa as mesmas tarefas de configuração contínua para aplicativos em contêiner como o Ansible, o Puppet e o Chef executam para aplicativos não conteinerizados.

Os principais provedores de computação em cloud, incluindo AWS, Google, Microsoft Azure e IBM Cloud, oferecem uma espécie de solução de pipeline de DevOps gerenciado.

O que é DevSecOps?

DevSecOps é o DevOps que integra e automatiza continuamente a segurança em 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 colocar isso é que o DevSecOps é o que o DevOps deveria ser desde o início. Mas dois dos primeiros desafios significativos (e por um tempo intransponí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 de segurança no ciclo de vida do DevOps (um problema técnico). A segurança passou a ser percebida como a "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 pretendida. No DevSecOps, a segurança é um cidadão e uma parte interessada de “primeira classe” junto com o desenvolvimento e as operações, e traz segurança para o processo de desenvolvimento com foco no produto.

Assista 'O que é DevSecOps?' para saber mais sobre os princípios, benefícios e casos de uso do DevSecOps:

DevOps e engenharia de confiabilidade do site (SRE)

A engenharia de confiabilidade do site (SRE) usa técnicas de engenharia de software para automatizar tarefas de operações de TI, por exemplo, gerenciamento do sistema de produção, gerenciamento de mudanças, resposta a incidentes e até mesmo resposta a emergências, que pode de outra forma ser executado manualmente por administradores de sistemas. A SRE busca transformar o administrador clássico do sistema em um engenheiro.

O objetivo final da SRE é semelhante ao objetivo do DevOps, mas mais específico: O SRE visa equilibrar o desejo de uma organização por desenvolvimento rápido de aplicativos com sua necessidade de atender aos níveis de desempenho e disponibilidade especificados em acordos de nível de serviço (SLAs) com clientes e usuários finais.

Os engenheiros de confiabilidade do local alcançam esse equilíbrio determinando um nível aceitável de risco operacional causado por aplicativos, chamado de 'orçamento de erro', e automatizando operações para atender a esse nível.

Em uma equipe de DevOps multifuncional, a SRE pode servir como uma ponte entre o desenvolvimento e as operações, fornecendo as métricas e a automação de que a equipe precisa para enviar mudanças de código e novos recursos por meio do pipeline de DevOps o mais rápido possível, sem 'quebrar' os termos dos SLAs das organizações.

Saiba mais sobre a engenharia de confiabilidade do site

DevOps e IBM Cloud

DevOps requer colaboração em negócios, desenvolvimento e partes interessadas em operação para agilizar e executar software confiável. As organizações que usam ferramentas e práticas DevOps enquanto transformam sua cultura criam uma base potente para a transformação digital e formam a modernização de seus aplicativos, conforme a necessidade de automação se amplia nos negócios e nas operações de TI.

Uma mudança em direção a uma maior automação deve começar com projetos pequenos e mensuráveis de sucesso, que você pode ajustar a escala e otimizar para outros processos e em outras partes da sua organização.

Trabalhando com a IBM, você terá acesso a Recursos de automação movidas por IA, incluindo fluxos de trabalho pré-desenvolvidos, para tornar cada processo de serviços de TI mais inteligente, liberando as equipes para se concentrarem nas questões de TI mais importantes e acelerar a inovação.

Dê o próximo passo:

Comece a usar com uma conta IBM Cloudhoje mesmo.

IBM Cloud Pak for Watson AIOps usa aprendizado de máquina e compreensão de linguagem natural para correlacionar dados estruturados e não estruturados em sua cadeia de ferramentas de operações em tempo real para descobrir insights ocultos e ajudar a identificar as causas básicas com mais rapidez. Eliminando a necessidade de vários dashboards de controle, o Watson AIOps alimenta insights e recomendações diretamente nos fluxos de trabalho de sua equipe para acelerar a resolução de incidentes.

Sobre o autor

Andrea C. Crawford é uma Distinguished Engineer na IBM com conhecimento em DevOps clássicos e modernos. Ela é apaixonada por ajudar o cliente a transformar a entrega de aplicativos por meio da modernização de pessoas, processos e ferramentas. Andrea gosta de explorar táticas “diferentes”, como jardinagem e andar de motocicleta.

https://twitter.com/acmthinks (link externo à IBM)

https://medium.com/@acmThinks (link externo à IBM)