DevOps é um processo de desenvolvimento de software que inclui uma mudança de cultura organizacional, focado em acelerar a entrega de um software de melhor qualidade. O DevOps automatiza e integra as equipes de desenvolvimento e de operações de TI, dois grupos que tradicionalmente atuavam separadamente ou em silos.

Esse processo visa atender à demanda dos usuários de software por recursos novos e inovadores lançados com frequência, além de desempenho e disponibilidade ininterruptos.

Os melhores processos e culturas do DevOps vão além do desenvolvimento e das operações para incorporar feedback de todos os stakeholders do aplicativo. A engenharia de plataforma e infraestrutura, o gerenciamento de segurança, conformidade, governança e risco, linha de negócios, usuários finais e clientes no ciclo de vida do desenvolvimento de software também são incluídos.

O DevOps representa o estado atual da evolução dos ciclos de entrega de software durante os últimos 20 anos ou mais, desde grandes lançamentos de código para todo o aplicativo a cada vários meses ou até anos, até atualizações iterativas de recursos ou funções menores lançadas com frequência diária, ou várias vezes por dia.

O ciclo de vida 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 de alta qualidade.

O nome e o número de fluxos de trabalho podem diferir dependendo de quem você questiona, mas eles tipicamente se resumem a estes seis:

• Planejamento (ou idealizaçã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 todos os stakeholders. 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 casos de usuários 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 construçã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, em seguida, 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 de implementação contínua). Aqui, o resultado da construção do tempo de execução (desde a integração) é implementado a um ambiente de tempo de execução, geralmente um ambiente de desenvolvimento em que os testes de tempo de execução são executados quanto à 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 estiverem 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 assim que a rede, o armazenamento, a plataforma, a capacidade de computação e a postura de segurança estejam todos funcionando corretamente. 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.
  
  
• Aprendizado (por 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 em que 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 a integração e a implementação. No entanto, o DevOps avançou de 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 CVE, linting), implementaçã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 para a identificação de risco e vulnerabilidade e fornece uma oportunidade para a TI aceitar, minimizar ou corrigir riscos.

Segurança: enquanto as metodologias em cascata e as implementações agile acrescentam fluxos de trabalho de segurança após a entrega ou a implementação, o DevOps se esforça para incorporar a segurança desde o início (Planejamento), quando problemas de segurança podem ser resolvidos mais facilmente e com menor custo e de forma contínua por 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 é melhor abordada no início e durante todo o ciclo de vida 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.

Os principais benefícios do DevOps são:

• Velocidade
• Implementação rápida
• Segurança
• Melhor colaboração
  
• Confiabilidade

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 eram meses ou até mesmo anos entre os lançamentos de software e, muitas vezes, várias correções (patches) significativas ou correções de erros (bugs) entre os lançamentos também. E esta abordagem "big bang" para entrega de recursos era geralmente caracterizada por planos complexos e arriscados de implementação, conexões difíceis de sincronizar com sistemas de envio e recebimento de dados e a "grande esperança" da 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 ágeis 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 integração contínua e a entrega contínua, ou CI/CD estão entre as mais importantes dessas metodologias. 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. A metodologia agile evoluiu a abordagem "big bang" para uma série de "explosões menores", que por sua vez compartimentam os riscos.

Quanto mais efetivamente essas práticas de desenvolvimento agile aceleravam o desenvolvimento e a entrega de software, mais elas expuseram as operações de TI ainda isoladas, como fornecimento, configuração, teste de aceitação, gerenciamento e monitoramento de sistema, como o próximo gargalo no ciclo de vida de entrega de software. 

Portanto, o DevOps foi além do Agile. Ele incluiu novos processos e ferramentas que estendem a iteração e a automação contínuas de CI/CD para o resto do ciclo de vida de entrega de software. E implementou uma estreita colaboração entre o desenvolvimento e as operações em cada etapa do processo.

As demandas do DevOps e da cultura DevOps valorizam as ferramentas que oferecem suporte à colaboração assíncrona, integram perfeitamente os 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:

