DevOps

DevOps

1. É um termo criado para descrever um conjunto de práticas para integração entre as equipes de desenvolvimento de softwares, operações e de apoio envolvidas e a adoção de processos automatizados para produção rápida e segura de aplicações e serviços.

   • Sprint/Tarefa
     • Implantação (deploy)
     • Liberação (release)
     • Entrega (delivery)
   • Em organizações tradicionais, a área de T.I era dividida em dois departamentos:
     • Departamento de Sistemas (ou Desenvolvimento), formado por desenvolvedores, programadores, analistas, arquitetos, etc.
     • Departamento de Operações, no qual ficavam alocados os administradores de rede, administradores de bancos de dados, técnicos de suporte, técnicos de infraestrutura, etc.
   • Princípios para entrega de software:
     • Crie um processo repetível e confiável para entrega de software: A ideia é que a entrega de software não pode ser um evento traumático, com passos manuais e sujeitos a surpresas. Em vez disso, colocar um software em produção deve ser tão simples como apertar um botão.
     • Automatize tudo que for possível: Advoga-se que todos os passos para entrega de um software devem ser automáticos, incluindo seu build, a execução dos testes, a configuração e ativação dos servidores e da rede, a carga do banco de dados
     • Mantenha tudo em um sistema de controle de versões: Tudo no enunciado do princípio refere-se não apenas a todo o código fonte, mas também arquivos e scripts de administração do sistema, documentação, páginas Web, arquivos de dados, etc.
     • Se um passo causa dor, execute-o com mais frequência e o quanto antes: Esse princípio não tem uma inspiração masoquista. Em vez disso, a ideia é antecipar os problemas, antes que eles se acumulem e as soluções fiquem complicadas. O exemplo clássico é o de Integração Contínua.
     • "Concluído" significa pronto para entrega: Esse princípio defende então que concluído, em projetos de software, deve ter uma semântica clara, isto é: 100% pronto para entrar em produção.
     • Todos são responsáveis pela entrega do software: Não admite-se mais que os times de desenvolvimento e de operações trabalham em silos independentes e troquem informações apenas na véspera de uma implantação.

2. Controle de Versões

   • Sistema de Controle de Versões (VCS)
     • Repositório: para armazenar a versão mais recente do código fonte de um sistema, bem como de arquivos relacionados, como arquivos de documentação, configuração, páginas Web, manuais, etc.
     • Ele permite que se recupere versões mais antigas de qualquer arquivo, caso seja necessário.
   • Sistemas de Controle de Versões Distribuídos (DVCS)
     • Em vez de uma arquitetura cliente/servidor, um DVCS adota uma arquitetura peer-to-peer. Na prática, isso significa que cada desenvolvedor possui em sua máquina um servidor completo de controle de versões, que pode se comunicar com os servidores de outras máquinas
     • Vantagens dos DVCS comparados com VCS
       • Trabalhar e gerenciar versões de forma offline, sem estar conectado a uma rede
       • Realizar commits com mais frequência
       • Commits são executados em menos tempo, isto é, eles são operações mais rápidas e leves.
       • A sincronização não precisa ser sempre com o repositório central. Em vez disso, dois nodos podem também sincronizar os seus repositórios.
     • Git: É um sistema de controle de versões distribuído cujo desenvolvimento foi liderado por Linus Torvalds, também responsável pela criação do sistema operacional Linux.
     • GitHub: É um serviço de hospedagem de código que usa o sistema Git para prover controle de versões. O GitHub oferece repositórios públicos e gratuitos, para projetos de código aberto, e repositórios fechados e pagos, para uso por empresas.

3. Integração Contínua: é a prática de mesclar todas as cópias de trabalho dos desenvolvedores em uma linha principal compartilhada, várias vezes ao dia.

   • Motivação
     • Branch principal
       • Branches de funcionalidades (feature branches)
       • Master (quando usa-se Git)
       • Trunk (quando usa-se outros sistemas, como svn)
         • Merge
           • Conflitos de integração
           • Conflitos de merge.
   • Boas Práticas para Uso de CI
     • Build Automatizado: Build é o nome usado para designar a compilação de todos os arquivos de um sistema, até a geração de uma versão executável. Não deve incluir nenhum passo manual
     • Testes Automatizados: Além de garantir que o sistema compila sem erros após cada novo commit, é importante garantir também que ele continua com o comportamento esperado.
     • Servidores de Integração Contínua: Após um novo commit, o sistema de controle de versões avisa o servidor de CI, que clona o repositório e executa um build completo do sistema, bem como roda todos os testes. Após a execução do build e dos testes, o servidor notifica o usuário.
     • Desenvolvimento Baseado no Trunk: não existem mais branches para implementação de novas funcionalidades ou para correção de bugs. Em vez disso, todo desenvolvimento ocorre no branch principal, também conhecido com trunk ou master.
     • Programação em Pares: pode ser considerada uma forma contínua de revisão de código, assim como builds e testes contínuos, recomenda-se usar programação em pares com CI. Porém, esse uso também não é obrigatório.

4. Deployment Contínuo: A implantação contínua é uma abordagem de engenharia de software na qual as funcionalidades do software são fornecidas com frequência por meio de implantações automatizadas.

   • Entrega Contínua (Continuous Delivery): todas as mudanças levadas para o repositório principal estão prontas para deploy em produção, mas o início desse processo ainda requer interação humana.
     • Deployment: é o processo de liberar uma nova versão de um sistema para seus usuários.
     • Delivery: é o processo de liberar uma nova versão de um sistema para ser objeto de deployment.
   • Feature Flags / Feature toggle: alternância de recursos é uma técnica de desenvolvimento de software que tenta fornecer uma alternativa para manter várias ramificações no código-fonte, de forma que um recurso de software possa ser testado antes mesmo de ser concluído e estar pronto para o lançamento.

Images and files in the map