A empresa só terá retorno no investimento quando o software estiver realmente rodando em produção. O problema da última milha só é visível quando s...

A empresa só terá retorno no investimento quando o software estiver realmente rodando em produção. O problema da última milha só é visível quando se toma uma visão holística do processo. Para resolvê–lo é preciso olhar além das barreiras impostas entre as diferentes equipes envolvidas: seja a equipe de negócios, a equipe de desenvolvimento ou a equipe de operações. Uma abordagem alternativa: DevOps e entrega contínua. Muitas empresas de sucesso na internet – como Google, Amazon, Netflix, Flickr, GitHub e Facebook – perceberam que a tecnologia pode ser usada a seu favor e que o atraso no deploy para produção significa atrasar sua habilidade de competir e se adaptar a mudanças no mercado. É comum que elas realizem dezenas ou até centenas de deploys por dia! Essa linha de pensamento que tenta diminuir o tempo entre a criação de uma ideia e sua implementação em produção é também conhecida como “Entrega Contínua” [6] e está revolucionando o processo de desenvolvimento e entrega de software. Alguns autores preferem utilizar o termo em inglês, continuous delivery. Quando o processo de deploy deixa de ser uma cerimônia e passa a se tornar algo corriqueiro, o ciclo vicioso da figura 1.1 se inverte completamente. O aumento da frequência de deploys faz com que a quantidade de mudanças em cada deploy diminua, reduzindo também o risco associado com aquele deploy. Esse benefício não é algo intuitivo, porém quando algo dá errado é muito mais fácil descobrir o que aconteceu, pois a quantidade de fatores que podem ter causado o problema é menor. No entanto, a diminuição do risco não implica na remoção completa dos processos criados entre as equipes de desenvolvimento e de operações. O segredo que permite a inversão do ciclo é a automatização desse processo, conforme mostra a figura 1.2. Automatizar o processo de deploy permite que ele seja executado a qualquer momento de forma confiável, removendo o risco de um erro humano causar problemas. Investir em automatização não é uma ideia nova, muitas equipes já escrevem testes automatizados como parte do processo de desenvolvimento de software. Práticas como o desenvolvimento dirigido a testes (Test-Driven Development ou TDD) [3] ou a integração contínua [12] – que será discutida em mais detalhes no capítulo 6 – são comuns e amplamente aceitas na comunidade de desenvolvimento. Esse foco em automação de testes, juntamente com a criação de equipes multidisciplinares, ajudou a quebrar a barreira existente entre desenvolvedores, testadores e analistas de negócio, criando uma cultura de colaboração entre pessoas com habilidades complementares trabalhando como parte da mesma equipe. Inspirado no sucesso dos métodos ágeis, um novo movimento surgiu para levar a mesma linha de raciocínio para o próximo nível: o movimento DevOps. Seu objetivo é criar uma cultura de colaboração entre as equipes de desenvolvimento e de operações que permite aumentar o fluxo de trabalho completado – maior frequência de deploys – ao mesmo tempo aumentando a estabilidade e robustez do ambiente de produção. Além de uma mudança cultural, o movimento DevOps enfoca bastante nas práticas de automação das diversas atividades necessárias para atacar a última milha e entregar código de qualidade em produção, como: compilação do código, testes automatizados, empacotamento, criação de ambientes para teste ou produção, configuração da infraestrutura, migração de dados, monitoramento, agregamento de logs e métricas, auditoria, segurança, desempenho, deploy, entre outros. Empresas que aplicaram essas práticas de DevOps com sucesso não enxergam mais o departamento de TI como um gargalo mas sim como um agente de capacitação do negócio. Elas conseguem se adaptar a mudanças no mercado rapidamente e realizar diversos deploys por dia de forma segura. Algumas delas inclusive fazem com que um novo desenvolvedor realize um deploy para produção no seu primeiro dia de trabalho! Este livro irá apresentar, através de exemplos reais, as principais práticas de DevOps e Entrega Contínua para permitir que você replique o mesmo sucesso na sua empresa. O objetivo principal do livro é aproximar as comunidades de desenvolvimento e de operações. Desenvolvedores conhecerão um pouco mais sobre as preocupações e práticas envolvidas para operar e manter sistemas estáveis em produção, enquanto engenheiros e administradores de sistema irão aprender como introduzir mudanças de forma segura e incremental através de automação. Sobre o livro: O principal objetivo do livro é mostrar na prática como aplicar os conceitos e técnicas de DevOps e Entrega Contínua. Por esse motivo, tivemos que escolher quais tecnologias e ferramentas utilizar. Nossa preferência foi usar linguagens e ferramentas de código livre e priorizamos aquelas que são bastante usadas na indústria. Você vai precisar usar as ferramentas escolhidas para acompanhar os exemplos de código. Porém, sempre que apresentarmos uma nova ferramenta, vamos discutir um pouco sobre as outras alternativas, para que você possa pesquisar qual opção faz mais sentido no seu contexto. Você não precisa de nenhum conhecimento prévio específico para acompanhar os exemplos. Se você tiver experiência no ecossistema Java ou Ruby, será um bônus. Nosso ambiente de produção vai rodar em UNIX (Linux, para ser mais específico), portanto um pouco de conhecimento no uso da linha de comando pode ajudar mas não é obrigatório [13]. De toda forma, você vai ser capaz de rodar todos os exemplos na sua própria máquina, independente se está rodando Linux, Mac ou Windows. Público alvo: Este livro é voltado para desenvolvedores, engenheiros de sistema, administradores de sistema, arquitetos, gerentes e qualquer pessoa com conhecimentos técnicos que tenha interesse em aprender mais sobre as práticas de DevOps e Entrega Contínua. Estrutura dos capítulos: O livro foi escrito para ser lido do início ao fim de forma sequencial. Dependendo da sua experiência com o assunto abordado em cada capítulo, você pode preferir avançar ou seguir em uma ordem diferente. No capítulo 2 apresentamos a aplicação de exemplo que será usada no restante do livro e as tecnologias usadas para construí-la. Como o foco do livro não é no desenvolvimento da aplicação em si, usamos uma aplicação não trivial escrita em Java e usando diversas bibliotecas bem comuns no ecossistema Java. Ao final do capítulo, a aplicação vai estar rodando em produção. Com um ambiente de produção no ar, no capítulo 3 vamos vestir o chapéu do time de operações e configurar um servidor de monitoramento para detectar falhas e enviar notificações sempre que algum problema for encontrado. Ao final do capítulo, seremos notificados de que um dos servidores caiu. No capítulo 4 vamos reconstruir o servidor problemático, dessa vez de forma automatizada, tratando a infraestrutura como código. O capítulo 5 é uma continuação do assunto, abordando tópicos mais avançados e refatorando o código para torná-lo mais modular, legível e extensível. Após vestir o chapéu do time de operações, iremos voltar nossa atenção para o desenvolvimento de software. O capítulo 6 discute práticas de engenharia ágil que ajudam a escrever código de qualidade. Vamos aprender sobre os diversos tipos de testes automatizados e subir um novo servidor dedicado para fazer integração contínua do código da nossa aplicação. Apresentamos o conceito da pipeline de entrega no capítulo 7. Colocamos o código de infraestrutura na integração contínua e implementamos um processo automatizado para instalar a versão mais nova da aplicação em produção com o simples clique de um botão. No capítulo 8 migramos o ambiente de produção para a nuvem. Por fim, discutimos tópicos mais avançados, com ponteiros para recursos onde você pode pesquisar e aprender mais sobre os assuntos que ficaram de fora do escopo deste livro. Convenções de código: Nos exemplos de código, vamos usar reticências ... para omitir as partes não importantes. Quando o código já existe, vamos repetir as linhas ao redor da área que precisa ser alterada para dar um pouco de contexto sobre a modificação. Quando a linha é muito comprida e não couber na página, vamos usar uma barra invertida \
para indicar que a próxima linha no livro é a continuação da linha anterior. Você pode simplesmente ignorar a barra invertida e continuar digitando na mesma linha. Nos exemplos na linha de comando, além da barra invertida, usaremos um sinal de maior > na próxima linha para indicar que ela ainda é parte do mesmo comando. Isto é para distinguir o comando que precisa ser digitado da saída que o comando produz quando for executado. Ao executar os comandos, você pode simplesmente digitar tudo na mesma linha, ignorando a \ e o >.