• Ferramentas de gerenciamento de projeto: ferramentas que permitem às equipes criar uma lista não processada de casos de usuários (requisitos) que formam projetos de codificação, dividi-los em tarefas menores e acompanhar as tarefas até a conclusão. Muitas suportam práticas de gerenciamento de projetos agile, 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, a construção, o teste e a implementação de código. Jenkins é a ferramenta de software livre mais conhecida 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 situa entre o aplicativo e a infraestrutura como camadas de código. ArgoCD é outra escolha popular de software livre para CI/CD nativo de Kubernetes.
  
  
• Frameworks de automação de teste: incluem ferramentas de software, bibliotecas e melhores práticas para automatizar testes de unidade, de contrato, funcionais, de desempenho, de usabilidade, de invasão e de segurança. As melhores ferramentas dessa categoria oferecem suporte a vários linguagens 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 frameworks de teste é muito ampla. As frameworks 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 de cloud", abaixo).
  
  
• Ferramentas de monitoramento: estas ajudam as equipes de DevOps a identificar e resolver problemas do sistema; elas também agrupam e analisam dados em tempo real para revelar como alterações de código afetam o desempenho do aplicativo. 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 da criação de mapa de calor (gravação de ações dos usuários em tela), pesquisas ou aberturas de chamadas de problemas de autoatendimento.

É 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 softwares.

No nível organizacional, o DevOps requer comunicação, colaboração e responsabilidade compartilhada de forma contínua entre todos os stakeholders da entrega de software, ou seja, equipes de operações de TI e de desenvolvimento de software, mas também para equipes de linhas de negócios e de riscos, governança, conformidade e segurança, para proporcionar inovação de forma rápida e contínua e incorporar a qualidade no software desde o início.

Na maioria dos casos, a melhor forma de atingir este objetivo é eliminar esses silos e reorganizá-los em equipes autônomas e multifuncionais de DevOps que possam trabalhar em projetos de código do início ao fim, desde o planejamento até o feedback, sem delegar para outras equipes ou aguardar aprovação. Quando colocadas no contexto do desenvolvimento agile, a responsabilidade compartilhada e a colaboração são os alicerces de um foco em produto compartilhado que gera resultados valiosos.

No nível técnico, o DevOps requer comprometimento com a automação para manter os projetos em andamento dentro e entre os fluxos de trabalho e com feedback e medição  para possibilitar que as equipes acelerem os ciclos de forma contínua e para que melhorem a qualidade e o desempenho do software.

Nativo da cloud é uma abordagem para construir aplicativos que utilizam tecnologias básicas da cloud computing. O objetivo do desenvolvimento nativo de cloud é possibilitar um desenvolvimento, implementação, gerenciamento e desempenho consistentes e otimizados em aplicativos, tanto em ambientes da cloud pública, privada quanto em ambientes multi-cloud. 

Atualmente, os aplicativos nativos da cloud são geralmente:

• Desenvolvidos usando microsserviços: componentes livremente acoplados e implementáveis de forma independente que têm sua própria pilha autocontida e se comunicam entre si por meio de APIs de REST, fluxo de eventos ou brokers de mensagens.
  
  
• Implementados em contêineres: unidades executáveis de código que contêm todas as dependências de código, de tempos de execução e do sistema operacional necessárias para executar o aplicativo. (Para a maioria das organizações, "contêineres" é sinônimo de contêineres Docker, mas outros tipos de contêineres existem).
  
  
• Operados (em escala) usando Kubernetes, uma plataforma de orquestração de contêiner de software livre usada para planejar e automatizar a implementação, o gerenciamento e o ajuste de escala de aplicativos conteinerizados.

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

Por exemplo, desenvolver e atualizar microsserviços, ou seja, a entrega iterativa de pequenas unidades de código a uma pequena base de código é a solução perfeita para a liberação rápida de DevOps e de ciclos de gerenciamento. E seria difícil lidar com a complexidade de uma arquitetura de microsserviços sem a implementação e a operação do 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 que investiram na arquitetura; 56% dos não usuários provavelmente adotarão microsserviços nos próximos dois anos. 

Ao agrupar 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.

A maioria dos principais provedores da cloud computing , incluindo AWS, Google, Microsoft Azure e IBM Cloud, oferecem algum tipo de solução de pipeline de DevOps gerenciado.

DevSecOps é o DevOps que integra e automatiza continuamente a segurança ao longo do 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ível) 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 considerada 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, conforme planejado originalmente. No DevSecOps, a segurança é um cidadão e um stakeholder de "primeira classe" junto com o desenvolvimento  e as operações, e traz segurança para o processo de desenvolvimento com foco no produto.

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

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

Os engenheiros de confiabilidade de site obtêm esse equilíbrio ao determinar um nível aceitável de risco operacional causado por aplicativos, chamado de um "orçamento de erro", e ao automatizar operações para alcançar esse nível. 

Em uma equipe multifuncional de DevOps, o 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 alterações de código e novos recursos por meio do pipeline de DevOps o mais rápido possível, sem "quebrar" os termos dos SLAs da organização. 

Saiba mais sobre a engenharia de confiabilidade do site