├── .gitignore ├── .gitlab-ci.yml ├── 01-sobre-o-curso.md ├── 02-devops.md ├── 03-lean.md ├── 04-projeto.md ├── 05-build.md ├── 06-controle-versao.md ├── 07-testes-automatizados.md ├── 08-integracao-continua.md ├── 09-entrega-continua.md ├── 10-deploy-continuo.md ├── 11-monitoramento-continuo.md ├── LICENSE.MD ├── README.md ├── arquivos-curso ├── manual-build.pdf ├── manual-deploy.pdf ├── script-inicial.sql └── tomcat.service ├── book.properties ├── cover.jpg └── imagens ├── capitulo-02 ├── agile-manifesto.png ├── apollo-11.jpg ├── eniac-devs.png ├── eniac.png ├── margaret-hamilton.png ├── nato.png ├── patrick-debois.png └── tools.png ├── capitulo-03 ├── kanban-base.png ├── kanban-pull.png └── kanban-push.png ├── capitulo-04 ├── alura-home.png ├── forum-cadastro.png ├── forum-dashboard.png ├── forum-login.png ├── forum-perfil.png ├── forum-senha.png ├── forum-topico-detalhe.png ├── forum-topico-responder.png └── forum-topicos.png ├── capitulo-05 ├── convert-maven-project.png ├── maven-build-artefatos.png ├── maven-build-eclipse-sucesso.png ├── maven-build-eclipse.png └── maven-info.png ├── capitulo-06 ├── download-git.png ├── gitlab-new-project.png └── gitlab-site.png ├── capitulo-07 ├── build-path-add-folder.png ├── build-path-finalizado.png ├── build-path-folder-name.png ├── build-path-lista.png ├── build-path-opcao.png ├── build-path-output-folder.png ├── jacoco-relatorio.png ├── junit-new-test-case.png ├── junit-teste-falha-2.png ├── junit-teste-falha.png ├── junit-teste-sucesso-2.png ├── junit-teste-sucesso.png └── piramide-testes.png ├── capitulo-08 ├── jenkins-build-now.png ├── jenkins-build-resultado.png ├── jenkins-form-admin.png ├── jenkins-home.png ├── jenkins-instancia.png ├── jenkins-logo.png ├── jenkins-manage-plugins-available.png ├── jenkins-manage-plugins-install.png ├── jenkins-manage-plugins.png ├── jenkins-new-item-build-triggers.png ├── jenkins-new-item-build.png ├── jenkins-new-item-scm.png ├── jenkins-new-item.png ├── jenkins-plugin-green-ball.png ├── jenkins-plugin-radiator-botao.png ├── jenkins-plugin-radiator-form.png ├── jenkins-plugin-radiator-tela.png ├── jenkins-plugin-test-results-analyzer.png ├── jenkins-plugins-git.png ├── jenkins-plugins-modo.png ├── jenkins-plugins-none.png ├── jenkins-senha-tela.png ├── jenkins-senha-terminal.png ├── jenkins-site-plugins.png └── tv-build.jpeg ├── capitulo-09 ├── blue-green-1.png ├── blue-green-2.png ├── canary-release.png ├── deployment-pipeline.png ├── jenkins-build-now.png ├── jenkins-new-item-build-maven.png ├── jenkins-new-item-build-vagrant.png ├── jenkins-new-item-scm.png ├── jenkins-new-item.png ├── lead-time.png ├── metricas-performance.png ├── vagrant-cloud.png ├── vagrant-download.png ├── vagrant-logo.png ├── vagrant-vm-virtualbox.png └── war-room.png ├── capitulo-10 └── jenkins-copy-item.png └── capitulo-11 └── dashboard.jpg /.gitignore: -------------------------------------------------------------------------------- 1 | .build/ 2 | .DS_Store 3 | -------------------------------------------------------------------------------- /.gitlab-ci.yml: -------------------------------------------------------------------------------- 1 | stages: 2 | - build 3 | - dropbox 4 | - alumni 5 | 6 | build-apostila: 7 | script: "build-apostila.sh" 8 | stage: build 9 | artifacts: 10 | name: "Apostilas" 11 | paths: 12 | - apostilas/ 13 | 14 | upload-dropbox: 15 | script: "upload-dropbox.sh" 16 | stage: dropbox 17 | only: 18 | refs: 19 | - master 20 | dependencies: 21 | - build-apostila 22 | 23 | upload-alumni: 24 | script: "upload-alumni.sh" 25 | stage: alumni 26 | only: 27 | refs: 28 | - master 29 | dependencies: 30 | - build-apostila 31 | -------------------------------------------------------------------------------- /01-sobre-o-curso.md: -------------------------------------------------------------------------------- 1 | # Sobre o curso 2 | 3 | ## DevOps 4 | 5 | A Essência do movimento DevOps é criar uma cultura de **colaboração** entre os times de **Dev** e **Ops**, com o objetivo de melhorar o processo de desenvolvimento, entrega e operação de softwares, de maneira ágil, segura e estável, utilizando como base para isso o mindset dos movimentos **Agile** e **Lean**, juntamente com a utilização de práticas ágeis e ferramentas focadas em **automatização**. 6 | 7 | DevOps não é uma tecnologia, ferramenta ou processo a ser implantado em uma empresa, mas sim uma **filosofia** que une os **valores**, **princípios**, **práticas** e **ferramentas** dos times de desenvolvimento e operações dela, com o objetivo de aumentar sua capacidade e **agilidade** de **inovação**, por meio da criação e manutenção de produtos de tecnologia, fazendo assim com que ela se torne mais competitiva no mercado. 8 | 9 | ## O curso 10 | 11 | Esse curso é para pessoas que trabalham com desenvolvimento e/ou infraestrutura e queiram aprender sobre como melhorar o processo de desenvolvimento, entrega e operação de software em suas empresas. 12 | 13 | No curso vamos aprender sobre os principais problemas e atritos que existem entre os times de desenvolvimento e operações, que motivou a criação do movimento DevOps, e como fazer para evitá-los e promover uma cultura de colaboração, focada na entrega rápida, confiável e segura de software. 14 | 15 | Veremos a importância e o impacto de alguns tópicos culturais, tais como: colaboração, comunicação, feedback, respeito e lean, e como fazer para aplicá-los no dia a dia. 16 | 17 | Também vamos aprender sobre o papel das ferramentas e da automatização em um ambiente DevOps, utilizando algumas delas para melhorar o processo de build, deploy e monitoração de um aplicação, tais como: Git, Jenkins, Vagrant, Ansible, Docker e Prometheus. 18 | 19 | ## Código fonte 20 | 21 | O código fonte do projeto que será utilizado como exemplo nesse curso está disponível no GitLab, no seguinte endereço: https://gitlab.com/aovs/projetos-cursos/do25-alura-forum 22 | 23 | Fique à vontade para navegar pelo código fonte do projeto e baixá-lo para realizar os exercícios em seu computador. 24 | 25 | ## Bibliografia complementar 26 | 27 | Para complementar seus estudos e aprimorar ainda mais seus conhecimentos sobre DevOps, recomendamos a leitura dos seguintes livros: 28 | 29 | * [Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale](https://www.amazon.com/Effective-DevOps-Building-Collaboration-Affinity/dp/1491926309) 30 | * [The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win](https://www.amazon.com/Phoenix-Project-Helping-Business-Anniversary/dp/B00VATFAMI) 31 | * [The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations](https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/B0767N1MM2) 32 | * [Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations](https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339) 33 | -------------------------------------------------------------------------------- /02-devops.md: -------------------------------------------------------------------------------- 1 | # DevOps 2 | 3 | Neste capítulo vamos aprender sobre o que é DevOps e entender sua história e motivação. Aprenderemos sobre os problemas recorrentes na área de tecnologia, em especial na área de desenvolvimento de software, que foram a grande inspiração para a criação da filosofia DevOps. 4 | 5 | Também vamos discutir sobre alguns dos principais mitos a respeito desse tema e porque não devemos nos preocupar com eles. 6 | 7 | ## O que é DevOps 8 | 9 | DevOps é um conceito um pouco complicado de explicar e definir, pois existem diversas opiniões distintas sobre ele na literatura e internet, e também por se tratar de algo bastante subjetivo, pois cada profissional e empresa possui um ambiente e contexto totalmente diferente, possuindo assim experiências distintas sobre o tema. 10 | 11 | Na nossa opinião, gostamos de definir DevOps da seguinte maneira: 12 | 13 | > **Filosofia** que une os **valores**, **princípios**, **práticas** e **ferramentas** dos times de desenvolvimento e operações de uma empresa, com o objetivo de aumentar sua capacidade e **agilidade** de **inovação**, por meio da criação e manutenção de produtos de tecnologia, fazendo assim com que ela se torne mais competitiva no mercado. 14 | 15 | Repare que é uma definição um pouco abstrata, da mesma forma que encontramos a definição de metodologias ágeis e do próprio manifesto ágil, pois a ideia não é te induzir a uma única maneira de fazer DevOps, focando em determinadas praticas e ferramentas, mas sim entender os princípios e valores por trás delas. 16 | 17 | Ao longo desse capítulo vamos estudar sobre a história do DevOps, algo que vai facilitar bastante no entendimento da nossa visão e definição dele. 18 | 19 | ## A história do desenvolvimento de software 20 | 21 | Para entender melhor o que é DevOps é necessário voltar ao passado, entendendo como a nossa área nasceu, evoluiu e chegou aos problemas aos quais o DevOps veio para tentar resolver. 22 | 23 | Voltaremos então ao ano de 1943, no qual ocorreu um grande marco para a área de desenvolvimento de software, pois nele iniciou-se um dos projetos de software mais famoso do mundo, que foi o projeto **ENIAC**. 24 | 25 | ### ENIAC - Electronic Numerical Integrator and Computer 26 | 27 | ![Fotos do computador ENIAC](imagens/capitulo-02/eniac.png) 28 | 29 | Em 1943, durante a 2ª guerra mundial, o governo dos Estados Unidos da América iniciou um projeto secreto, com o objetivo de criar uma máquina capaz de realizar cálculos balísticos complexos em poucos segundos. 30 | 31 | Nasce assim o projeto que ficou conhecido como **Electronic Numerical Integrator and Computer**, abreviado de **ENIAC**. 32 | 33 | Alguns engenheiros da Universidade de Pennsylvania foram responsáveis por construir o hardware do ENIAC, que pesava quase 30 toneladas e ocupava uma área de quase 170 metros quadrados. 34 | 35 | Após o hardware ser concluído, foi necessário o desenvolvimento de um software para operá-lo, sendo que seis mulheres matemáticas participaram desse projeto e assim criaram o primeiro sistema de computador eletrônico programável do mundo, que foi desenvolvido sem o uso de linguagens de programação ou quaisquer ferramentas, utilizando apenas diagramas lógicos e dispositivos eletrônicos. 36 | 37 | ![Foto das seis desenvolvedoras do software do ENIAC](imagens/capitulo-02/eniac-devs.png) 38 | 39 | Naquela época a indústria focava apenas em hardwares, sendo que quando problemas surgiam os engenheiros de hardware costumavam dizer: “O problema não é o hardware, mas quem está o operando”. 40 | 41 | O projeto ENIAC foi concluído em 1945 e seu primeiro teste real foi realizado no dia 10 de dezembro desse mesmo ano. 42 | 43 | Esse foi o marco de início de uma nova área, focada no desenvolvimento de softwares para controle de hardwares. 44 | 45 | > **ENIAC Programmers Project** 46 | > 47 | > Embora o software do ENIAC tenha sido desenvolvido por seis mulheres, que são consideradas como pioneiras da área de desenvolvimento de software, elas nunca tiveram o merecido reconhecimento e suas histórias ficaram perdidas no passado. 48 | > 49 | > Kathy Kleiman, uma jovem desenvolvedora de softwares, iniciou nos anos 90 uma busca pela verdadeira história por trás do desenvolvimento do software do ENIAC e criou um projeto chamado **ENIAC Programmers Project**, com o objetivo de resgatar e divulgar a história perdida das seis desenvolvedoras que participaram da construção do software do ENIAC. 50 | > 51 | > Para saber mais sobre esse projeto acesse o site: https://eniacprogrammers.org 52 | 53 | ### Projeto Apollo 54 | 55 | ![Foto do astronauta sobre o solo da lua](imagens/capitulo-02/apollo-11.jpg) 56 | 57 | Após o projeto ENIAC ser concluído, milhares de outros projetos de software foram iniciados ao redor do mundo, sendo que na década de 60 um desses projetos era bastante ambicioso e com grande impacto mundial. 58 | 59 | Em 1961, o presidente americano John Kennedy anunciou que em 10 anos os Estados Unidos da América levariam uma pessoa à lua, a trazendo de volta para a Terra em segurança. Criou-se então um projeto, batizado de Apollo, sendo sua missão atribuída à NASA. 60 | 61 | Para realizar tal missão a NASA precisava construir um foguete e também de alguém capaz de desenvolver um software complexo para controle aéreo, que seria utilizado nesse foguete a ser enviado à lua. 62 | 63 | Margaret Hamilton, uma matemática do MIT, foi a pessoa escolhida como responsável por chefiar a equipe de desenvolvimento de tal software. 64 | 65 | ![Foto da Margaret Hamilton](imagens/capitulo-02/margaret-hamilton.png) 66 | 67 | Devido às limitações de hardware do módulo lunar, o software que Margaret e sua equipe desenvolveram era flexível a ponto de permitir que ele pudesse ser sobrescrito manualmente, para que o piloto o controlasse utilizando controles manuais. 68 | 69 | O projeto foi concluído em 1969 e o foguete foi lançado da terra em 16 de julho desse mesmo ano, retornando para a terra no dia 24 de julho, após oito longos dias de missão no espaço. 70 | 71 | Durante o desenvolvimento do software, Margaret Hamilton definiu alguns itens como sendo críticos para garantir sua qualidade, tais como: 72 | 73 | * Debug individual de todos os componentes; 74 | * Testes individuais de todos os componentes; e 75 | * Testes de integração entre os componentes. 76 | 77 | Nasce assim o termo **Software Engineering**, na qual Margaret Hamilton foi uma das pioneiras em especializar e profissionalizar a então nova área de desenvolvimento de softwares, que estava ficando cada vez mais popular e utilizada no mundo inteiro. 78 | 79 | > **O primeiro projeto DevOps do mundo?** 80 | > 81 | > Graças à liberdade, autonomia, confiança e respeito entre todas as pessoas envolvidas no projeto Apollo, a missão foi bem-sucedida. 82 | > 83 | > Ao ler sobre a história do Apollo é possível identificar como os valores e princípios do modelo DevOps ali estavam presentes e contribuíram bastante para o sucesso do projeto como um todo. 84 | > 85 | > Sendo assim, podemos considerar o Apollo como sendo o primeiro projeto DevOps do mundo, embora naquela época esse termo sequer existia :) 86 | 87 | ### Software Crisis 88 | 89 | Embora os projetos ENIAC e Apollo tenham sido bem-sucedidos, ao redor do mundo a grande maioria dos projetos de software fracassava e muitos problemas começaram a surgir, visto que essa era uma área nova e que não seguia os padrões das outras engenharias. 90 | 91 | Em 1967, o `NATO Science Committee` criou um grupo de estudos sobre Ciência da Computação, formado por cientistas de diversos países e indústrias, com o objetivo de discutir sobre o estado atual da área de engenharia de software. 92 | 93 | Foram formados três grupos focados em discutir sobre projeto de software, desenvolvimento de software e operação de software, com objetivos de definir, descrever e começar a pensar em como resolver os problemas da engenharia de software. 94 | 95 | Em 1968, ocorreu a primeira `NATO Software Engineering Conference`, na qual foram identificados os principais problemas da engenharia de software, dentre eles: 96 | 97 | * Definição e métricas de sucesso do projeto; 98 | * Softwares complexos que exigem investimentos altos e viabilidade incerta; 99 | * Entregar projetos dentro do orçamento previsto; 100 | * Entregar projetos no prazo previsto; e 101 | * Entregar projetos de acordo com as especificações. 102 | 103 | ![Foto da NATO Software Engineering Conference](imagens/capitulo-02/nato.png) 104 | 105 | Nessa conferencia se cunhou então o termo **Software Crisis**, para descrever o cenário problemático atual da área de engenharia de software. 106 | 107 | Posteriormente, a partir de 1979, a tecnologia começou a evoluir bastante, em especial na área de redes, na qual empresas e universidades estavam utilizando novas tecnologias para compartilhar informações. 108 | 109 | Entretanto, compartilhar informações não era visto com bons olhos pelas empresas, pois elas não queriam que seu modo de operar fosse exposto, pois ele era considerado como informação estratégica. 110 | 111 | Esse **isolamento** entre as empresas acabou levando a um aumento na complexidade de seus sistemas, algo que motivou a necessidade de especialização de perfis e aumento no número de papéis relacionados a área de tecnologia. 112 | 113 | E assim se inicia, infelizmente, o surgimento de **silos** dentro da área de tecnologia, pois de um lado estavam os **engenheiros de software**, especializados no desenvolvimento e manutenção de produtos, e do outro estavam os **sysadmins**, especializados na operação dos sistemas. 114 | 115 | Cada um desses dois perfis têm habilidades e necessidades distintas, sendo que em situações de problemas é comum que não haja uma colaboração entre eles. 116 | 117 | Aqui foi justamente onde a engenharia de software “desandou”, algo bem diferente do que aconteceu no projeto Apollo. 118 | 119 | O problema foi que as tecnologias de software evoluíram muito rapidamente, forçando as empresas a aumentarem sua flexibilidade e velocidade de evolução para continuarem competitivas no mercado. 120 | 121 | Mas essa velocidade de evolução e necessidade de constantes mudanças causou problemas e atritos entre as equipes de desenvolvedores e sysadmins, pois ela afetava a estabilidade nos sistemas e aumentava o risco de problemas surgirem. 122 | 123 | E com isso se inicia uma nova era de grande **resistência às mudanças**. 124 | 125 | ### Agile Manifesto 126 | 127 | Após um tempo de caos e diversos problemas recorrentes na área de engenharia de software, nasce um movimento denominado **Agile**, com o manifesto ágil publicado em 2001. 128 | 129 | ![Foto dos valores do Manifesto Ágil](imagens/capitulo-02/agile-manifesto.png) 130 | 131 | O manifesto ágil surgiu de uma reunião entre 17 engenheiros de software que buscavam por melhores formas de desenvolver softwares e como lidar com os problemas enfrentados no mercado. 132 | 133 | Nesse encontro eles compartilharam seus valores e princípios, e também como acreditavam que o desenvolvimento de softwares deveria ser, sendo comum entre ele um foco grande em **ciclos de release curtos**, **adaptação às mudanças** e forte **ênfase nas pessoas**. 134 | 135 | Algumas metodologias de desenvolvimento de software alinhadas ao manifesto ágil foram surgindo e se popularizando. Dentre elas: Scrum, XP e Kanban. 136 | 137 | Esse foi um grande marco na história da área de desenvolvimento de software, pois o manifesto e as metodologias ágeis resgataram os valores e princípios da época do projeto Apollo, aumentando bastante com isso o sucesso dos projetos de software ao redor do mundo. 138 | 139 | ## A história do DevOps 140 | 141 | Agora que já aprendemos sobre a origem, evolução e problemas enfrentados pela área de desenvolvimento de software, vai ficar mais fácil de entender o que motivou o movimento DevOps. 142 | 143 | ### Dev vs. Ops 144 | 145 | Mesmo com o manifesto e as metodologias ágeis sendo utilizadas como principal abordagem para o desenvolvimento de softwares, alguns problemas ainda persistiam no mercado. 146 | 147 | O grande problema é que a área de operações, também conhecida como infraestrutura, era tratada de maneira **isolada** da área de desenvolvimento, o que acabou criando um **silo** entre essas duas áreas. 148 | 149 | De um lado está o time de desenvolvimento, trabalhando de maneira ágil, buscando autonomia e necessitando de ciclos de release cada vez mais curtos, mas do outro lado está o time de operações, que possui outro ritmo de trabalho e processos que exigem mais controle, governança e estabilidade. 150 | 151 | São duas áreas com ideias, necessidades e processos distintos, que às vezes podem entrar em conflito, gerando um atrito entre esses dois times. 152 | 153 | O resultado desse conflito foi a perda de agilidade da empresa em inovação, o que geralmente a fazia perder o **Time to Market** ao tentar desenvolver uma nova ideia de negócio. 154 | 155 | A única maneira de resolver tal situação era juntando os times de desenvolvimento e operações, fazendo com que eles trabalhassem como um time só, com metas compartilhadas e entendendo suas necessidades, problemas, valores e princípios, para que assim pudessem pensar juntos em como resolver os problemas e melhorar a capacidade e agilidade de inovação de sua empresa. 156 | 157 | Foi justamente para resolver esses problemas que alguns sysadmins começaram a se interessar pelo tema `Agile` e foram buscar por maneiras de o utilizar também na área de infraestrutura. 158 | 159 | ### Agile Infrastructure 160 | 161 | Em 2008, no evento `Agile Conference`, Patrick DuBois e Andrew Schafer se reuniram para discutir sobre um tópico pouco explorado na comunidade: **Agile Infrastructure**. 162 | 163 | Eles discutiram e trocaram experiências sobre os problemas e frustrações que haviam passado em suas empresas, ao tentar levar o mindset do movimento `Agile` para a área de operações e ao tentar unir os times de desenvolvimento e operações. Posteriormente eles criaram um grupo de discussões para compartilhar suas ideias com outras pessoas ao redor do mundo. 164 | 165 | Patrick Debois palestrou no evento com o tema **"Agile Infrastructure and Operations: how infra-gile are you?"**, sendo que sua palestra foi para contar sua experiência em utilizar os conceitos de Agile em três projetos dos quais ele participou. Os slides de sua palestra podem ser acessados em: http://www.jedi.be/presentations/agile-infrastructure-agile-2008.pdf 166 | 167 | ![Foto do slide de apresentação do Patrick Debois](imagens/capitulo-02/patrick-debois.png) 168 | 169 | No ano seguinte, em 2009, na O’Reilly Velocity Conference, John Allspaw e Paul Hammond, ambos do Flickr, deram uma palestra com o tema **["10+ Deploys per Day: Dev and Ops Cooperation at Flickr"](https://www.youtube.com/watch?v=LdOe18KhtT4)**, contando sobre suas experiências de trabalho no Flickr, onde eles conseguiram unir os times de desenvolvimento e operações, conseguindo com isso ter um ambiente onde eram realizados mais de 10 deploys ao dia, algo que naquela época era bem inovador e difícil de se ver no mercado. 170 | 171 | E assim começa a nascer e crescer o interesse das pessoas sobre o tema **Agile Infrastructure**, para então tentar resolver os conflitos entre os times de Dev e de Ops, gerando melhores resultados para suas empresas. 172 | 173 | Patrick Debois não pôde ir ao evento para prestigiar a palestra de John Allspaw e Paul Hammond, mas assistiu remotamente a transmissão e ficou muito empolgado e feliz em ver que diversas outras pessoas e empresas estavam interessadas pelo tema que ele se apaixonou um ano antes. 174 | 175 | ### DevOps Days 176 | 177 | Ainda em 2009, Patrick Debois decidiu criar um evento para reunir pessoas interessadas pelo assunto e que também quisessem compartilhar suas experiências. 178 | 179 | O evento foi batizado de **DevOps Days**, na qual sua primeira edição ocorreu na Bélgica, terra natal de Patrick Debois, e foi fortemente divulgado na internet via Twitter, sendo que para isso foi necessário a criação de uma `hashtag`. 180 | 181 | A ideia era utilizar o próprio nome do evento como hashtag, mas preferiu-se remover a palavra `days`, e com isso a hashtag utilizada foi: **DevOps**. 182 | 183 | E foi justamente assim que surgiu o termo DevOps, o qual Patrick Debois é considerado um dos pioneiros e que rapidamente se espalhou pelo mundo, sendo adotando por milhares de empresas. 184 | 185 | Perceba então que agora que entendemos a história, motivação e origem do DevOps, fica mais fácil de entender o que ele é, e o porquê dele ter sido criado. 186 | 187 | DevOps pode ser considerado também com uma **extensão** do Agile, para contemplar também a área de infraestrutura e deixa-la mais alinhada com a área de desenvolvimento, fazendo assim com que essas duas áreas trabalhem de maneira similar e com muita colaboração, para que assim consigam entregar mais resultados para a empresa como um todo. 188 | 189 | ## DevOps Anti-Patterns 190 | 191 | Assim como é importante conhecer os conceitos, motivações e boas práticas do DevOps, também é muito importante conhecer os mal-entendidos e anti-patterns sobre esse tema, para evitar cair em algumas armadilhas comuns de se ver no mercado, evitando com isso uma dificuldade ao adotar DevOps em uma empresa. 192 | 193 | ### DevOps é apenas para Dev e Ops 194 | 195 | Embora o termo DevOps seja uma abreviação de `Developers` e `Operations`, a ideia não é limitar a prática apenas a esses dois times. 196 | 197 | É importante que os outros times, como por exemplo QA, segurança e business, também sejam envolvidos e colaborem entre si, pois isso vai influenciar muito nos resultados. 198 | 199 | ### DevOps é um time separado 200 | 201 | Criar um time DevOps separado dos outros times pode ser um tiro no pé, pois se a empresa já tem dificuldades de transparência, comunicação e colaboração, um novo time DevOps separado apenas vai criar mais um silo e não necessariamente resolverá tais problemas de cultura dela. 202 | 203 | ### DevOps é um cargo 204 | 205 | DevOps é um movimento cultural, com objetivos de melhorar o ambiente de trabalho e os resultados produzidos em todo o processo de desenvolvimento e manutenção de softwares. 206 | 207 | Muitas vezes criar um cargo chamado `DevOps Engineer` cria a sensação de ser uma vaga para uma pessoa de desenvolvimento que também tenha conhecimentos em infra ou vice e versa. 208 | 209 | Tem muita empresa que faz isso para redução de custos, contratando um profissional que vale por dois, mas no geral elas fazem isso apenas para atrair novos talentos, que estejam interessados em trabalhar em ambientes que sigam a cultura DevOps. 210 | 211 | Há também o caso de muitos profissionais que fazem isso pois existem pesquisas que indicam maiores salários para cargos com esse nome. 212 | 213 | ### DevOps não serve para empresas grandes 214 | 215 | Embora em empresas grandes seja mais difícil aplicar mudanças culturais e promover mais agilidade, também é totalmente possível aplicar DevOps nesse tipo de ambiente, seguindo algumas dicas de como lidar com os possíveis problemas, barreiras e dificuldades que surgirão no caminho. 216 | 217 | ### DevOps é enxugar o time 218 | 219 | DevOps não significa ter menos pessoas, já que se tem a ideia de que um time DevOps é formado por profissionais `Full-Stack`, no qual cada pessoa tem todas as competências de Dev e de Ops. Isso pode levar a sobrecarga de trabalho e estresse, algo que certamente vai gerar mais erros e problemas que poderiam ser evitados. 220 | 221 | ### DevOps somente pode ser feito de um jeito 222 | 223 | Não existe a famosa **Bala de Prata** no DevOps. Cada empresa possui diferentes necessidades e problemas e cada implementação de DevOps provavelmente será diferente. Inclusive em relação a quais ferramentas e técnicas que os times vão adotar. 224 | 225 | ### DevOps é apenas sobre ferramentas e automatização 226 | 227 | DevOps não se resume a apenas utilizar ferramentas e tecnologias para automatizar um pipeline de build e deploy de aplicações. 228 | 229 | Ferramentas e automatização são muito importantes em um time DevOps, pois elas auxiliam muito na agilidade e produtividade, além de minimizar os erros humanos. 230 | 231 | Entretanto, de nada adianta adotar as melhores ferramentas do mercado, se o grande problema na empresa é cultural. 232 | 233 | ## A cultura em um ambiente DevOps 234 | 235 | Em um ambiente no qual as pessoas são culpadas e punidas por **erros** que acontecem, uma cultura de **medo** será criada e certamente causará a criação de **silos** entre as pessoas e seus times, algo que prejudicará muito a comunicação e transparência entre elas. 236 | 237 | Isso torna o ambiente de trabalho um local **hostil**, no qual as pessoas têm medo de arriscar, inovar e colaborar, por conta do risco de errarem e serem punidas. 238 | 239 | Nesse tipo de ambiente os erros humanos são considerados como **a causa de um problema**, criando-se assim uma cultura que busca a eliminação de erros humanos, os considerando como **incompetência**. 240 | 241 | Uma outra abordagem seria considerar os erros humanos como **o sintoma de um problema sistêmico**, que levou as pessoas a os cometerem. 242 | 243 | Nessa segunda abordagem os problemas não são atribuídos às pessoas, mas ao processo ou sistema de trabalho na qual elas estão inseridas, criando-se assim **oportunidades de aprendizado**, que favorecem a transparência e a colaboração. 244 | 245 | Essa segunda abordagem está totalmente alinhada aos princípios e valores do movimento DevOps, devendo sempre ser preferida pelas empresas que querem adotá-lo. 246 | 247 | O coração do DevOps consiste em criar uma cultura na qual as pessoas não trabalhem de maneira isolada, mas sim unidas, com transparência, colaboração e com metas claras e compartilhadas, bem como resolvendo juntas a causa raiz dos problemas que surgirem ao longo do caminho. 248 | 249 | Conforme mencionado anteriormente, não existe uma única maneira de fazer DevOps. Cada empresa tem diferentes necessidades, problemas, clientes, processos, ferramentas e pessoas, fazendo com que sua adoção ao DevOps também seja diferente. 250 | 251 | Porém, existem alguns tópicos relacionados à cultura que são comuns e recorrentes entre as empresas, nos quais podemos os basear em um pilar que pode ser utilizado para se começar uma adoção ao DevOps de maneira mais efetiva, que é a **colaboração**. 252 | 253 | Ao se basear nesse pilar será muito mais fácil de identificar os problemas de cultura de sua empresa, algo que certamente vai contribuir para as mudanças necessárias e para a adoção ao DevOps de uma maneira mais efetiva. 254 | 255 | ### Colaboração 256 | 257 | As pessoas passam boa parte dos seus dias no trabalho, portanto é muito importante e essencial que haja colaboração entre elas. 258 | 259 | Existem alguns aspectos que devem ser avaliados ao se planejar como abordar e melhorar o tema colaboração dentro de uma empresa. São eles: 260 | 261 | * Comunicação; 262 | * Transparência; 263 | * Autonomia; 264 | * Empatia; 265 | * Valores comuns; e 266 | * Mentoria. 267 | 268 | ### Comunicação 269 | 270 | Comunicação é a coisa mais importante para a colaboração de um time. Sem uma comunicação efetiva haverá desconfiança, retrabalho, desentendimentos e desunião entre as pessoas do time. 271 | 272 | Uma comunicação efetiva é capaz de ajudar um time a ter uma visão e entendimento compartilhado de seus objetivos, evitando que elas trabalhem de maneira isolada e competitiva. 273 | 274 | Incentivar a comunicação e o compartilhamento de informações dentro de um time, e também entre outros times e setores da empresa, ajuda a criar uma cultura de transparência e colaboração, favorecendo com isso o trabalho em time, e principalmente evitando a sobrecarga de trabalho e riscos ao deixar conhecimentos acumulado em poucas pessoas. 275 | 276 | Transparência é um ponto chave para a comunicação, pois sem ela as pessoas se sentirão excluídas, não mais sendo colaborativas, além disso favorecer a ocultação de problemas. 277 | 278 | Algumas práticas e técnicas para incentivar a comunicação incluem: 279 | 280 | * Pair Programming; 281 | * Code Reviews; 282 | * Programming Dojos; 283 | * Tech Talks; 284 | * Shared Coffee Breaks; e 285 | * Hack days. 286 | 287 | Algo que prejudica bastante a comunicação são as interrupções, principalmente durante reuniões. É necessário criar uma cultura onde as pessoas falem para serem entendidas e não apenas para influenciar. 288 | 289 | Interrupções atrapalham bastante no entendimento e quase sempre levam a discussões, distrações e conflitos. 290 | 291 | ### Transparência 292 | 293 | Sem transparência será difícil haver colaboração entre as pessoas, principalmente entre times distintos. As pessoas precisam saber o que está acontecendo a qualquer momento, independente da área, e isso certamente facilitará o entendimento e tomada de decisões. 294 | 295 | É muito importante criar uma cultura de transparência que favorece o compartilhamento e facilidade no acesso às informações da empresa, pois caso contrário teremos uma cultura onde as pessoas têm medo, desconfiança e preferem ocultar problemas e dificuldades, para não causar problemas e evitar riscos de punição. 296 | 297 | ### Autonomia 298 | 299 | Autonomia é outro conceito fundamental para se criar um ambiente mais colaborador e eficiente. As pessoas gostam de se sentir responsáveis pelas mudanças, melhorias e inovações, sendo que isso vai exigir a tomada de decisões. 300 | 301 | É muito ruim ter que pedir permissão o tempo inteiro para poder realizar parte do seu trabalho. Isso gera um certo desconforto, pois passa a impressão de falta de confiança, algo que pode desmotivar as pessoas. 302 | 303 | Além disso, não ter autonomia para tomar certas decisões pode atrapalhar no andamento de tarefas, algo que certamente prejudicará a agilidade na execução delas. 304 | 305 | ### Empatia 306 | 307 | Empatia é a capacidade de se colocar no lugar de outra pessoa, entendendo o porquê ela age de determinada maneira, levando em consideração seus problemas, dificuldades, dentre outras coisas. 308 | 309 | Saber ouvir e compreender o ponto de vista do outro, sem julgar e questionar, são maneiras de se praticar a empatia. 310 | 311 | Ao valorizar a empatia em um time DevOps, começamos a fazer com que a equipe de Ops entenda e aprecie a importância de ser capaz de colocar código novo em produção de maneira ágil e contínua, bem como a equipe de Dev a entender os problemas e impactos causados por códigos mal escritos, lentos e inseguros. 312 | 313 | Sendo assim, a empatia vai permitir que ambos os times de Dev e Ops colaborem e se ajudem a entregar e operar novas funcionalidades da melhor maneira possível, para satisfazer as necessidades de seus clientes e usuários. 314 | 315 | ### Valores Comuns 316 | 317 | Um time é a união entre diversas pessoas distintas com um ou mais objetivos em comum. Isso é bem diferente do modelo de equipes, onde cada equipe possui os seus objetivos individuais, algo que não favorece a colaboração. 318 | 319 | Sendo assim, é muito importante deixar claro para todas as pessoas do time quais são seus objetivos em comum e também os seus valores em comum. Isso vai deixar claro a todos do time o porquê de seus comportamentos e práticas serem de determinada maneira. 320 | 321 | Deixar claro os valores de um time também pode ajudar nos casos de conflitos de ideias. Por exemplo, imagine uma situação de conflito entre duas pessoas de um time, na qual uma pessoa quer entregar um código o quanto antes, mesmo sabendo que ele não tem uma boa qualidade, para conseguir cumprir com um determinado cronograma, enquanto a outra pessoa prefere correr o risco de atrasar, para manter um padrão mínimo de qualidade. 322 | 323 | Qual das duas pessoas tem a razão? 324 | 325 | As duas pessoas podem ter a razão, dependendo de seu time, sendo que isso vai depender dos valores dele. 326 | 327 | Se um time valoriza muito a qualidade, então a segunda pessoa estaria mais certa em correr o risco de não cumprir o prazo acordado, para favorecer a qualidade das entregas, algo que vai de encontro com os valores defendidos pelo seu time. 328 | 329 | Ter valores e objetivos compartilhados é uma excelente maneira de favorecer a colaboração entre as pessoas de um time, além de ajudar na resolução de conflitos de ideias entre elas. 330 | 331 | ### Mentoria 332 | 333 | Outra maneira de incentivar a colaboração entre as pessoas é por meio de programas de mentoria, com o objetivo de nivelar o conhecimento entre o time e melhorar a comunicação entre as pessoas. 334 | 335 | Pair programming, hackdays, treinamentos internos e externos e acompanhamento sênior/júnior são maneiras de promover um processo de mentoria. 336 | 337 | Isso certamente fará com que as pessoas colaborem mais entre si, além de melhorar os resultados obtidos pelo time e valorizar o potencial das pessoas. 338 | 339 | Outra vantagem é que as pessoas costumam a valorizar muito esse tipo de incentivo, do ponto de vista de carreira profissional, e tendem a permanecer mais tempo em empresas que investem nisso. 340 | 341 | ## CALMS 342 | 343 | Ao estudar sobre cultura relacionada ao movimento DevOps, é comum encontrar o termo CALMS, que é um acrônimo para: Culture, Automation, Lean, Measurement e Sharing. 344 | 345 | O termo foi criado por Damon Edwards e John Willis em 2010, após o primeiro evento Devopsdays que ocorreu nos Estados Unidos, sendo que inicialmente o acrônimo era apenas CAMS, mas posteriormente o L, de Lean, foi acrescentado por sugestão de Jez Humble. 346 | 347 | A ideia desse acrônimo é mostrar os cinco princípios mais importantes ao adotar o modelo DevOps em uma empresa, sendo que para os autores o coração do DevOps é sobre pessoas e gestão. 348 | 349 | ### Culture 350 | 351 | Cultura está relacionado ao tópico anterior, no qual foi discutido que o principal pilar sobre o tema é colaboração. 352 | 353 | Sem uma boa cultura, focada em colaboração, não adianta ter as melhores ferramentas e as melhores pessoas trabalhando em uma empresa, pois DevOps não nasceu para resolver problemas de ferramentas, mas sim problemas humanos. 354 | 355 | Outra dica em relação à cultura é formar times de projetos/produtos, com todas as pessoas necessárias fazendo parte dele, ao invés da clássica separação funcional, responsável por criar silos e desfavorecer a colaboração. 356 | 357 | ### Automation 358 | 359 | Automação consiste em identificar todas as tarefas repetitivas, que são chatas, cansativas e sujeitas a falhas humanas, e utilizar ferramentas para automatizá-las. 360 | 361 | Isso diminui as chances de erros e falhas humanas, diminui estresse ao executar tais tarefas, reduz o tempo para executá-las, acelera o feedback e aumenta a confiabilidade. 362 | 363 | Os principais pontos para se buscar automatização são: build, testes, deploy e provisionamento. 364 | 365 | ### Lean 366 | 367 | Utilize os conceitos de Lean a favor do time, para melhorar ainda mais a colaboração e melhoria de seus processos. 368 | 369 | Ideias do Lean que vão contribuir muito ao adotar e melhorar um ambiente DevOps: One Piece Flow, eliminação de desperdícios, System Thinking, Pull System, Kanban, Kaizen, experimentações, inspeção e adaptação. 370 | 371 | ### Measurement 372 | 373 | É difícil saber se melhorias estão acontecendo ou se problemas estão sendo gerados, se não tivermos dados para analisar. 374 | 375 | DevOps não encerra quando colocamos um produto ou feature em produção. É extremamente importante coletar métricas que vão ajudar o time a tomar as melhores decisões. 376 | 377 | Métricas não se resumem a apenas dados técnicos, como SLA e response time, mas também a dados de negócio, como número de novos clientes. 378 | 379 | ### Sharing 380 | 381 | Em um ambiente DevOps tanto as pessoas de Dev quanto as de Ops devem trabalhar juntas, compartilhando informações e metas, e pareando sempre que possível, para que ambos os lados entendem o trabalho e dificuldades de cada um. 382 | 383 | Isso facilita a criação de um ambiente mais colaborativo e a redução da superespecialização, onde cada um tem apenas uma responsabilidade e não se preocupa com o trabalho e problemas dos outros. 384 | 385 | Uma boa abordagem aqui é a ideia de que quem constrói um software também deveria ser responsável por buildar, deployar e monitorar o projeto. Uma famosa frase que remete a isso é a: **You build it, you run it**, citada em 2006 por Werner Vogels, que na época era CTO da Amazon. 386 | 387 | ## Mudanças culturais para adotar DevOps 388 | 389 | Ao adotar DevOps em uma empresa algumas mudanças vão começar a surgir e ser percebidas pelas pessoas. Dentre elas, as principais serão relacionadas ao comportamento das pessoas e a organização dos times. 390 | 391 | Algumas características que devem ser observadas nesse tipo de ambiente são: 392 | 393 | * Otimizações focadas em entrega de valor; 394 | * Visão sistêmica do pipeline de entrega de valor; 395 | * Definição de pronto focada no usuário; 396 | * Entregas contínuas e pequenas; 397 | * Loops de feedback; e 398 | * Automatização. 399 | 400 | ### Otimizações focadas em entrega de valor 401 | 402 | O foco de um time DevOps não é eficiência e produtividade. Ao invés de buscar por mais produtividade, mais tarefas sendo feitas ao mesmo tempo e mais entregas sendo realizadas, o foco muda para o entendimento do problema a ser resolvido, do ponto de vista de valor para os clientes e usuários, e como o time se organizará para solucioná-lo de maneira mais ágil e eficaz. 403 | 404 | ### Visão sistêmica do pipeline de entrega de valor 405 | 406 | Todo o time deve ter a visão do processo de trabalho de ponta a ponta, sabendo quais são as etapas e atividades que deverão ser seguidas para se entregar valor ao cliente. O foco deixa de ser **fazer a minha parte e passar o bastão para o próximo** e passa a ser **entender o fluxo de valor e pensar em como otimiza-lo de maneira colaborativa**. 407 | 408 | ### Definição de pronto focada no usuário 409 | 410 | De nada adianta um item estar pronto, do ponto de vista do desenvolvedor, se os usuários não podem ter acesso e dar feedback. 411 | 412 | Todas as pessoas do time devem ter a visão clara de que um item é considerado pronto apenas quando ele for entregue aos usuários. Isso favorece a colaboração entre os times de Dev, Ops, QA, etc. em entregar valor aos usuários de maneira mais ágil. 413 | 414 | ### Entregas contínuas e pequenas 415 | 416 | Para diminuir os riscos e aumentar o ciclo de feedback, é importante fazer entregas contínuas e que elas sejam pequenas. 417 | 418 | Isso também contribui para manter um ritmo sustentável de trabalho do time e também dos usuários. Além disso, valor é algo que costuma diminuir bastante com o tempo, sendo assim, de nada adianta fazer um entrega depois de 8 meses de trabalho. 419 | 420 | ### Loops de feedback 421 | 422 | Feedback é algo muito importante e valioso para um time DevOps e não deve se resumir a apenas o aceite ou rejeição dos usuários quanto à uma entrega. 423 | 424 | É importante que haja feedback entre os times de Dev e Ops durante todo o ciclo de entrega de valor, para que problemas e oportunidades sejam discutidas e tratadas de maneira colaborativa. 425 | 426 | ### Automatização 427 | 428 | Após cultura, automatização é a coisa mais importante em um ambiente DevOps. Sem automatização, um time terá muita dificuldade de entregar valor de maneira ágil, segura, efetiva e com baixo risco. 429 | 430 | Automatização acelera o processo de entrega de valor, aumenta a confiança no trabalho executado, diminui erros humanos em tarefas repetitivas e também contribui para a colaboração entre os times de Dev e Ops. 431 | 432 | ## The Three Ways 433 | 434 | No livro **The DevOps Handbook** os autores enfatizam que o modelo DevOps é composto por três princípios, chamados de **Three Ways**, que são fundamentais para a adoção efetiva do modelo. 435 | 436 | O primeiro princípio, chamado de **Principle of Flow**, foca em acelerar a entrega de trabalho que flui entre os times de Dev e Ops. 437 | 438 | O segundo princípio, chamado de **Principle of Feedback**, foca em melhorar o feedback entre os times de Ops e Dev, para criar um ambiente de trabalho mais seguro e colaborativo. 439 | 440 | O terceiro princípio, chamado de **Principle of Continuous Learning and Experimentation**, foca em criar uma cultura de confiança, resiliência e baseada em experimentações e adaptações contínuas. 441 | 442 | Recomendamos a utilização desses princípios ao adotar DevOps e promover as mudanças culturais em uma empresa. 443 | 444 | ## O papel das ferramentas em um ambiente DevOps 445 | 446 | Geralmente DevOps está associado com a utilização de dezenas de ferramentas, sendo que isso pode criar uma falsa ilusão de que para adotar DevOps basta apenas utilizar tais ferramentas. 447 | 448 | Já discutimos anteriormente que uma adoção ao DevOps deveria focar mais na parte de **pessoas** e **cultura**, para depois se preocupar com ferramentas e automatização de processos. 449 | 450 | Mas claro, ferramentas e automatização são tópicos também considerados importantes no universo DevOps, não devendo ser ignorados. 451 | 452 | Devemos ter a visão de que as ferramentas na verdade são **complementos à cultura** que vão aumentar a agilidade do time, pois estão alí para automatizar tarefas e processos repetitivos e sujeitos a erros humanos. 453 | 454 | Certamente isso vai ser de grande valia para o time, pois vai acelerar o ciclo de entrega de software e de recebimento de feedbacks. 455 | 456 | ### DevOps Toolchain 457 | 458 | ![Foto com exemplos de ferramentas](imagens/capitulo-02/tools.png) 459 | 460 | Ao pesquisar sobre DevOps na internet é comum encontrar imagens similares à figura anterior. 461 | 462 | A imagem é uma representação do símbolo do infinito contendo as várias etapas envolvidas no ciclo de vida da **construção** e **operação** de um software e listando algumas ferramentas que podem ser utilizadas em cada uma delas. 463 | 464 | Perceba que desenvolver um software e o colocar em produção não se resume a apenas as atividades de codificação e deploy. Um processo mais eficaz deve contemplar muito mais etapas que também são importantes. 465 | 466 | Sendo assim, é comum encontrar processos que contemplem ao menos as seguintes etapas: 467 | 468 | 1. Planejamento; 469 | 1. Codificação; 470 | 1. Build; 471 | 1. Testes; 472 | 1. Entrega; 473 | 1. Deploy; 474 | 1. Operação; e 475 | 1. Monitoramento. 476 | 477 | E dentro de cada uma dessas etapas existem inúmeras ferramentas que podem auxiliar o time DevOps a ser mais efetivo em seu trabalho de entregar software de valor aos seus clientes e usuários. 478 | 479 | Ao longo do curso veremos mais detalhes sobre essas etapas e aprenderemos a utilizar algumas dessas ferramentas. 480 | 481 | Reforçamos que não existe um única opção de ferramenta em cada etapa, sendo que você deve estudar e analisar as diversas opções existentes, para assim conseguir escolher as ferramentas que forem mais apropriadas para o seu time. 482 | -------------------------------------------------------------------------------- /03-lean.md: -------------------------------------------------------------------------------- 1 | # Lean 2 | 3 | Neste capítulo vamos aprender o que é Lean e qual a sua relação com a área de desenvolvimento de software. 4 | 5 | ## O que é Lean 6 | 7 | O **sistema Lean de Produção** foi desenvolvido pela Toyota e tem um princípio claro e simples: **reduzir o desperdício**. 8 | 9 | Em 2009, a Toyota vendeu mais carros nos Estados Unidos do que a nacional e tradicional Ford, tornando-se a segunda maior vendedora de carros naquele país. 10 | 11 | Mas como uma marca japonesa ultrapassou a gigante americana que popularizou o automóvel e revolucionou o sistema de produção de veículos com o conceito de linha de montagem? 12 | 13 | **Simplificando**. 14 | 15 | ## Exercício: Lean Lego Game 16 | 17 | Para entendermos melhor as idéias do Lean e as vantagens que elas trazem num sistema de produção, seja ele de automóveis ou de software, faremos um exercício prático que ilustra a redução de desperdícios por mudanças simples no processo e na cultura. 18 | 19 | Esse *workshop* foi criado em 2008 por Danilo Sato e Francisco Trindade, da Thoughtworks de Londres, como uma forma de ensinar e promover discussões sobre Lean de forma divertida. 20 | 21 | Ele já foi apresentado em diversas conferências pelo mundo e a página de referência sobre o jogo é: http://www.dtsato.com/blog/work/lean-lego-game 22 | 23 | O instrutor explicará o jogo em sala. 24 | 25 | ## Sobre Lean: o método Toyota 26 | 27 | Lean está intrinsecamente ligado à minimização dos desperdícios, sejam eles no processo, no desenvolvimento ou no produto final. 28 | 29 | Considere como desperdício tudo aquilo que não traz valor para o cliente e, como ganho, tudo o que agrega valor. O lucro é, então, uma conta trivial: `ganho - desperdício`. No contexto de produção de software, podemos ser mais objetivos no que são considerados desperdício e ganho. 30 | 31 | Desperdício é tudo o que não é feito para o cliente, seja a já discutida documentação excessiva, tempo de desenvolvimento parado por falta de informações (ou falta de clareza nelas), ou código e funcionalidades não-requisitadas. 32 | 33 | Ganho é tudo o que agrega valor e reduz retrabalho: funcionalidades novas, entregas frequentes para o cliente, código de qualidade, testes, etc. 34 | 35 | ### Desperdícios em desenvolvimento de software 36 | 37 | E o que é desperdício no desenvolvimento de software? 38 | 39 | Funcionalidades que são desenvolvidas pela metade e as que não estão completamente funcionais são exemplos de desperdício de desenvolvimento, ligados a quantidade de trabalho em andamento, ou seja, trabalho incompleto. 40 | 41 | Minimizar esse tipo de desperdício é fundamental para aumentar a eficácia e, consequentemente, o retorno em valor do software desenvolvido. 42 | 43 | Outros exemplos estão ligados com o planejamento e o trabalho do dia a dia, excessos que cometemos, como produzir uma funcionalidade ainda desnecessária, aguardar ordens etc. 44 | 45 | ### Os tipos de desperdício 46 | 47 | Lean divide os desperdícios em três categorias de igual importância: 48 | 49 | * **Mura:** desperdícios por tentar prever possíveis necessidades futuras. Evitar Mura significa reduzir ao máximo o inventário, isto é, as partes paradas no meio do processo, ou seja, trabalho começado e não terminado. 50 | 51 | * **Muri:** desperdícios que podem ser evitados por planejamento. Nessa categoria enquadra-se o excesso de burocracia ou de complexidade num processo de produção. 52 | 53 | * **Muda:** desperdícios do dia-a-dia, criados por uma cultura anterior de trabalho. Os sete Mudas geralmente destacados são: 54 | 55 | * Superprodução; 56 | * Transporte desnecessário; 57 | * Inventário; 58 | * Locomoção; 59 | * Defeitos; 60 | * Superprocessamento; e 61 | * Espera. 62 | 63 | Durante o *Lean Lego Game*, vimos como ações simples podem reduzir drasticamente os desperdícios supracitados. 64 | 65 | ## Push vs. Pull Systems 66 | 67 | No sistema Ford de produção, cada estação da linha de produção trabalha enquanto houver matéria-prima para tal. A quantidade do que será produzido é regulada com base nas previsões feitas sobre o mercado num determinado período e não há ligação entre os pedidos reais e a linha de produção. 68 | 69 | Naturalmente, uma estação de trabalho mais simples é mais eficiente em realizar sua tarefa. Contudo, assim, dois desperdícios são criados: 70 | 71 | * As muitas peças produzidas, esperando para serem usadas em outras estações, sem sequer saber se há demanda pelo produto. Chamamos essas peças de inventário; 72 | 73 | * O tempo livre dos trabalhadores superespecializados que trabalham nas funções terminadas mais cedo. 74 | 75 | Esses são exemplos de **Mura**. Uma solução possível para tais desperdícios é trabalhar com sistemas *pull* em vez dos tradicionais *push*, como o descrito. 76 | 77 | Sistemas *pull* trabalham com o mínimo possível de inventário que ainda permita atender às demandas de clientes rapidamente. Sua concepção e prática são simples: há apenas o número suficiente de peças em inventário para um produto (ou um lote) ser completo. 78 | 79 | Perceba que, em vez do planejamento pouco maleável baseado em previsões de mercado utilizado por sistemas *push*, em sistemas *pull* a produção acontece de acordo com a demanda, reduzindo custos de armazenamento de peças intermediárias e de produtos não vendidos, além de flexibilizar a produção. 80 | 81 | Quando de fato há demanda, a estação final consome as peças necessárias. A anterior, então, trabalha para repor o que foi consumido, e assim acontece sucessivamente, até a primeira estação. 82 | 83 | ## Kanban 84 | 85 | Se entendermos a linha de produção como uma sequência de passos para produzir algo, a representação óbvia para o processo é o **Kanban**, já consagrado em diversas teorias da área de Administração. 86 | 87 | Nele, os produtos por fazer ficam à esquerda e migram para a direita conforme os passos para sua construção vão sendo terminados. 88 | 89 | ![Exemplo de quadro Kanban](imagens/capitulo-03/kanban-base.png) 90 | 91 | Em sistemas *push*, cada estação de trabalho faz sua parte sem considerar as fases anteriores e posteriores. O Kanban abaixo permite ver com mais clareza o acúmulo de inventário: 92 | 93 | ![Quadro Kanban exemplificando o sistema Push](imagens/capitulo-03/kanban-push.png) 94 | 95 | Já no Kanban que representa o sistema *pull* de produção, há um limite de inventário claramente delimitado. Dessa forma, peças só são produzidas quando de fato há demanda e gasta-se menos em peças que não serão utilizadas ou em estoque de inventário. 96 | 97 | ![Quadro Kanban exemplificando o sistema Pull](imagens/capitulo-03/kanban-pull.png) 98 | 99 | O Kanban é uma excelente forma de visualizar o andamento da produção, mas é importante lembrar que ele é apenas uma ferramenta. E, como qualquer ferramenta, deve ser empregada para reforçar e auxiliar na aplicação da metodologia. 100 | 101 | ## Systems Thinking 102 | 103 | Voltando ao cenário proposto, após reduzir o Mura, pudemos ver mais claramente como nossa linha de produção funciona. E então foi possível notar que havia trabalhos redundantes. 104 | 105 | No caso do workshop, havia uma estação a mais do que o realmente necessário e não reparamos antes porque, focados na nossa tarefa, não nos preocupamos em sequer saber o que as outras estações faziam. Ou, pior, notamos a duplicação de trabalho, mas não sinalizamos essa deficiência. 106 | 107 | E quantas vezes não vimos consagrados processos de produção de software atrapalhando uma equipe em vez de ajudá-la? Todas as fases do seu processo são realmente necessárias para o sucesso final? 108 | 109 | Ainda que todas as fases sejam necessárias no começo de um projeto, frequentemente, em algum ponto, alguma delas deixa de ser necessária e outras, antes não pensadas, podem passar a ser úteis. 110 | 111 | É importante sempre pensar no processo, não simplesmente aceitá-lo. Um processo de produção de software, uma metodologia ou um framework. Todos eles foram planejados para auxiliar na produção - se estão fazendo o oposto, precisam ser mudados. 112 | 113 | Pensar sempre no sistema, *Systems Thinking*, é pensar e repensar durante todo o andamento do projeto no que poderia ser melhorado no próprio processo de desenvolvimento e nas interações entre as pessoas envolvidas. 114 | 115 | ## Work Cells 116 | 117 | Não é possível, no entanto, encontrar possíveis melhorias no processo se cada envolvido está focado exclusivamente em uma tarefa, na qual é especialista. 118 | 119 | Por isso, Lean entende que as pessoas envolvidas em um projeto não podem ser *superespecialistas*, isto é, não podem se limitar a conhecimentos apenas de sua etapa. Deveriam conhecer todas elas e saber executar pelo menos algumas delas. 120 | 121 | Cada membro da equipe é, dessa forma, uma *Work Cell*: uma pessoa capaz de trabalhar no projeto como um todo, em algumas ou todas as suas partes. E o conhecimento mais amplo sobre o projeto é incentivado, já que, quanto melhor alguém conhece o todo, melhor sabe criticá-lo - e, dessa forma, melhorá-lo. 122 | 123 | Também, se um trabalhador consegue chegar sozinho ao produto final, todo o custo com locomoção, tanto de pessoas quanto de máquinas ou peças, é extinto. Menos desperdício. 124 | 125 | Em uma planta industrial, a possibilidade de um só trabalhador fazer o produto por completo é muito mais difícil, portanto a *work cell* é formada por um grupo de pessoas, em vez de 126 | uma pessoa apenas. Já em desenvolvimento de software essa barreira é bem menor. 127 | 128 | Um arquiteto, um tester ou um desenvolvedor, seja ele júnior ou sênior, podem produzir código e deveriam entender essa atividade como algo de valor para o projeto, colaborando com o time. 129 | 130 | ## Kaizen 131 | 132 | Ainda na década de 1970, Frederich Brooks publicou um artigo chamado *No Silver Bullet*. Apesar de tanto tempo passado, o artigo não perde sua veracidade e é, juntamente com 133 | *The Mythical Man-Month*, leitura obrigatória para todos aqueles na área de Engenharia e Gerenciamento de Software. 134 | 135 | Em Lean, acredita-se que não exista, também para o processo, uma bala de prata capaz de resolver todos os problemas. Dessa forma, é preciso que cada equipe adapte a metodologia e ferramentas à sua necessidade, a todo momento. 136 | 137 | Finalmente, a última prática dessa breve introdução a Lean é o *Kaizen*, palavra japonesa para **melhoria**. E melhoria significa maximizar aquela função: `ganho - desperdício`. Melhorias no processo, na forma de produção e no produto final são parte do dia-a-dia de quem trabalha com Lean. 138 | 139 | O Kaizen é amplamente apoiado pelos conceito previamente vistos. Perceba: como cada *work cell* da equipe tem uma visão mais geral da produção e são incentivados a pensar no sistema (*system thinking*), conseguem enxergar melhorias mais facilmente. 140 | 141 | ## Lean e DevOps 142 | 143 | Lean pode ser considerado como um conjunto de princípios que emergiram nas fábricas da Toyota, como o objetivo de eliminar desperdícios e promover um ambiente de melhoria contínua. 144 | 145 | Percebe-se então sua relação direta com DevOps, pois no modelo DevOps há um foco muito grande em mudanças culturais para promover melhores resultados no processo de desenvolvimento e operação de softwares. 146 | 147 | Podemos utilizar todos os conceitos de Lean que vimos nesse capítulo no modelo DevOps: 148 | 149 | * **Pull Systems**: Para se obter um melhor fluxo de trabalho, evitando sobrecargas, demoras para entregar, estresses e erros. 150 | * **Work Cell**: Para evitar superespecializações, concentração de conhecimento e promover um ambiente de colaboração entre as pessoas. 151 | * **Systems Thinking**: Para que tanto o time de Dev quanto o de Ops conheçam todo o processo de trabalho como um todo e possam pensar em como torná-lo mais simples. 152 | * **Kaizen**: Para que todos possam pensar em melhorias no processo, ferramentas, ambiente ou quaisquer outras coisas que estejam atrapalhando a entrega de valor. 153 | -------------------------------------------------------------------------------- /04-projeto.md: -------------------------------------------------------------------------------- 1 | # O projeto do curso 2 | 3 | Neste capítulo vamos conhecer a aplicação que trabalharemos durante o curso e aprenderemos como fazer para executá-la localmente. 4 | 5 | ## Alura Fórum: o fórum da plataforma Alura 6 | 7 | A Alura é a plataforma de treinamentos de tecnologia do grupo Caelum, criada em 2011, focada em treinamentos na modalidade online. 8 | 9 | Sua missão é criar uma plataforma de aprendizado de tecnologia, na qual as pessoas possam discutir, participar e enriquecer seus conhecimentos. 10 | 11 | ![Site da plataforma Alura](imagens/capitulo-04/alura-home.png) 12 | 13 | Uma das funcionalidades da plataforma é o **fórum** de discussões, onde os alunos podem abrir tópicos para tirar dúvidas sobre os cursos ou trocar ideias sobre algum assunto em específico. 14 | 15 | Esse fórum de discussões será justamente a aplicação que utilizaremos de exemplo ao longo do curso. 16 | 17 | ![Fórum da plataforma Alura](imagens/capitulo-04/forum-dashboard.png) 18 | 19 | Obs: A aplicação que utilizaremos no curso é uma versão simplificada do fórum real da plataforma Alura, contendo apenas um subconjunto de suas funcionalidades. 20 | 21 | ## As funcionalidades da aplicação 22 | 23 | Vamos agora conhecer um pouco sobre as funcionalidades da aplicação do fórum da alura. 24 | 25 | ### Lista de tópicos 26 | 27 | Uma das funcionalidades do fórum é uma lista contendo todos os tópicos que foram cadastrados pelos alunos e ainda não foram fechados, ou seja, ainda podem ser visualizados e os alunos podem interagir com ele. 28 | 29 | ![Lista de tópicos](imagens/capitulo-04/forum-topicos.png) 30 | 31 | A lista possui algumas informações de cada tópico, como seu título, autor e número de respostas, além de também possuir alguns filtros e paginação dos resultados. 32 | 33 | Essa funcionalidade é pública, ou seja, não é necessário estar autenticado para poder acessá-la. 34 | 35 | ### Detalhes do tópico 36 | 37 | Ao clicar em algum tópico, somos redirecionados para uma outra página que mostra mais detalhes dele, além de mostrar também as respostas que ele teve, um formulário para o cadastro de novas respostas e alguns links para executar ações no tópico, como por exemplo fechá-lo ou marcar uma resposta como sendo a solução. 38 | 39 | ![Tela de detalhes de um tópico](imagens/capitulo-04/forum-topico-detalhe.png) 40 | 41 | ![Campo para cadastrar resposta em um tópico](imagens/capitulo-04/forum-topico-responder.png) 42 | 43 | Essa funcionalidade é parcialmente pública. Usuários não autenticados podem apenas visualizar as informações do tópico, mas não podem interagir com ele. 44 | 45 | Para cadastrar uma resposta é necessário estar autenticado na aplicação. 46 | 47 | Um outro detalhe importante é que somente o usuário que cadastrou o tópico, ou um usuário com perfil de *moderador*, tem permissão para fechá-lo ou para marcar uma resposta como sendo a solução. 48 | 49 | ### Login 50 | 51 | A aplicação também possui uma funcionalidade para que usuários previamente cadastrados possam se autenticar. 52 | 53 | ![Tela de login](imagens/capitulo-04/forum-login.png) 54 | 55 | ### Cadastro 56 | 57 | Qualquer pessoa pode se cadastrar livremente no fórum, para poder participar das discussões. 58 | 59 | ![Tela de cadastro](imagens/capitulo-04/forum-cadastro.png) 60 | 61 | Um detalhe aqui é que o email deve ser único no sistema, ou seja, um usuário não pode se cadastrar utilizando o email de outro usuário já cadastrado. 62 | 63 | ### Editar perfil 64 | 65 | A aplicação possui uma tela para editar o perfil do usuário, na qual ele poderá alterar seus dados pessoais, bem como alterar sua senha de acesso. 66 | 67 | ![Tela de editar perfil](imagens/capitulo-04/forum-perfil.png) 68 | 69 | ![Tela de redefinir senha](imagens/capitulo-04/forum-senha.png) 70 | 71 | Para acessar essa funcionalidade o usuário precisa estar autenticado na aplicação. 72 | 73 | ## Como rodar a aplicação? 74 | 75 | Agora que já conhecemos a aplicação que vamos trabalhar ao longo do curso, precisamos baixar seu código fonte para poder fazer o build e o deploy dela. 76 | 77 | ## Código fonte do projeto 78 | 79 | O primeiro passo será baixar o código fonte da aplicação e configurar o ambiente de desenvolvimento. 80 | 81 | A nossa aplicação foi desenvolvida em *Java* e seu código-fonte está hospedado no *GitLab*, podendo ser acessado pelo seguinte endereço: https://gitlab.com/aovs/projetos-cursos/do25-alura-forum 82 | 83 | Para baixá-la em nosso computador será necessário a utilização do *Git*. 84 | 85 | ## Exercício: download do código fonte da aplicação 86 | 87 | 1. Abra o `terminal` e rode o seguinte comando para baixar o código fonte da aplicação: 88 | 89 | ``` 90 | git clone https://gitlab.com/aovs/projetos-cursos/do25-alura-forum 91 | ``` 92 | 93 | 2. Acesse o diretório `home` e verifique se uma pasta chamada `do25-alura-forum` foi criada e dentro dela se encontram os arquivos da aplicação. 94 | 95 | ## Build do projeto 96 | 97 | Após baixar o projeto precisamos configurá-lo para então conseguir realizar o build dele. 98 | 99 | A configuração deve ser feita importando o projeto em uma `IDE Java`, que nosso caso será o *Eclipse*, e realizando nela também a configuração do servidor de aplicações `Tomcat`. 100 | 101 | Feito isso, já será possível realizar o build da aplicação para termos um pacote que poderá ser colocado em produção. Entretanto, existem algumas etapas que devemos seguir para conseguir realizar o build de maneira correta. 102 | 103 | Para facilitar esse processo a equipe de desenvolvimento criou um documento explicando o passo a passo necessário para realizar o build da aplicação, chamado de **Manual do Build**, ao qual devemos seguir, evitando assim possíveis problemas. 104 | 105 | ## Exercício: build manual da aplicação 106 | 107 | 1. Acesse o diretório do curso e abra o documento **manual-build.pdf**. 108 | 109 | 1. Siga as instruções desse manual para realizar o build da aplicação. 110 | 111 | 1. Em caso de dúvidas ou dificuldades peça ajuda ao instrutor. 112 | 113 | ## Deploy do projeto 114 | 115 | Após realizar o build da aplicação agora devemos realizar o deploy dela, sendo que para isso devemos configurar toda a infra estrutura necessária. 116 | 117 | Como esse processo é um pouco complicado e sujeito a erros, a equipe de Ops também criou um documento com as instruções para realizar tal atividade, o qual é chamado de **Manual do Deploy**. 118 | 119 | Devemos seguir esse manual para conseguir simular um ambiente de produção, utilizando máquinas virtuais, com todas as configurações de infra estrutura necessárias para que a aplicação possa ser executada normalmente. 120 | 121 | ## Exercício: deploy manual da aplicação 122 | 123 | 1. Acesse o diretório do curso e abra o documento **manual-deploy.pdf**. 124 | 125 | 1. Siga as instruções desse manual para realizar o deploy da aplicação. 126 | 127 | 1. Em caso de dúvidas ou dificuldades peça ajuda ao instrutor. 128 | -------------------------------------------------------------------------------- /05-build.md: -------------------------------------------------------------------------------- 1 | # Build automatizado 2 | 3 | Neste capítulo vamos discutir sobre a importância da automatização do build em uma aplicação, além de aprender a como automatizar o build da aplicação utilizada como exemplo no curso. 4 | 5 | ## Build 6 | 7 | Para desenvolver uma aplicação a equipe de desenvolvimento precisa escrever o código fonte dela, que vai conter as lógicas de negócio específicas da aplicação, além do código de infra estrutura necessário para suportá-la. 8 | 9 | Mas uma aplicação não é feita apenas do código fonte escrito em alguma linguagem de programação, como Java, PHP ou Ruby, mas também de outros arquivos utilitários. 10 | 11 | Em uma aplicação Web, por exemplo, também são necessárias as páginas HTML, arquivos de estilos CSS, arquivos JavaScript, imagens, dentre outros. 12 | 13 | E além disso, também é comum que a equipe de desenvolvimento utilize bibliotecas e frameworks para facilitar o desenvolvimento da aplicação, juntamente com arquivos de configurações. 14 | 15 | Mas quando a aplicação estiver pronta para ir à produção será necessário **transformar** todos esses milhares de arquivos em uma espécie de *pacote*, que será o arquivo *binário* a ser instalado e executado no servidor da aplicação. 16 | 17 | Esse processo de converter todo o código fonte da aplicação no pacote a ser instalado no servidor é chamado de **build**, sendo que ele pode variar de aplicação para aplicação e também de acordo com a linguagem de programação e bibliotecas utilizadas. 18 | 19 | Perceba então que esse processo de realizar o build da aplicação é algo que o time de desenvolvimento precisa realizar com bastante frequência, principalmente em ambientes alinhados com a cultura ágil e DevOps, que exigem ciclos de entregas mais curtos. 20 | 21 | Isso faz com que o processo de build de uma aplicação seja considerado como algo *crítico*, devendo o time de desenvolvimento buscar maneiras de minimizar os erros que podem acontecer nele. 22 | 23 | ## Os problemas do build manual 24 | 25 | É muito comum encontrar aplicações cujo processo de build é realizado de maneira manual, ou seja, com alguma pessoa do time de desenvolvimento seguindo um *passo a passo* de tarefas que precisam ser realizadas para gerar o artefato final do build. 26 | 27 | Isso foi exatamente o que fizemos no capítulo anterior, ao gerar o build da aplicação do fórum da Alura, o qual inclusive utilizamos o documento chamado **manual do build**, detalhando o passo a passo para realizar o build da aplicação. 28 | 29 | O problema dessa abordagem é que ela gera um risco elevado de erros acontecerem, uma vez que o processo de build de uma aplicação pode ser algo complexo e que envolva dezenas de passos a serem seguidos. 30 | 31 | Caso uma pessoa do time esqueça de realizar algum dos passos ou o realize de maneira incorreta, teremos um artefato final incompleto ou com erros que podem prejudicar as pessoas que utilizam a aplicação. 32 | 33 | Um exemplo clássico de erro comum que pode acontecer ao se ter um processo manual de build, é o de fazer o deploy da aplicação em ambiente de **produção**, mas com as configurações de banco de dados do ambiente de **desenvolvimento**. 34 | 35 | Você já passou por isso antes ou conhece alguém que tenha passado? Quais os impactos negativos que isso pode gerar para o time de desenvolvimento, para a área de tecnologia e até mesmo para a própria empresa? 36 | 37 | ## Automatização do processo de build 38 | 39 | Perceba que existe um grande risco de problemas acontecerem ao se realizar o build da aplicação de maneira manual. O ideal é buscar por maneiras de automatizar tal processo. 40 | 41 | O processo de build de uma aplicação nada mais é do que uma sequência de passos a serem executados de maneira sequencial, para produzir o artefato final, sendo que normalmente essa sequência de passos é sempre executada da mesma maneira. 42 | 43 | Tais passos podem incluir atividades como: 44 | 45 | * Compilar o código fonte; 46 | * Executar testes automatizados; 47 | * Criar, copiar, mover, renomear ou remover arquivos e/ou diretórios; 48 | * Executar scripts; 49 | * Gerar o pacote final da aplicação; 50 | * Etc. 51 | 52 | Por conta dessa característica repetitiva, na qual os passos são sempre executados da mesma maneira, temos a possibilidade então de automatizar esse processo. 53 | 54 | Em um ambiente DevOps a automatização do processo de build se torna algo de grande valor para o time, pois além de eliminar as chances de erros humanos, também vai gerar mais **agilidade**, pois uma máquina é infinitamente mais rápida do que qualquer pessoa. 55 | 56 | ## Build tools 57 | 58 | Existem diversas ferramentas para automatização de build, chamadas de **Build Tools**, que podemos utilizar em nossas aplicações. Elas podem variar de acordo com a linguagem de programação e bibliotecas utilizadas pela aplicação. 59 | 60 | Algumas delas são: 61 | 62 | * Maven(Java) 63 | * Webpack(JavaScript) 64 | * Rake(Ruby) 65 | * PyBuilder(Python) 66 | * MSBuild(.NET) 67 | 68 | Geralmente as ferramentas de build são configuráveis, permitindo que o time de desenvolvimento possa customizar o processo de build de cada aplicação, podendo cada uma delas ter o processo totalmente distinto das outras. 69 | 70 | Hoje em dia é praticamente obrigatória a utilização de alguma ferramenta de build, sendo raro encontrar alguma aplicação que não utilize tal solução. 71 | 72 | Caso sua aplicação não utilize uma ferramenta de build, o recomendado é escolher alguma delas e começar a utilizá-la o quanto antes. 73 | 74 | ## Automatizando o build do fórum da Alura 75 | 76 | A aplicação utilizada como exemplo no curso, o fórum da Alura, não está utilizando nenhuma ferramenta de build, forçando assim que o processo de build seja executado de maneira manual. 77 | 78 | Nosso trabalho agora é adicionar nela alguma das ferramentas de build e então configurar o processo de build dela, conforme fizemos de maneira manual, seguindo o manual do build. 79 | 80 | Como se trata de uma aplicação Java, utilizaremos o Maven como ferramenta de build, que é uma das opções mais comuns e populares no Java. 81 | 82 | ### Maven 83 | 84 | Maven é uma ferramenta utilizada para automatizar o processo de build de uma aplicação Java, além de conter outras funcionalidades, como o gerenciamento das dependências. 85 | 86 | As configurações do Maven na aplicação são feitas em um arquivo no formato `XML`, chamado `pom.xml`, que deve ser criado no diretório raiz da aplicação. 87 | 88 | Nesse arquivo devemos configurar as informações sobre a aplicação, o tipo de empacotamento dela, as dependências dela, dentre outras inúmeras possíveis configurações. 89 | 90 | Veja a seguir um exemplo do arquivo `pom.xml`: 91 | 92 | ```xml 93 | 96 | 97 | 4.0.0 98 | br.com.caelum 99 | alura-forum 100 | 1.0 101 | war 102 | 103 | 104 | UTF-8 105 | UTF-8 106 | 1.8 107 | 108 | 109 | 110 | 111 | org.springframework 112 | spring-webmvc 113 | 4.3.0.RELEASE 114 | 115 | 116 | 117 | org.hibernate.javax.persistence 118 | hibernate-jpa-2.1-api 119 | 1.0.0.Final 120 | 121 | 122 | 123 | mysql 124 | mysql-connector-java 125 | 5.1.15 126 | 127 | 128 | 129 | ``` 130 | 131 | Para mais informações sobre o Maven e seu funcionamento, acesse o seu site em: https://maven.apache.org 132 | 133 | ## Exercício: Adicionando o Maven ao projeto 134 | 135 | Nesse exercício vamos adicionar e configurar o Maven em nossa aplicação. 136 | 137 | 1. O primeiro passo será converter o projeto para o `Maven`, sendo que isso pode ser feito diretamente no Eclipse, clicando com o botão direito no projeto e selecionando a opção: `Configure -> Convert to Maven Project`. 138 | 139 | ![Opção Convert to Maven Project no Eclipse](imagens/capitulo-05/convert-maven-project.png) 140 | 141 | 2. Na tela que será exibida devemos preencher algumas informações para o Maven, conforme a imagem a seguir: 142 | 143 | ![Informações do projeto para o Maven](imagens/capitulo-05/maven-info.png) 144 | 145 | 3. O próximo passo é configurar as dependências do projeto no arquivo `pom.xml`. Já deixamos o arquivo preenchido no diretório do curso, portanto apenas substitua o arquivo atual pelo arquivo disponibilizado. 146 | 147 | 4. Por fim, devemos apagar **todos** os arquivos `.jar` do diretório `WebContent/WEB-INF/lib`. 148 | 149 | 5. Pronto! O projeto agora já foi convertido para o Maven e deveria estar funcionando normalmente. Caso algum erro esteja aparecendo no projeto no Eclipse, peça auxilio ao instrutor. 150 | 151 | ## Exercício: Isolando os datasources com profiles 152 | 153 | Nesse exercício vamos adicionar na aplicação o conceito de **Profiles**, para isolar as configurações dos bancos de dados de desenvolvimento e produção, evitando assim que isso tenha que ser feito manualmente no build. 154 | 155 | 1. No pacote **br.com.alura.forum.config** crie uma classe chamada **DataSourceConfiguration**: 156 | 157 | ```java 158 | @Configuration 159 | public class DataSourceConfiguration { 160 | 161 | } 162 | ``` 163 | 164 | 2. Abra a classe **JPAConfiguration** procure pelos dois métodos chamados **datasource** e mova-os para a classe **DataSourceConfiguration**. Você pode remover os comentários do código e renomear os métodos conforme o exemplo a seguir: 165 | 166 | ```java 167 | @Configuration 168 | public class DataSourceConfiguration { 169 | 170 | @Bean 171 | public DataSource desenvolvimento() { 172 | DriverManagerDataSource dataSource = new DriverManagerDataSource(); 173 | dataSource.setDriverClassName("com.mysql.jdbc.Driver"); 174 | dataSource.setUrl("jdbc:mysql://localhost:3306/alura_forum?useSSL=false"); 175 | dataSource.setUsername("root"); 176 | dataSource.setPassword(""); 177 | return dataSource; 178 | } 179 | 180 | @Bean 181 | public DataSource producao() { 182 | DriverManagerDataSource dataSource = new DriverManagerDataSource(); 183 | dataSource.setDriverClassName("com.mysql.jdbc.Driver"); 184 | dataSource.setUrl("jdbc:mysql://192.168.56.110:3306/alura_forum?useSSL=false"); 185 | dataSource.setUsername("alura"); 186 | dataSource.setPassword("qwerty123"); 187 | return dataSource; 188 | } 189 | 190 | } 191 | ``` 192 | 193 | 3. A classe **JPAConfiguration** estará com um erro de compilação. Para resolve-lo você fazer o seguinte ajuste: 194 | 195 | ```java 196 | @EnableTransactionManagement 197 | public class JPAConfiguration { 198 | 199 | @Autowired 200 | private DataSource dataSource; 201 | 202 | @Bean 203 | public LocalContainerEntityManagerFactoryBean entityManagerFactory() { 204 | LocalContainerEntityManagerFactoryBean em = new LocalContainerEntityManagerFactoryBean(); 205 | em.setDataSource(dataSource); 206 | em.setPackagesToScan(new String[] { "br.com.alura.forum.model" }); 207 | 208 | JpaVendorAdapter vendorAdapter = new HibernateJpaVendorAdapter(); 209 | em.setJpaVendorAdapter(vendorAdapter); 210 | em.setJpaProperties(additionalProperties()); 211 | 212 | return em; 213 | } 214 | 215 | //resto do código continua igual... 216 | } 217 | ``` 218 | 219 | 4. Por fim, na classe **DataSourceConfiguration** precisamos adicionar no método **producao** a anotação `@Profile("producao")` e no método **desenvolvimento** a anotação `@Profile("desenvolvimento")`, ficando o código da seguinte maneira: 220 | 221 | ```java 222 | @Bean 223 | @Profile("desenvolvimento") 224 | public DataSource desenvolvimento() { 225 | DriverManagerDataSource dataSource = new DriverManagerDataSource(); 226 | dataSource.setDriverClassName("com.mysql.jdbc.Driver"); 227 | dataSource.setUrl("jdbc:mysql://localhost:3306/alura_forum?useSSL=false"); 228 | dataSource.setUsername("root"); 229 | dataSource.setPassword(""); 230 | return dataSource; 231 | } 232 | 233 | @Bean 234 | @Profile("producao") 235 | public DataSource producao() { 236 | DriverManagerDataSource dataSource = new DriverManagerDataSource(); 237 | dataSource.setDriverClassName("com.mysql.jdbc.Driver"); 238 | dataSource.setUrl("jdbc:mysql://192.168.56.110:3306/alura_forum?useSSL=false"); 239 | dataSource.setUsername("alura"); 240 | dataSource.setPassword("qwerty123"); 241 | return dataSource; 242 | } 243 | ``` 244 | 245 | 5. Pronto! Ao rodar localmente a aplicação, o datasource carregado será o de desenvolvimento. Para que a aplicação carregue o `datasource` de produção será necessário adicionar a seguinte variável de ambiente no servidor: `spring.profiles.active=producao`. 246 | 247 | ## Realizando o build automatizado com Maven 248 | 249 | Agora que já configuramos o Maven em nosso projeto podemos realizar o build de maneira automatizada, evitando assim erros e desperdício de tempo com essa tarefa repetitiva e rotineira. 250 | 251 | O build pode ser realizado de dentro da própria IDE Eclipse, clicando com o botão direito em cima do projeto e navegando na opção: `Run As -> Maven install`. 252 | 253 | ![Opção para build do projeto no Eclipse](imagens/capitulo-05/maven-build-eclipse.png) 254 | 255 | Ao selecionar essa opção o Maven vai iniciar o processo de build, que deve levar alguns segundos para finalizar, e durante esse processo o Maven gera alguns logs sobre o seu andamento diretamente no `console` do Eclipse. 256 | 257 | Ao final do processo é esperado que a mensagem **BUILD SUCCESS** seja exibida no console, conforme demonstrado na seguinte figura: 258 | 259 | ![Log de build realizado com sucesso no console Eclipse](imagens/capitulo-05/maven-build-eclipse-sucesso.png) 260 | 261 | ### Artefatos do build 262 | 263 | Durante o processo de build o Maven gera os artefatos, por padrão, no diretório chamado **target**, que fica localizado no diretório raiz da aplicação: 264 | 265 | ![Diretório target com os artefatos gerados pelo Maven](imagens/capitulo-05/maven-build-artefatos.png) 266 | 267 | Repare que diversos arquivos e diretórios foram criados, mas no nosso caso o que interessa é o arquivo **.war**, pois ele representa o artefato utilizado para deploy da aplicação em produção. No nosso caso então, será o arquivo gerado pelo Maven com o nome **alura-forum-0.0.1-SNAPSHOT.war**. 268 | 269 | ### Build por linha de comando 270 | 271 | Não é obrigatório utilizar o Eclipse para gerar o build automatizado do projeto com o Maven. Isso é apenas um jeito mais cômodo para alguém do time de desenvolvimento que esteja utilizando o Eclipse e precise gerar o build do projeto. 272 | 273 | Uma outra maneira de gerar o build é pelo `terminal`, caso o Maven esteja instalado no computador. Para isso, basta acessar o diretório do projeto e rodar o seguinte comando: 274 | 275 | ``` 276 | mvn clean install 277 | ``` 278 | 279 | O build será realizado da mesma maneira e os artefatos ficarão disponíveis no mesmo diretório `target` do projeto. 280 | 281 | > **Clean ?** 282 | > 283 | > Ao executar o Maven no exemplo mostrado anteriormente foi adicionado o parâmetro `clean`, que serve para **limpar** o build anterior, ou seja, apagar todos os artefatos que foram gerados no último build. 284 | > 285 | > O Maven possui diversos outros parâmetros, além do `clean` e `install`, como por exemplo o `test`, que serve para executar os testes automatizados do projeto. 286 | > 287 | > Para saber mais detalhes, acesse a documentação em: https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html 288 | 289 | 290 | ## Exercício: Gerando o build automatizado do projeto 291 | 292 | Nesse exercício vamos gerar o build da aplicação de maneira automatizada, utilizando o Maven. 293 | 294 | 1. Abra o terminal e acesse o diretório do projeto. 295 | 296 | 2. Rode o comando `mvn install` para gerar o build do projeto. 297 | 298 | 3. Acesse o diretório do projeto e verifique se na pasta `target` os artefatos foram gerados normalmente. 299 | 300 | 4. É preciso fazer mais alguma coisa manualmente ao realizar o build do projeto? Discuta com o instrutor e demais alunos da turma. 301 | -------------------------------------------------------------------------------- /06-controle-versao.md: -------------------------------------------------------------------------------- 1 | # Controle de Versão 2 | 3 | Neste capítulo vamos aprender a utilizar o Git como ferramenta de controle de versão, além de entender o porquê de ser muito importante utilizar esse tipo de ferramenta, tanto pelo time de Dev quanto pelo time de Ops. 4 | 5 | ## Backup e colaboração 6 | 7 | Você provavelmente deve possuir diversos arquivos em seu computador pessoal. Sejam fotos, vídeos, planilhas, documentos do trabalho, da faculdade e/ou pessoais. 8 | 9 | E se algo *trágico* acontecesse com o seu computador, como ele queimar, der problema no HD ou até mesmo ser furtado? Além do prejuízo financeiro, você perderia todos os seus arquivos, algo que seria muito trágico e traumático. 10 | 11 | Por conta desse risco, quase todas as pessoas, inclusive pessoas que não trabalham diretamente na área de tecnologia, já possuem o hábito de realizar **cópias** de seus arquivos, em especial os arquivos que são considerados como sendo muito importantes. 12 | 13 | Seja utilizando algum serviço Web, como Dropbox ou Google Drive, ou utilizando algum dispositivo físico, como pendrive ou HD externo, as pessoas já desenvolveram há um bom tempo o hábito de realizar **backups** com frequência, pois nunca se sabe quando algo de ruim poderá acontecer com nossos arquivos. 14 | 15 | Ao trabalhar no desenvolvimento de uma aplicação temos a mesma situação, pois diversos arquivos serão criados, modificados e excluídos ao longo do tempo, e não queremos correr o risco de perder todo o trabalho já realizado até então. 16 | 17 | Devemos então ter o mesmo hábito de realizar backups do código fonte da aplicação. Mas a pergunta é: onde guardar e como realizar tais backups? 18 | 19 | Além disso, é raro trabalharmos de maneira isolada durante o projeto. Geralmente trabalhamos simultaneamente com outras pessoas, que juntas formam um time, e com isso surge mais um problema: como fazer para *sincronizar* o trabalho de todo mundo sem que uma pessoa sobrescreva o trabalho da outra, visto que cada pessoa vai trabalhar em seu próprio computador? 20 | 21 | Por fim, há ainda mais um problema: seria interessante não apenas ter um backup do código fonte, mas também ter registrado todo o **histórico** de evolução dele, pois dificilmente as pessoas vão conseguir se lembrar de todas as modificações que nele foram feitas ao longo do tempo. 22 | 23 | ## Sistemas de Controle de Versão 24 | 25 | Para resolver esses problemas e facilitar a vida de quem trabalha com desenvolvimento de software, diversas ferramentas foram criadas ao longo do tempo. 26 | 27 | Esse tipo de ferramenta é conhecido como **VCS(Version Control Systems)** ou também como **SCM(Source Code Management)**, sendo hoje considerado como **obrigatório** para qualquer tipo de projeto de software. 28 | 29 | Sistemas de controle de versão são ferramentas que ajudam um time de desenvolvimento a **gerenciar as alterações** feitas no código fonte do projeto **ao longo do tempo**. 30 | 31 | Isso pode ser muito útil para alguém do time que queira entender melhor a **evolução** de certo trecho de código do projeto, além de também facilitar e agilizar nos casos de ser necessário **reverter** um trecho de código para uma das versões anteriores. 32 | 33 | Outro benefício de se utilizar esse tipo de ferramenta é a **rastreabilidade**, pois em cada alteração registrada nela também são armazenados metadados sobre quando a alteração foi feita, quais modificações foram realizadas e quem foi a pessoa que as realizou. 34 | 35 | Além disso, esse tipo de ferramenta favorece bastante a **colaboração**, pois permite que diversas pessoas trabalhem ao mesmo tempo na mesma base de código, colaborando entre si para o desenvolvimento do projeto. 36 | 37 | Eventualmente pode haver conflitos no código fonte, no caso de duas ou mais pessoas alterarem o mesmo arquivo em um mesmo momento, mas as ferramentas de controle de versão costumam auxiliar na resolução deles, por meio de seus recursos. 38 | 39 | Sendo assim, percebe-se então a grande importância de se utilizar uma ferramenta de controle de versão pelo time de desenvolvimento, sendo essa considerada uma ferramenta muito importante e valiosa, pois o time a utilizará diariamente ao longo do desenvolvimento do projeto. 40 | 41 | ### Ferramentas de controle de versão 42 | 43 | Dentre as principais ferramentas de controle de versão estão: 44 | 45 | * CVS 46 | * Subversion(SVN) 47 | * SourceSafe 48 | * Git 49 | * Mercurial 50 | 51 | Cada uma delas tem suas vantagens e desvantagens, sendo que todas elas cumprem com seu objetivo principal, que é manter o histórico de modificações nos arquivos de um projeto. 52 | 53 | Até meados de 2008 o SVN era uma das mais populares e utilizadas dentre elas, mas foi perdendo cada vez mais mercado para o Git, cuja popularidade aumentava cada vez mais ao redor do mundo, tendo atualmente o domínio do mercado. 54 | 55 | ## Git 56 | 57 | O Git foi criado em 2005 por *Linus Torvalds*, o mesmo criador do kernel do *Linux*, e hoje é a ferramenta de controle de versão mais popular, utilizada e recomendada ao redor do mundo. 58 | 59 | Dentre as principais vantagens do Git estão: 60 | 61 | * Gratuito e open source 62 | * Distribuído 63 | * Alta performance 64 | * Extensível 65 | * Suporte a diferentes tipos de workflow 66 | 67 | Essas vantagens foram atraindo muitos desenvolvedores ao redor do mundo, que começaram a o utilizar como principal ferramenta para controle de versão, aumentando com isso sua popularidade. 68 | 69 | Depois de um tempo muitas ferramentas e serviços baseados no Git foram criadas, para facilitar ainda mais a vida das pessoas que trabalham com desenvolvimento de software, criando-se com isso uma enorme comunidade e apoio ao projeto. 70 | 71 | Um exemplo disso é o **GitHub**, que é um site que funciona como serviço para hospedagem de código fonte de projetos que utilizam o Git como controle de versão. 72 | 73 | O GitHub provavelmente foi a ferramenta que mais disseminou o uso do Git ao redor do mundo, além de também incentivar e apoiar fortemente os projetos de software open source, oferencendo planos gratuitos para esse tipo de projeto. 74 | 75 | Isso fez com que muitos projetos open source fossem migrados de outras plataformas, como *Google Code* e *SourceForge*, para o GitHub, aumentando assim tanto a sua popularidade, como também a do Git. 76 | 77 | ## Utilizando o Git 78 | 79 | Para utilizar o Git é preciso baixá-lo e fazer sua instalação. Existem versões para Windows, Linux e Mac, que podem ser baixadas diretamente de seu site: https://git-scm.com/downloads 80 | 81 | ![Página de Download no site do Git](imagens/capitulo-06/download-git.png) 82 | 83 | Existem duas principais maneiras de se utilizar o Git: via linha de comandos e via interface gráfica. 84 | 85 | Existem aplicações gráficas para se trabalhar com o Git, como por exemplo: *gitk*, *git-gui* e *GitHub for macOS and Windows*, além das próprias IDEs já possuirem *plugins* que as integram diretamente com o Git, evitando a necessidade de se utilizar ferramentas externas. 86 | 87 | Mas ao longo do curso vamos trabalhar com o Git via linha de comandos, utilizando o *Terminal*, para não ficar dependente de uma ferramenta ou plugin em específico, e também para entender melhor como funcionam os comandos do Git. 88 | 89 | ### Criando um novo repositório 90 | 91 | No Git existe um termo importante chamado **repositório**, que nada mais é do que o diretório raiz da aplicação, no qual o time de desenvolvimento vai criar o código fonte dela. A ideia é que cada aplicação tenha o seu próprio repositório separado, para que o código de uma não atrapalhe no das outras. 92 | 93 | Para criar um novo repositório no Git basta acessar o diretório raiz da aplicação e rodar o seguinte comando: 94 | 95 | ``` 96 | git init 97 | ``` 98 | 99 | Ao rodar o comando anterior o Git criará um diretório oculto chamado `.git`, o qual contém todas as informações sobre o repositório para o Git. Esse diretório será utilizado pelo Git para armazenar o histórico de alterações dos arquivos, dentre outras informações, não devendo ser modificado pelo time de desenvolvimento. É justamente por isso que ele é um diretório oculto :) 100 | 101 | Agora o time de desenvolvimento já pode criar os arquivos que farão parte do código fonte da aplicação. 102 | 103 | ### Configurando o usuário para o Git 104 | 105 | Antes de registrar as alterações no repositório precisamos nos *identificar* para o Git, pois o Git precisa guardar quem foi a pessoa que registrou cada alteração. 106 | 107 | Isso deve ser feito utilizando os seguintes dois comandos: 108 | 109 | ``` 110 | git config --global user.name 'seu nome' 111 | git config --global user.email 'seu email' 112 | ``` 113 | 114 | Agora todas as alterações registradas nesse repositório, feitas a partir desse computador, estarão vinculadas à pessoa com o *nome* e *email* indicados no comando anterior. 115 | 116 | O parâmetro `--global` indica ao Git que esse mesmo nome e email deve ser utilizado em todos os novos repositórios Git que forem criados ou baixados a partir desse computador, para que assim você não precise ficar repetindo o comando anterior a cada novo repositório que for trabalhar. 117 | 118 | ### Registrando alterações com commits 119 | 120 | Outro termo importante e recorrente no Git é o **commit**, que nada mais é do que a representação de um registro de alteração efetuada por alguém em um determinado momento no repositório. 121 | 122 | Sempre que uma pessoa do time de desenvolvimento desejar registrar no histórico do repositório alguma alteração, ela precisará fazer um commit. 123 | 124 | Ao realizar um commit no repositório, o Git deixará registrado quem o efetuou, quando ele foi feito e, principalmente, quais arquivos foram modificados. 125 | 126 | Para efetuar um commit, o seguinte comando deve ser utilizado: 127 | 128 | ``` 129 | git commit -m 'mensagem do commit' 130 | ``` 131 | 132 | O parâmetro `-m` é utilizado para escrever uma mensagem que explique o que aquele commit representa para a aplicação. Veja alguns exemplos de mensagens: 133 | 134 | * Correção do bug no botão de logout 135 | * Funcionalidade de login 136 | * Ajuste no tamanho das fontes 137 | * Alteração da cor de fundo da tabela de novos clientes 138 | * Correção ortográfica na mensagem de erro 139 | * Adicionando campo telefone no cadastro de clientes 140 | * Adicionando novo item na barra de menu superior 141 | * Simplificando código que calcula o valor do saldo devedor 142 | 143 | Perceba que as mensagens costumam ser curtas e objetivas em relação ao que aquele commit representa, facilitando assim quando for necessário analisar os commits do repositório. 144 | 145 | ### Indicando quais alterações farão parte do commit 146 | 147 | Antes de realizar um commit precisamos indicar ao Git quais das alterações farão parte dele, pois o Git não considera que *todas as modificações* que foram realizadas desde o último commit serão adicionadas ao próximo commit a ser realizado. 148 | 149 | E essa indicação é feita com a utilização do comando `git add`. Por exemplo, imagine um repositório no qual temos dois arquivos, `index.html` e `logo.png`, que foram modificados e queremos adicionar ao próximo commit. O comando que devemos executar antes do commit deve ser então: 150 | 151 | ``` 152 | git add index.html 153 | git add imagens/logo.png 154 | ``` 155 | 156 | Repare que devemos informar o *caminho completo* do arquivo, e não somente o seu nome, além de ter que adicionar cada arquivo separadamente. Isso acaba sendo algo meio *chato*, mas é possível adicionar todos os arquivos que foram modificados de uma só vez, utilizando o comando `add` da seguinte maneira: 157 | 158 | ``` 159 | git add . 160 | ``` 161 | 162 | O ponto(`.`) utilizado no comando anterior indica ao Git que queremos adicionar quaisquer alterações que tiverem sido realizadas no repositório, inclusive em arquivos que estejam em subdiretórios, ou seja, o comando é `recursivo`. 163 | 164 | ### Verificando o status do repositório 165 | 166 | E se eu não me lembrar quais arquivos foram modificados ou quais arquivos já foram adicionados? 167 | 168 | Para esse caso existe um outro comando útil do Git, que é o comando `git status`, tendo como objetivo indicar o *status* atual do repositório, ou seja, quais arquivos foram criados, modificados e excluídos, além de indicar também quais arquivos já foram *adicionados* pelo comando `add`. 169 | 170 | Ao rodar o comando `git status` em um repositório Git, uma mensagem como a demonstrada a seguir será apresentada: 171 | 172 | ``` 173 | On branch master 174 | Changes not staged for commit: 175 | (use "git add ..." to update what will be committed) 176 | (use "git checkout -- ..." to discard changes in working directory) 177 | 178 | modified: pom.xml 179 | 180 | Untracked files: 181 | (use "git add ..." to include in what will be committed) 182 | 183 | WebContent/WEB-INF/views/index.jsp 184 | 185 | no changes added to commit (use "git add" and/or "git commit -a") 186 | ``` 187 | 188 | Repare que a mensagem indica que um novo arquivo foi criado no repositório, que no caso é o arquivo `index.jsp`, além de também indicar que o arquivo `pom.xml` sofreu alterações. 189 | 190 | Se executarmos o comando `git add .` e em seguida o comando `git status`, a seguinte saída será exibida: 191 | 192 | ``` 193 | On branch master 194 | Changes to be committed: 195 | (use "git reset HEAD ..." to unstage) 196 | 197 | new file: WebContent/WEB-INF/views/index.jsp 198 | modified: pom.xml 199 | 200 | ``` 201 | 202 | Repare que agora a mensagem mudou, sendo que os dois arquivos estão aparecendo na seção `Changes to be committed`, a qual indica quais arquivos serão incluídos no próximo commit. 203 | 204 | ### Listando os commits do repositório 205 | 206 | Outro comando importante do Git é o `git log`, utilizado para listar todos os commits registrados no repositório. Veja a seguir um exemplo do que é exibido ao executar esse comando: 207 | 208 | ``` 209 | commit 97fddae580b08e977f60fbdc8ca6fdcba3ec7c92 (HEAD -> master, origin/master) 210 | Author: Rodrigo Caneppele 211 | Date: Mon Sep 24 15:56:13 2018 -0300 212 | 213 | corrigindo instrucoes e senha do mysql 214 | 215 | commit 197af796a89ebf4793414b36f9fbe6bd547a1bde 216 | Author: Rodrigo Caneppele 217 | Date: Fri Dec 8 11:33:14 2017 -0200 218 | 219 | context-path do projeto 220 | 221 | commit fcda2b3a95593865d007fd0d362029e10b5e6008 222 | Author: Rodrigo Caneppele 223 | Date: Fri Dec 8 11:32:41 2017 -0200 224 | 225 | atualizando instrucoes 226 | 227 | commit febb65e93cdb751cbc00cd089c71f1ca5639273d 228 | Author: Rodrigo Caneppele 229 | Date: Thu Nov 30 12:58:07 2017 -0200 230 | 231 | correcao no nome da tabela 232 | ``` 233 | 234 | Repare que, para cada commit, o Git exibe o *autor* do commit, a *data* que o commit foi realizado e também a *mensagem* do commit. Além disso, repare que cada commit possui um identificador único, por exemplo: `97fddae580b08e977f60fbdc8ca6fdcba3ec7c92`. 235 | 236 | Esse identificador, também chamado de `id`, é gerado automaticamente pelo Git e serve para diferenciar um commit do outro. 237 | 238 | ## Exercício: Utilizando o Git na aplicação 239 | 240 | Nesse exercício vamos utilizar o Git em nossa aplicação. 241 | 242 | 1. O primeiro passo será a criação do repositório. Abra o `Terminal`, acesse nele o diretório da aplicação e crie o repositório com o comando `git init`. Por exemplo: 243 | 244 | ``` 245 | cd Desktop/alura-forum 246 | git init 247 | ``` 248 | 249 | 2. O próximo passo é fazer o commit dos arquivos do projeto, mas antes precisamos utilizar o comando `git add` para indicar quais arquivos serão adicionados ao commit. Rode o seguinte comando no Terminal: 250 | 251 | ``` 252 | git add . 253 | ``` 254 | 255 | 3. Agora já podemos realizar o commit. Rode o seguinte comando: 256 | 257 | ``` 258 | git commit -m "criacao do repositorio do projeto" 259 | ``` 260 | 261 | 4. Por fim, verifique se tudo está ok no repositório, utilizando para isso o comando `git status`. A seguinte saída deve ser apresentada: 262 | 263 | ``` 264 | On branch master 265 | nothing to commit, working tree clean 266 | ``` 267 | 268 | ## Mais detalhes do Git 269 | 270 | Geralmente em uma aplicação podem existir arquivos que não queremos que façam parte do histórico de commits do Git, ou seja, arquivos aos quais o Git deve ignorar. 271 | 272 | Isso é comum para arquivos temporários, binários, ou outros similares. Por exemplo, na nossa aplicação vimos que existe o diretório `target`, utilizado pelo Maven ao gerar o build do projeto. 273 | 274 | Entretanto esse diretório e seus arquivos podem ser considerados como temporários, pois não são utilizados pelo código fonte da aplicação, podendo até serem excluídos, sem que isso causa efeitos colaterais nela. 275 | 276 | Sendo assim, ao realizar qualquer commit no repositório devemos tomar cuidado para não incluir acidentalmente tais arquivos ao utilizar o comando `git add`. 277 | 278 | Para evitar esse trabalho de ter que ficar lembrando de não incluir determinados arquivos no repositório, o Git possui um mecanismo que faz isso de maneira automatizada. 279 | 280 | Basta criar no diretório raiz do repositório um arquivo chamado `.gitignore`, e nele adicionar quais arquivos e diretórios devem sempre ser ignorados pelo Git. Veja a seguir um exemplo desse arquivo: 281 | 282 | ``` 283 | temp 284 | build 285 | /target/ 286 | *.jar 287 | ``` 288 | 289 | Inclusive o projeto `alura-forum` que foi disponibilizado para vocês durante o curso já possui tal arquivo. Se você acessar o diretório da aplicação no terminal e rodar o comando `ls -la` verá que será listado o arquivo `.gitignore`. Caso você queira visualizar o conteúdo desse arquivo diretamente no terminal, basta utilizar o comando `cat .gitignore`. 290 | 291 | O Git possui muitos outros recursos e comandos que veremos ao longo do treinamento. 292 | 293 | ## Hospedando o repositório no GitLab 294 | 295 | Uma das grandes vantagens do Git é ele funcionar de maneira *distribuída*, evitando assim a necessidade de se ter um *servidor central* para o repositório e fazer a sincronização com ele a cada novo commit. 296 | 297 | Isso nos permite trabalhar de maneira isolada e offline, que inclusive foi o que fizemos até então, pois criamos o repositório da aplicação e nele fizemos um commit sem estar conectado a nenhum servidor central externo. 298 | 299 | Embora isso seja uma característica interessante, ela nos traz um risco muito grande caso aconteça algo com o computador onde o repositório tenha sido criado, pois não estamos fazendo o backup dos arquivos e histórico de commits em nenhum outro local. 300 | 301 | No início desse capítulo discutimos o quão importante é manter um backup de nossos arquivos pessoais, sendo que isso também é válido para os repositórios de nossas aplicações. 302 | 303 | E além disso, para poder trabalhar em colaboração com outras pessoas na aplicação precisaremos compartilhar o repositório dela, para que assim todos consigam ter acesso ao código fonte dela e possam sincronizar suas modificações. 304 | 305 | A solução mais comum para esse tipo de problema é utilizar algum serviço online de hospedagem de repositórios Git, como GitHub, GitLab e Bitbucket, permitindo assim que as pessoas possam colaborar entre si, independente de onde elas estejam. 306 | 307 | ![Site do GitLab](imagens/capitulo-06/gitlab-site.png) 308 | 309 | Durante o curso utilizaremos o GitLab como serviço para hospedar o repositório da nossa aplicação, pois hoje em dia ele é um dos mais populares e utilizados ao redor do mundo, além de possuir diversas ferramentas relacionadas ao tema DevOps :) 310 | 311 | ## Exercício(opcional): Criando uma conta no GitLab 312 | 313 | Nesse exercício vamos criar uma nova conta no GitLab. Caso você já tenha cadastro no GitLab, pode pular esse exercício. 314 | 315 | 1. Acesse o site do GitLab em https://gitlab.com 316 | 317 | 2. No menu superior clique na opção **Register** 318 | 319 | 3. Preencha o formulário com seus dados e clique no botão **Register** para criar a conta. Obs: em baixo desse botão também existe a opção para fazer login via Google, Twitter, etc. 320 | 321 | 4. Você receberá um email com o link para verificação da conta. Acesse seu email e clique nesse link. Obs: Verifique a caixa de spam caso não tenha recebido o email. 322 | 323 | ## Exercício: Criando um repositório no GitLab 324 | 325 | Nesse exercício vamos criar um repositório em nossa conta do GitLab. 326 | 327 | 1. Acesse sua conta no site do GitLab 328 | 329 | 2. Clique no botão **New project** ou entre diretamente no endereço https://gitlab.com/projects/new 330 | 331 | 3. Preencha o campo *Project name* com **alura-forum**, deixe a visibilidade como **private** e clique no botão **Create project**. 332 | 333 | ![Tela de criar repositório no site do GitLab](imagens/capitulo-06/gitlab-new-project.png) 334 | 335 | ## Sincronizando o repositório local com o GitLab 336 | 337 | Agora que já criamos nosso repositório no GitLab, precisamos de alguma maneira o **vincular** com o repositório que criamos em nosso computador. 338 | 339 | No Git, esse repositório que está em nosso computador é chamado de **repositório local**. Já o repositório ao qual vamos vincular e sincronizar o nosso repositório local é chamado de **repositório remoto**. 340 | 341 | Para fazer essa *ponte* entre os repositórios local e remoto, devemos utilizar o comando `git remote add`, para assim adicionar um novo repositório remoto: 342 | 343 | ``` 344 | git remote add gitlab https://gitlab.com/usuario/repositorio.git 345 | ``` 346 | 347 | O comando `git remote add` precisa de dois parâmetros, sendo que o primeiro é o *apelido* do repositório remoto que estamos adicionando e o segundo é o endereço dele. 348 | 349 | O apelido é necessário, pois podemos ter mais de um repositório remoto vinculado a um mesmo repositório local. Com isso poderíamos ter um repositório remoto no GitLab e outro no GitHub, por exemplo, sincronizando nossos commits em ambos os serviços. 350 | 351 | Para saber quais são os repositórios remotos já adicionados em um repositório local, devemos utilizar o comando `git remote`: 352 | 353 | ``` 354 | git remote 355 | ``` 356 | 357 | O comando anterior exibe apenas os apelidos dos repositórios remotos, sendo necessário passar o parâmetro `-v` para ver também seus respectivos endereços. 358 | 359 | Após adicionar o repositório remoto já é possível sincronizar os commits, os enviando para o GitLab, com a utilização do comando `git push`: 360 | 361 | ``` 362 | git push gitlab master 363 | ``` 364 | 365 | O primeiro parâmetro do comando `push` é o apelido do repositório remoto ao qual enviaremos os commits, e o segundo é o nome da `branch` a qual pertencem esses commits. Mais adiante no curso veremos o que são e como funcionam as branchs no Git. 366 | 367 | Para fazer o caminho inverso, ou seja, atualizar o repositório **local** com os novos commits que foram enviados por outras pessoas para o repositório remoto, devemos utilizar o comando `git pull`, de maneira similar ao comando `git push`: 368 | 369 | ``` 370 | git pull origin master 371 | ``` 372 | 373 | ## Exercício: Enviando os commits para o repositório remoto 374 | 375 | Nesse exercício vamos sincronizar os commits do repositório local com o repositório remoto no GitLab. 376 | 377 | 1. Adicione o repositório remoto do GitLab em seu repositório local: 378 | 379 | ``` 380 | git remote add gitlab https://gitlab.com/SEU_USUARIO/alura-forum.git 381 | ``` 382 | 383 | 2. Envie os `commits` do repositório local para o repositório remoto: 384 | 385 | ``` 386 | git push gitlab master 387 | ``` 388 | 389 | 3. Verifique no GitLab se os commits e arquivos do projeto foram enviados com sucesso. 390 | 391 | ## Clonando um repositório já existente 392 | 393 | Caso uma nova pessoa entre para o time de desenvolvimento, ela precisará ter acesso ao código fonte do projeto e como ele já existe e está hospedado no GitLab, não será necessário criar um novo repositório local em seu computador. 394 | 395 | Nesse caso ela precisaria apenas **baixar** o repositório do GitLab para o seu computador, sendo que isso deve ser feito com o comando `git clone`. Por exemplo: 396 | 397 | ``` 398 | git clone https://gitlab.com/usuario/projeto.git 399 | ``` 400 | 401 | Ao rodar o comando anterior, o Git vai realizar uma cópia do repositório remoto para o nosso computador, criando um diretório com o mesmo nome do projeto. 402 | 403 | Ao acessar esse novo diretório, veremos que temos todos os arquivos do projeto e todo o histórico de commits. Além disso, o Git automaticamente já adiciona esse endereço que clonamos como nosso repositório remoto: 404 | 405 | ``` 406 | git remote -v 407 | 408 | origin https://gitlab.com/usuario/projeto.git (fetch) 409 | origin https://gitlab.com/usuario/projeto.git (push) 410 | ``` 411 | 412 | Repare que por padrão o Git coloca o apelido do repositório remoto como *origin*, pois ele representa a *origem* de onde foi baixado o repositório. 413 | 414 | ## Exercício: Renomeando o repositório remoto 415 | 416 | Nesse exercício vamos renomear o apelido do nosso repositório remoto, para que assim ele siga o padrão de nomenclatura padrão do Git. 417 | 418 | 1. Execute no terminal o comando `git remote -v`. A saída deve ser algo como: 419 | 420 | ``` 421 | gitlab https://gitlab.com/SEU_USUARIO/alura-forum.git (fetch) 422 | gitlab https://gitlab.com/SEU_USUARIO/alura-forum.git (push) 423 | ``` 424 | 425 | 2. Altere o apelido do repositório remoto de `gitlab` para `origin`: 426 | 427 | ``` 428 | git remote rename gitlab origin 429 | ``` 430 | 431 | 3. Verifique se o repositório remoto foi renomeado executando novamente o comando `git remote -v`. 432 | 433 | ## E quanto ao time de Ops? 434 | 435 | Até o momento falamos bastante sobre o Git e seu funcionamento, entretanto apenas do ponto de vista do time de desenvolvimento. Mas e quanto ao time de Ops, seria possível e interessante a utilização do Git? 436 | 437 | A resposta é sim! O time de Ops pode utilizar o Git, por exemplo, para controlar a evolução de arquivos de configuração de servidores, banco de dados, sistema operacional, etc. 438 | 439 | Isso é algo bem útil, pois todas as alterações que forem realizadas ficariam registradas em commits, com uma mensagem as explicando, evitando assim que o conhecimento fique concentrado apenas com a pessoa que as realizou. 440 | 441 | Um outro exemplo seria ao utilizar o conceito de `IaC`(Infrastructure as Code), ao qual toda a infra estrutura da aplicação é programável, com a utilização de arquivos de configuração. 442 | 443 | Certamente essas configurações vão evoluir e ser alteradas o tempo inteiro, e não podemos deixar de registrar cada uma dessas alterações, para os casos de backup, entendimento e rollback. 444 | 445 | Uma ferramenta de controle de versão, como o Git, é bastante útil para lidar com esses problemas que os times de Ops costumam enfrentar de maneira recorrente. 446 | -------------------------------------------------------------------------------- /08-integracao-continua.md: -------------------------------------------------------------------------------- 1 | # Integração Contínua 2 | 3 | Neste capítulo vamos aprender sobre Integração Contínua e entender o porquê dessa prática ser indispensável para um time DevOps, além de também aprender a utilizar o Jenkins como uma das principais ferramentas para tal prática. 4 | 5 | ## Trabalhando em time 6 | 7 | Já discutimos que desenvolver um software é uma tarefa bastante complexa e desafiadora, não sendo comum que apenas uma pessoa, de maneira isolada, seja responsável por todo o desenvolvimento dele. É mais provável que seja formado um time, com diversas pessoas colaborando entre si, para realizar tal tarefa. 8 | 9 | E com isso algumas dificuldades podem surgir: 10 | 11 | * Como fazer para que essas pessoas trabalhem todas ao mesmo tempo mexendo na mesma **base de código**? 12 | * Como fazer para que essas pessoas **sincronizem** sua parte do trabalho com as partes das outras? 13 | * Como identificar possíveis **conflitos** no código ao realizar a sincronização do trabalho? 14 | 15 | Já discutimos também, em capítulos anteriores, sobre essas dificuldades e que utilizar uma ferramenta de **controle de versão** é a principal solução para elas. Inclusive, para isso, aprendemos e começamos a utilizar o Git em nossa aplicação. 16 | 17 | Entretanto, apenas utilizar uma ferramenta de controle de versão não vai resolver todos os problemas, pois algumas dificuldades ainda podem permanecer e outras poderão surgir. 18 | 19 | Para entender melhor que tipos de problemas podem surgir, vamos imaginar a seguinte situação: nossa aplicação possui diversas funcionalidades que precisam ser desenvolvidas e outras que precisam ser ajustadas, e o time de desenvolvimento é formado por 8 pessoas. 20 | 21 | Suponha que você ficou responsável por desenvolver alguma dessas funcionalidades, por exemplo, uma tela que mostre um relatório mensal de tópicos criados no fórum da Alura. Você analisou o esforço para realizar essa tarefa e estimou um prazo de 4 dias para realizá-la. 22 | 23 | Após os 5 dias, você finalizou o trabalho e agora precisa sincronizar seus commits com o repositório central que está no GitLab. Vimos que isso é algo bem simples de se fazer com o Git, bastando apenas utilizar o comando `git push`. 24 | 25 | Porém, durante esses 5 dias em que você ficou trabalhando nessa funcionalidade, as outras 7 pessoas do time também estavam trabalhando em suas funcionalidades, realizando alterações no código fonte da aplicação e commits para registrá-las. 26 | 27 | Embora 5 dias possa parecer pouco tempo, quando temos muitas pessoas mexendo ao mesmo tempo no código fonte de uma aplicação, o trabalho acumulado por elas será muito grande, sendo que o efeito disso será percebido apenas quando elas forem sincronizar seus trabalhos. 28 | 29 | Antes de efetuar o `push`, você vai precisar executar o comando `pull`, para baixar os commits enviados ao repositório central pelas outras 7 pessoas do time. 30 | 31 | Como são muitas pessoas trabalhando na aplicação ao longo de 5 dias, serão muitos commits a serem baixados, sendo muito provável que alguns conflitos ocorram durante a sincronização. 32 | 33 | > **Conflitos?** 34 | > 35 | > Em sistemas de controle de versão conflitos ocorrem quando duas ou mais pessoas alteram um mesmo arquivo no repositório. 36 | > 37 | > Se as alterações forem em linhas distintas do arquivo, o Git é capaz de realizar o **merge(mesclagem)** de maneira automática, sem a necessidade de intervenção humana. 38 | > 39 | > Somente nos casos das alterações terem ocorrido na mesma linha de um determinado arquivo é que precisaremos resolver manualmente o conflito, editando o arquivo e indicando ao Git que o conflito foi resolvido. 40 | 41 | Perceba então que quanto mais tempo sem sincronizar o código fonte da aplicação, com as alterações feitas pelas outras pessoas do time, mais commits com alterações estarão sendo acumulados, aumentando proporcionalmente com isso as chances de conflitos ocorrerem durante a próxima sincronização. 42 | 43 | Agora imagine que o time é formado por 16 pessoas e você ficou 25 dias trabalhando de maneira isolada no desenvolvimento de uma determinada funcionalidade. É bem provável que a sincronização, também chamada de **integração**, será bastante *dolorosa*. 44 | 45 | ## Integration hell 46 | 47 | Trabalhar durante muito tempo de maneira isolada, sem integrar seu código com o repositório central, pode levar a problemas de conflitos ao realizar a integração, que podem demandar muito tempo para serem resolvidos, afinal, estamos falando de centenas, ou até milhares de alterações realizadas no repositório durante todo esse tempo. 48 | 49 | Infelizmente essa prática ainda é comum em muitos projetos de software, podendo levar as equipes de desenvolvimento a terem uma certa **aversão** à integração de código, pois as pessoas sabem que isso se trata de um evento traumático e que certamente vai gerar muita dor de cabeça. 50 | 51 | Inclusive, as pessoas criaram um termo que define bem essa situação: **Integration Hell**, também conhecido como **Merge Hell**. Isso se deve justamente ao fato de ser um verdadeiro *inferno* o fato de ter que integrar o código e gastar um bom tempo resolvendo problemas de conflitos que são bastante chatos de lidar. 52 | 53 | É bem comum encontrar alguns times de desenvolvimento que costumam levar horas, ou até mesmo dias, para fazer a integração do código fonte da aplicação. Geralmente essa atividade é realizada apenas quando é necessário subir uma nova versão da aplicação em ambiente de produção. Também é comum que essa atividade seja realizada apenas nas sextas-feiras, pois o time de desenvolvimento terá o final de semana para resolver os problemas de conflitos, caso seja necessário. 54 | 55 | Além dos conflitos, outro problema muito comum ao realizar a integração acontece quando, mesmo depois da resolução dos conflitos, a aplicação não funciona como deveria. Às vezes uma alteração em uma parte do código produz efeitos colaterais em outras partes, sem que a pessoa que realizou tal alteração perceba. 56 | 57 | Os testes automatizados, conforme foi visto no capítulo anterior, costumam ajudar bastante a evitar esse problema, mas nem sempre as pessoas se lembram de executar todos os testes após alterar o código fonte da aplicação, podendo com isso deixar de ter rapidamente o feedback de que um ou mais bugs foram gerados. 58 | 59 | ## Integração Contínua 60 | 61 | Existe uma frase bem famosa do Martin Fowler, citada no livro *Continuous Integration*, que diz: "If it hurts, do it more often", que em português seria algo como: "Se dói, faça mais vezes". 62 | 63 | Embora essa frase seja meio *estranha*, soando até como *masoquismo*, ela reflete exatamente a solução para os problemas citados acima, pois integrar código é uma tarefa dolorosa apenas quando não a fazemos com bastante frequência. 64 | 65 | Ao realizar a integração apenas ao finalizar uma tarefa, como por exemplo o desenvolvimento de uma funcionalidade, ocorre um acumulo de alterações no código fonte da aplicação, que certamente vai ser bastante trabalhoso de integrar. 66 | 67 | Mas ao diminuir esse tempo, por exemplo integrando semanalmente, diariamente ou até mesmo diversas vezes ao longo do dia, diminuímos com isso o acúmulo de alterações, reduzindo assim também a dificuldade e problemas de se integrar código. 68 | 69 | Esse é justamente o ponto principal da frase anterior, pois o foco não é aumentar a frequência de integração para que as pessoas se *acostumem* com a dor, mas sim para **reduzir**, ou quem sabe até eliminar, a dor. 70 | 71 | Ou seja, quanto menos tempo levamos para integrar nosso código com o repositório central, menores são as chances de conflitos e outros problemas acontecerem, pois o trabalho acumulado será bem pequeno. 72 | 73 | Esse é justamente o *coração* da prática que ficou conhecida como **Continuous Integration(Integração Contínua)**, que é uma das principais práticas utilizadas por times DevOps. 74 | 75 | O termo *integração contínua* foi descrito inicialmente por **Grady Booch**, um dos criadores da *UML(Unified Modeling Language)*, em 1991 em seu livro *Object Oriented Design: With Applications*, mas se popularizou apenas após **Kent Beck** ter o incluído com uma das práticas do *XP(Extreme Programming)*, que é uma das principais metodologias ágeis utilizadas por times de desenvolvimento de software. 76 | 77 | Integração contínua não é uma ferramenta, como algumas pessoas costumam interpretar de maneira errônea, mas sim uma **prática**. Tal prática consiste no **hábito** que as pessoas que fazem parte do time de desenvolvimento devem ter de continuamente integrarem o código de seu repositório local com o repositório remoto. 78 | 79 | Ao invés de realizar tais integrações em períodos longos, como semanas ou meses, o ideal é sempre preferir períodos mais curtos, como dias ou horas. 80 | 81 | Dessa forma não ficamos com o nosso repositório local desatualizado por um período muito longo, algo que poderia aumentar drasticamente as chances de conflitos e bugs. 82 | 83 | Embora não seja obrigatório, é altamente recomendado que as práticas de build e testes automatizados também façam parte do processo de integração contínua, para assim potencializar seu resultado e benefícios. 84 | 85 | ## Princípios da integração contínua 86 | 87 | Para que o processo de integração contínua se torne um hábito entre todas as pessoas do time de desenvolvimento, não se tornando algo complexo e trabalhoso, alguns princípios devem ser seguidos. 88 | 89 | Ao seguir tais princípios, aumentamos as chances de aplicar corretamente a prática de integração contínua e com isso colher todos os seus benefícios. 90 | 91 | ### Utilize um repositório de código 92 | 93 | Já discutimos anteriormente que utilizar uma ferramenta de controle de versão é algo essencial para qualquer projeto de desenvolvimento de software. Com integração contínua isso se torna mais importante ainda. 94 | 95 | As pessoas do time precisam ter acesso ao código fonte da aplicação, para poder obter uma cópia dele e então começar a trabalhar nela, criando, editando e removendo seus arquivos. 96 | 97 | Gerenciar manualmente os milhares de arquivos que fazem parte do código fonte da aplicação e todas as modificações efetuadas neles se torna uma tarefa praticamente impossível de ser realizada. 98 | 99 | Portanto, utilizar uma ferramenta de controle de versão e manter o código fonte da aplicação em um repositório é um dos principais princípios que devem ser seguidos para se realizar a prática da integração contínua. 100 | 101 | Não somente o código fonte da aplicação deve ser mantido no repositório, mas também todo e qualquer recurso que seja essencial para ela ser executada normalmente. Isso inclui, por exemplo, os seguintes tipos de recursos: 102 | 103 | * Scripts de testes 104 | * Scripts de banco de dados 105 | * Arquivos de configurações 106 | * Bibliotecas externas 107 | 108 | Para avaliar se a regra anterior está sendo seguida, responda ao seguinte questionamento: Se eu baixar uma cópia do repositório para um computador recém formatado, serei capaz de executar o build da aplicação sem a necessidade de baixar quaisquer outros arquivos externos? 109 | 110 | Caso a resposta do questionamento anterior seja negativa, isso significa que o repositório da aplicação está incompleto, ou seja, existem arquivos essenciais que deveriam estar presentes no repositório, mas que não estão. 111 | 112 | ### Automatize o processo de build 113 | 114 | Integração contínua não se resume a apenas sincronizar o repositório local com o remoto e resolver os conflitos de códigos que eventualmente ocorrerem. 115 | 116 | Não adianta nada apenas resolver os conflitos de código, se não pudermos mais realizar o build da aplicação por conta de algum problema ter ocorrido com as alterações realizadas. 117 | 118 | Ou seja, é importante também, após realizar a sincronização e resolução dos conflitos, realizar o build da aplicação, para verificar se as últimas alterações realizadas no código fonte dela não causaram algum efeito colateral. 119 | 120 | Também é importante que esse processo de build seja automatizado, para que ele seja executado de maneira mais ágil e com menos riscos de falhas. 121 | 122 | Perceba então que automatizar o processo de build, para que ele possa ser executado de maneira ágil e confiável a cada integração realizada, se torna também um princípio importante no processo de integração contínua. 123 | 124 | Automatização de build é outro assunto que também já foi discutido anteriormente aqui no curso, sendo que já sabemos muito bem como o realizar e sua grande importância para um time DevOps. 125 | 126 | ### Utilize testes automatizados 127 | 128 | No capítulo anterior discutimos sobre testes automatizados e os grandes benefícios que tal prática proporciona para um projeto de software. 129 | 130 | Justamente por conta disso é que a prática de escrever testes automatizados em uma aplicação se torna, também, um dos princípios da integração contínua. 131 | 132 | Isso porque de nada adianta gerar o build da aplicação com sucesso, gerando com isso o artefato que pode ser realizado o deploy em produção, se nela existem diversos bugs que foram gerados por conta das últimas alterações que foram realizadas nela. 133 | 134 | É extremamente importante também garantir que tudo o que estava funcionando, antes de realizar a integração, continue funcionando normalmente após a integração ser realizada. 135 | 136 | E sabemos que a única maneira de garantir isso é testando a aplicação, para verificar se nenhuma das modificações gerou um efeito colateral resultando em bugs. 137 | 138 | Testar todas as funcionalidades da aplicação de maneira manual, a cada nova integração, se torna algo muito trabalhoso e lento com o passar do tempo, chegando a se tornar algo inviável. 139 | 140 | Sendo assim, nada melhor do que automatizar todos esses testes, para agilizar esse processo de detectar bugs e garantir que nada foi impactado com as novas alterações realizadas no código fonte da aplicação. 141 | 142 | ### Integre os testes automatizados ao processo de build 143 | 144 | De nada adianta ter testes automatizados na aplicação, se eles não forem executados continuamente para a detecção de possíveis bugs. 145 | 146 | Eventualmente algumas alterações no código fonte da aplicação podem gerar efeitos colaterais, fazendo com que alguns testes automatizados falhem por conta de bugs terem surgido. 147 | 148 | Devemos então ter o hábito de sempre executar os testes automatizados da aplicação, principalmente após realizar alterações no código fonte dela, para detectar o quanto antes os problemas. 149 | 150 | Porém, pode acontecer das pessoas se esquecerem de executar os testes automatizados, deixando passar batido alguns bugs que deveriam ter sido detectados. 151 | 152 | Até aí não seria um grande problema, pois o código foi integrado apenas localmente, sendo que tais alterações, a princípio, não foram enviadas para o ambiente de produção. 153 | 154 | Problema mesmo seria se realizarmos o build da aplicação para realizar um deploy em ambiente de produção, sem antes executar os testes automatizados, pois corremos o risco de gerar um artefato contendo bugs. 155 | 156 | Ou seja, o mínimo que devemos fazer é integrar a execução dos testes automatizados ao processo de build da aplicação, para que eles sejam executados automaticamente a cada novo build realizado, inclusive forçando uma interrupção do processo de build caso algum dos testes falhe, pois isso indica a presença de um bug. 157 | 158 | A regra é bem simples e clara: não podemos gerar os artefatos do build da aplicação no caso de existirem bugs nela! 159 | 160 | Isso é extremamente importante para se evitar que bugs sejam colocados em ambiente de produção, prejudicando os usuários da aplicação e até mesmo a organização como um todo. 161 | 162 | Esse é mais um dos princípios do processo de integração contínua, que inclusive já estamos seguindo, pois o build de nossa aplicação está configurado para ser automaticamente interrompido no caso de algum teste automatizado falhar. 163 | 164 | ### Sincronize diariamente com o repositório remoto 165 | 166 | Esse talvez possa ser considerado como o principal princípio da integração contínua, pois de nada adianta seguir todos os princípios anteriores, se a integração em si é realizada com pouca frequência. 167 | 168 | Devemos encurtar ao máximo o intervalo em que as integrações ocorrem, para minimizar o **volume** de código a ser integrado, pois já discutimos bastante sobre os problemas e dificuldades que podemos enfrentar ao não seguir esse hábito. 169 | 170 | A periodicidade recomendada para a sincronização com o repositório remoto é diária, ou seja, pelo menos uma vez ao dia devemos sincronizar nosso repositório local com o remoto, para assim disparar todo o processo de integração contínua e então detectar e corrigir o quanto antes os problemas que surgirem. 171 | 172 | Se possível, o ideal seria tentar encurtar mais ainda esse período, realizando então diversas integrações ao longo de todos os dias de trabalho. 173 | 174 | ### Mantenha ágil o processo de build 175 | 176 | Um dos principais fatores que contribuem para a redução da frequência, ou até mesmo o abandono, da prática de integração contínua é o seu tempo de execução ser muito longo. 177 | 178 | No início do projeto o tempo para a execução do processo de integração contínua como um todo costuma ser bem pequeno, com uma duração de poucos minutos ou até mesmo segundos. 179 | 180 | Porém, conforme a aplicação vai crescendo, com a adição de novas funcionalidades, testes automatizados e complexidade, é natural que o esse tempo também aumente proporcionalmente, podendo levar vários minutos ou até mesmo horas, em casos extremos. 181 | 182 | Imagine uma aplicação cujo processo de integração contínua demore 20 minutos para ser concluído. Certamente as pessoas do time não vão gostar do fato de terem de esperar 20 minutos a cada integração que fizerem, pois isso vai impactar absurdamente sua produtividade. 183 | 184 | Nesse caso é bem provável que as pessoas parem de realizar o processo de integração contínua, ou, no mínimo, diminuam drasticamente sua frequência, para que assim consigam trabalhar de maneira produtiva, sem muitos momentos de espera e ociosidade. 185 | 186 | Ou seja, precisamos ficar sempre atentos a quanto tempo leva para que o ciclo de integração contínua seja concluído, realizando ajustes quando ele estiver muito elevado. 187 | 188 | Agora você deve estar se perguntando: mas qual é o tempo ideal de duração do processo de integração contínua da aplicação que estou desenvolvendo? 189 | 190 | Infelizmente não existe uma resposta padrão para essa pergunta. Cada aplicação tem suas necessidades e particularidades distintas, fazendo com que esse tempo varie de projeto para projeto. 191 | 192 | É possível utilizar como base uma prática do XP chamada **10-minute build**, que recomenda que o build seja executado em no máximo 10 minutos, pois um tempo maior do que esse vai causar uma redução na frequência de sua realização, fazendo com que o time perca feedbacks importantes e rápidos sobre a situação atual da aplicação. 193 | 194 | ### Dispare o processo de integração contínua a cada novo commit 195 | 196 | Ao invés de criar uma especie de *calendário* para a execução do processo de integração contínua, ou seja, definir horários ou uma periodicidade específica, é mais simples e fácil o disparar a cada novo commit efetuado no repositório. 197 | 198 | Isso evitar termos de ficar lembrando quando precisamos disparar o processo, além de fazer mais sentido, pois cada commit representa um conjunto de modificações que foi realizado no código fonte da aplicação. 199 | 200 | ### Utilize um servidor para executar a integração contínua 201 | 202 | Até o momento falamos bastante sobre automatização, mas o foco dela era em algumas das etapas do processo de integração contínua e não no processo em si. 203 | 204 | Para agilizar o processo e diminuir o risco de esquecimento ou de erros em sua execução, o ideal é sempre utilizar alguma ferramenta que dispare o processo de integração contínua de maneira automatizada para o time. 205 | 206 | Inclusive podemos instalar e configurar essa ferramenta em algum servidor externo, evitando que tenhamos que executar o processo em nosso próprio computador. 207 | 208 | Dessa forma podemos focar em desenvolver o software em si, de tal forma que o processo de integração contínua funcionará de maneira transparente para o time de desenvolvimento. A única coisa que o time precisará fazer é ter o hábito de sincronizar seu repositório continuamente. 209 | 210 | Como não estaremos mais disparando e acompanhando manualmente a execução do processo, precisamos também configurar para que a ferramenta nos alerte de maneira automática, no caso de erros terem sido encontrados. 211 | 212 | Seguindo esse princípio o time poderá ficar mais focado em desenvolver o software em si, sendo alertado eventualmente em casos de problemas, e com isso sua produtividade não será muito afetada. 213 | 214 | Existem diversas ferramentas que nos auxiliam com esse processo de integração contínua, tais como: 215 | 216 | * Jenkins 217 | * Travis CI 218 | * Circle CI 219 | * Bamboo 220 | * Team City 221 | * Code Ship 222 | 223 | Mais adiante nesse capítulo aprenderemos a utilizar o Jenkins como nossa principal ferramenta para integração contínua. 224 | 225 | ### Imediatamente corrija os problemas que forem detectados 226 | 227 | Sempre que um problema for detectado, independente se foi por uma pessoa do time, ao realizar o processo de integração contínua manualmente, ou por uma ferramenta, que disparou o processo de maneira automatizada, o time deve parar o que estiver fazendo e imediatamente focar na resolução dele. 228 | 229 | Isso é muito importante para evitar que os problemas se acumulem, além de que quanto mais tempo demoramos para resolver um problema, mais difícil será de lembrar o porquê das alterações que o causaram terem sido realizadas. 230 | 231 | Ou seja, será muito mais fácil de encontrar e resolver o problema na hora que ele surgir, pois ainda não teremos uma quantidade muito grande de trabalho acumulado e também porque o conhecimento ainda estará *fresco* na cabeça das pessoas do time. 232 | 233 | ### Torne visível a todos o processo de integração contínua 234 | 235 | No início do curso discutimos que transparência é um dos principais pilares culturais para a adoção do modelo DevOps em uma organização, pois sem transparência não haverá confiança. 236 | 237 | Esse pilar também é válido para o processo de integração contínua, pois todas as pessoas do time deveriam saber como funciona esse processo em sua aplicação, além de também conseguir visualizar os problemas e possíveis melhorias nele. 238 | 239 | Deixar o processo de integração contínua disponível e visível a todos é mais uma maneira de praticar o princípio da transparência, além de também ser considerado como uma forma de comunicação. 240 | 241 | É comum que alguns times de desenvolvimento utilizem um monitor ou TV de tela grande, geralmente ficando na mesma sala em que o time trabalha, como forma de seguir esse princípio, pois assim qualquer pessoa, tanto do time quanto externa, ficará sabendo de maneira bem clara e direta como está a situação da aplicação. 242 | 243 | ![Exemplo de televisão mostrando o status do build de aplicações](imagens/capitulo-08/tv-build.jpeg) 244 | 245 | As ferramentas de integração contínua, como o Jenkins, possuem recursos para exibir de maneira visual o status de cada aplicação, nos auxiliando com isso a seguir esse princípio. 246 | 247 | ### Deixe acessível os artefatos gerados pelos builds 248 | 249 | Lembre-se que o resultado do build da aplicação é um artefato que pode ser colocado em produção. Para simplificar esse processo, é importante facilitar o acesso a tais artefatos. 250 | 251 | Geralmente na própria ferramenta de integração contínua conseguimos ter acesso aos artefatos produzidos por cada um dos builds que foram executados, facilitando com isso o acesso a eles. 252 | 253 | Isso é importante também para que o time de Ops não precise ficar interrompendo alguém do time de Dev toda vez que precisar ter acesso aos artefatos da aplicação para realizar um novo deploy. 254 | 255 | Aqui também, novamente, podemos ver o pilar da transparência sendo aplicado. 256 | 257 | ### Automatize o processo de deploy 258 | 259 | Pelo mesmo fato de ser extremamente importante automatizar o processo de build da aplicação, o processo de deploy também deveria ser automatizado. 260 | 261 | Além de agilizar o deploy de uma nova versão da aplicação, a automatização vai reduzir o risco de erros que podem ser causados quando esse processo é executado de maneira manual. 262 | 263 | Mais adiante no curso veremos com mais detalhes e aplicaremos esse princípio em nossa aplicação. 264 | 265 | ## Jenkins 266 | 267 | **Jenkins**(https://jenkins.io) é um servidor de integração contínua capaz de orquestrar de maneira automatizada o fluxo utilizado em processos de integração contínua. Por ser gratuito e extensível, por meio de plugins, se tornou bastante popular e utilizado ao redor do mundo. 268 | 269 | ![Imagem mostrando logotipo e slogan do Jenkins](imagens/capitulo-08/jenkins-logo.png) 270 | 271 | Ele foi desenvolvido em Java, o que o torna portável, mas também suporta aplicações em diversas outras linguagens de programação. Utilizaremos o Jenkins ao longo do curso, sendo que nos próximos exercícios aprenderemos como o instalar, configurar e utilizar. 272 | 273 | ## Exercício: Instalação do Jenkins 274 | 275 | Nesse exercício vamos fazer a instalação e configuração inicial do Jenkins. 276 | 277 | 1. Acesse o diretório do curso e copie o arquivo `jenkins.war` para o **Desktop**. 278 | 279 | 2. Abra o terminal, acesse o diretório Desktop e rode o seguinte comando para inicializar o Jenkins: 280 | 281 | ``` 282 | java -jar jenkins.war --httpPort=8082 283 | ``` 284 | 285 | 3. A partir da versão 2 o jenkins possui um mecanismo de autenticação que já vem habilitado por padrão. Na primeira vez que você executar o jenkins pelo terminal uma senha será gerada para acessá-lo: 286 | 287 | ![Senha gerada pelo Jenkins no Terminal](imagens/capitulo-08/jenkins-senha-terminal.png) 288 | 289 | 4. Abra o navegador e acesse o Jenkins em http://localhost:8082 290 | 291 | ![Tela do Jenkins para adicionar a senha padrão](imagens/capitulo-08/jenkins-senha-tela.png) 292 | 293 | 5. Na próxima tela temos a possibilidade de instalar os plugins que queremos utilizar no Jenkins: 294 | 295 | ![Tela para escolher o modo de instalação dos plugins](imagens/capitulo-08/jenkins-plugins-modo.png) 296 | 297 | 6. Selecione a segunda opção(**Select plugins to install**) e na próxima tela clique no link **None**, para desmarcar os plugins que já vem selecionados por padrão: 298 | 299 | ![Tela de listagem de plugins](imagens/capitulo-08/jenkins-plugins-none.png) 300 | 301 | 7. Inicialmente precisaremos apenas dos plugins do **Git** e do **Maven Integration**. Selecione-os e clique no botão **Install**. 302 | 303 | ![Tela de plugins mostrando o plugin do Git](imagens/capitulo-08/jenkins-plugins-git.png) 304 | 305 | 8. O próximo passo será a criação de um usuário `admin` no jenkins. Crie um usuário com o username **admin** e com password **caelum**. Preencha também os campos `Full name` e `E-mail address` com o seu nome e email, e então clique no botão **Save and finish**: 306 | 307 | ![Tela com formulário para criação do usuário admin](imagens/capitulo-08/jenkins-form-admin.png) 308 | 309 | 9. Na próxima tela, de configuração da instância do Jenkins, deixe a configuração padrão e clique no botão **Save and finish**. 310 | 311 | ![Tela de configuração da instância do Jenkins](imagens/capitulo-08/jenkins-instancia.png) 312 | 313 | 10. Por fim, clique no botão **Start using Jenkins** para acessar a tela principal do Jenkins: 314 | 315 | ![Tela principal do Jenkins](imagens/capitulo-08/jenkins-home.png) 316 | 317 | ## Integração contínua com Jenkins 318 | 319 | Agora que o Jenkins já está pronto para uso, podemos o utilizar para melhorar nosso processo de integração contínua. A ideia agora é seguir os **princípios** mencionados anteriormente. 320 | 321 | Inclusive, boa parte desses princípios nós já estamos seguindo, como por exemplo, estamos utilizando o Git para controle de versão, automatizamos o build da aplicação, estamos escrevendo testes automatizados e eles estão integrados ao build, e o build está sendo executado de maneira ágil. 322 | 323 | O próximo passo será utilizar o Jenkins como servidor, para automatizar o processo de executar o build da aplicação a cada novo commit efetuado no repositório, além de nos alertar no caso de ocorrer algum erro no processo ou no caso de algum teste automatizado falhar. 324 | 325 | ## Exercício: Utilizando o Jenkins como servidor de integração contínua 326 | 327 | Nesse exercício vamos utilizar o Jenkins como servidor de integração contínua, configurando-o para executar os testes automatizados a cada novo commit realizado no repositório da aplicação. 328 | 329 | 1. Acesse o Jenkins no browser em http://localhost:8082 e, no menu lateral esquerdo, clique na opção **New Item**. 330 | 331 | 2. Preencha o campo *item name* com **alura-forum-testes**, selecione a opção **Maven project** e clique no botão **Ok**. 332 | 333 | ![Tela de criação de Item no Jenkins](imagens/capitulo-08/jenkins-new-item.png) 334 | 335 | 3. No formulário de configuração do novo Item, procure a seção chamada **Source Code Management**, marque a opção **Git** e no campo **Repository URL** preencha com **file:///home/LOGIN_DA_TURMA/Desktop/alura-forum**. Obs: Deve ser o caminho do repositório Git da aplicação alura-forum em seu computador. Em caso de dificuldades, peça ajuda ao instrutor(a). 336 | 337 | ![Source Code Management na tela de configuração de item no Jenkins](imagens/capitulo-08/jenkins-new-item-scm.png) 338 | 339 | 4. Na seção **Build Triggers**, marque a opção **Poll SCM** e no campo **Schedule** preencha com: `* * * * *`. 340 | 341 | ![Build Triggers na tela de configuração de item no Jenkins](imagens/capitulo-08/jenkins-new-item-build-triggers.png) 342 | 343 | 5. Na seção **Build**, preencha o campo **Goals and options** com o valor: `clean test` e clique no botão **Save** para finalizar a configuração. 344 | 345 | ![Build na tela de configuração de item no Jenkins](imagens/capitulo-08/jenkins-new-item-build.png) 346 | 347 | 6. Para forçar um novo build, clique no botão **Build Now**, localizado no menu lateral esquerdo da tela: 348 | 349 | ![Botão Build Now no Jenkins](imagens/capitulo-08/jenkins-build-now.png) 350 | 351 | 7. O build deve passar, e clicando nele somos redirecionados para a tela de detalhes, na qual podemos ver quais testes foram executados, dentre outras informações: 352 | 353 | ![Tela de detalhes do build no Jenkins](imagens/capitulo-08/jenkins-build-resultado.png) 354 | 355 | 8. Repare que no canto superior direito da tela é informado quanto tempo o build levou para ser executado. No exemplo anterior, levou apenas 23 segundos, que é um tempo muito bom. Claro, esse tempo só foi bem pequeno pelo fato da nossa aplicação possuir poucos testes, sendo natural ele aumentar com o andamento do projeto. 356 | 357 | ## Plugins do Jenkins 358 | 359 | Uma das grandes vantagens do Jenkins é sua extensibilidade, obtida por meio de **plugins** que podem ser criados para adicionar novas funcionalidades a ele. 360 | 361 | Um plugin pode ser desenvolvido por qualquer pessoa no mundo, podendo também ser compartilhado livremente para a comunidade tirar benefício dele. Atualmente o Jenkins possui mais de 1500 plugins, utilizados para melhorar algumas tarefas, tais como: relatórios de testes, análise estática de código, build e deploy da aplicação, etc. 362 | 363 | ![Tela de plugins no site do Jenkins](imagens/capitulo-08/jenkins-site-plugins.png) 364 | 365 | ## Exercício: Utilizando plugins do Jenkins 366 | 367 | Nesse exercício vamos adicionar alguns plugins ao Jenkins, para tirar proveito de sua extensibilidade e incrementar nosso processo de integração contínua. 368 | 369 | 1. Acesse o Jenkins no browser em https://localhost:8082 370 | 371 | 2. No menu lateral esquerdo clique na opção **Manage Jenkins**. 372 | 373 | 3. Na tela que foi aberta, selecione a opção **Manage Plugins**. 374 | 375 | ![Opção Manage Plugins](imagens/capitulo-08/jenkins-manage-plugins.png) 376 | 377 | 4. Na tela que foi aberta, clique na aba superior **Available** e espere o Jenkins carregar a lista de plugins disponíveis. 378 | 379 | ![Aba Available na tela de Manage Plugins](imagens/capitulo-08/jenkins-manage-plugins-available.png) 380 | 381 | 5. Marque os seguintes plugins: **Green ball**, **Radiator View** e **Test Results Analyzer**, e então clique no botão **Download now and install after restart**. 382 | 383 | 6. Na tela de instalação que foi aberta, marque a checkbox **Restart Jenkins when installation is complete and no jobs are running** e aguarde a finalização da instalação. 384 | 385 | ![Tela de instalação dos plugins](imagens/capitulo-08/jenkins-manage-plugins-install.png) 386 | 387 | 7. O plugin *Green balls* é ativado automaticamente e sua função é trocar a cor de azul para verde, nos builds executados com sucesso: 388 | 389 | ![Dashboard do Jenkins com plugin green balls](imagens/capitulo-08/jenkins-plugin-green-ball.png) 390 | 391 | 8. O plugin *Test Results Analyzer* adiciona uma nova tela com mais informações sobre os testes automatizados da aplicação. Para acessá-lo, basta entrar na tela de detalhes do *Item* **alura-forum-testes** e clicar na nova opção **Test Results Analyzer** no menu lateral esquerdo: 392 | 393 | ![Tela do plugin Test Results Analyzer](imagens/capitulo-08/jenkins-plugin-test-results-analyzer.png) 394 | 395 | 9. O plugin *Radiator View* precisa ser configurado, para adicionar uma nova forma de visualizar o status de cada projeto sendo monitorado pelo Jenkins. Acesse a tela principal do Jenkins e clique no botão com o símbolo **+**, localizado ao lado da aba superior **All**: 396 | 397 | ![Botão para adicionar nova view no Jenkins](imagens/capitulo-08/jenkins-plugin-radiator-botao.png) 398 | 399 | 10. No formulário que foi aberto, preencha o campo **View name** com o valor **Radiator**, marque a opção **Raditor** e clique no botão **Ok**: 400 | 401 | ![Tela de configuração de nova view no Jenkins](imagens/capitulo-08/jenkins-plugin-radiator-form.png) 402 | 403 | 11. No novo formulário que foi aberto, marque o projeto *alura-forum-testes* na opção **Jobs** e marque também as opções **Show stable builds** e **Show build details**, e então finalize clicando no botão **Ok**. 404 | 405 | ![Tela do Radiator View](imagens/capitulo-08/jenkins-plugin-radiator-tela.png) 406 | 407 | 12. O Radiator divide a tela de acordo com o número de projetos selecionados, exibindo como fundo de cada um a cor verde, no caso do último build ter passado com sucesso, ou vermelho no caso de ter falhado. Essa tela do Radiator poderia ser exibida em um monitor ou TV de tela grande na sala do time DevOps, para que todos tenham visibilidade do status de cada projeto, além de tornar ágil a identificação das aplicações cujo build falhou. 408 | 409 | Para conhecer melhor esses e outros plugins do Jenkins, acesse o site: https://plugins.jenkins.io 410 | 411 | ## Branches 412 | 413 | Uma outra abordagem muito utilizada para se trabalhar em time, com várias pessoas utilizando o mesmo repositório de código, é utilizar o conceito chamado de **branch**, sendo esse um recurso disponibilizado pelos sistemas de controle de versão. 414 | 415 | Todo commit é realizado em alguma branch, sendo que no caso do Git ele cria automaticamente uma branch chamada **master**, que geralmente é utilizada como branch principal do projeto. 416 | 417 | Mas é possível também criar outras branches no repositório, além da branch *master*, para assim ser possível **separar** logicamente os commits do repositório. Essa separação permite, por exemplo, que uma pessoa trabalhe e realize seus commits em outra branch, de maneira isolada, sem atrapalhar com isso as outras pessoas, que podem continuar a trabalhar na branch master. 418 | 419 | ### Utilizando branches no Git 420 | 421 | No Git, branches são bem simples e performáticas de se trabalhar, algo bem diferente das branches no SVN, que eram lentas e causavam muita dor de cabeça para os times de desenvolvimento. 422 | 423 | Para listar as branches de um repositório devemos utilizar o comando `git branch`: 424 | 425 | ``` 426 | git branch 427 | 428 | * master 429 | ``` 430 | 431 | Repare que foi listada apenas a branch `master`, que é a única existente em nosso repositório. O asterisco(`*`) antes do nome `master` é para indicar em qual branch estamos no momento. 432 | 433 | Para criar uma nova branch devemos utilizar o comando `git branch nome_da_branch`: 434 | 435 | ``` 436 | git branch login 437 | ``` 438 | 439 | Agora ao executar novamente o comando `git branch` veremos que temos duas branches no repositório: 440 | 441 | ``` 442 | git branch 443 | 444 | login 445 | * master 446 | ``` 447 | 448 | Podemos trocar de branch com o comando `git checkout nome_da_branch`: 449 | 450 | ``` 451 | git checkout login 452 | 453 | Switched to branch 'login' 454 | ``` 455 | 456 | E agora ao realizar novos commits eles serão registrados na branch `login`, que é a branch selecionada no momento. 457 | 458 | ### Merge de commits 459 | 460 | Após finalizar o trabalho em uma branch separada, vamos precisar juntar os commits realizados nela aos novos commits da branch `master`. Isso é feito com a utilização do comando `git merge nome_da_branch`: 461 | 462 | ``` 463 | git checkout master 464 | git merge login 465 | ``` 466 | 467 | Caso ocorra algum conflito, o Git nos avisará e precisaremos resolvê-los para continuar com o processo de `merge` dos commits. 468 | 469 | Caso a branch não seja mais utilizada, é possível excluí-la com o comando `git branch -d nome_da_branch`: 470 | 471 | ``` 472 | git branch -d login 473 | 474 | Deleted branch login (was a43904b). 475 | ``` 476 | 477 | ### Feature-Branch 478 | 479 | Existe uma prática utilizada por diversos times de desenvolvimento ao redor do mundo, que consiste em sempre desenvolver as funcionalidades da aplicação em branches separadas, evitando com isso realizar commits diretamente na branch `master`. Essa prática é chamada de **Feature-Branch**. 480 | 481 | A ideia consiste em criar uma branch para cada nova funcionalidade a ser desenvolvida e cada pessoa do time deve trabalhar na branch específica de sua funcionalidade, sendo que após a funcionalidade ser concluída um merge dos commits deve ser realizado na branch `master`. 482 | 483 | Isso serve para manter a branch `master` estável, ou seja, ela nunca deverá ter funcionalidades incompletas, representando com isso um *estado seguro* que pode ir para produção a qualquer momento. Outra vantagem é permitir que as pessoas trabalhem em suas respectivas funcionalidades sem atrapalhar o trabalho das outras pessoas com seus commits. 484 | 485 | ### Trunk-Based 486 | 487 | Uma outra prática, diferente da feature-branch, consiste em não utilizar branches para cada nova funcionalidade a ser desenvolvida, mas sim sempre utilizar a branch principal, ou seja, a branch `master`. 488 | 489 | Essa prática ficou conhecida como **Trunk-Based**, sendo que `trunk` é o nome da branch principal no SVN, que é equivalente à branch `master` no Git. 490 | 491 | Nessa prática o foco é evitar a criação de branches, para que assim todos possam trabalhar juntos e serem forçados com isso a integrarem seus códigos a todo momento, para detectar e corrigir o quanto antes os possíveis problemas de integração que surgirem. 492 | 493 | Ao utilizar essa prática, todas as pessoas do time devem desenvolver suas funcionalidades na branch `master`, ou `trunk`, no caso do SVN, sempre realizando o processo de integração contínua, para antecipar problemas. 494 | 495 | O problema é que na branch master teremos código de funcionalidades incompletas misturado com o código das que já foram finalizadas, podendo com isso dificultar o trabalho de gerar um build para fazer deploy em produção, pois será necessário fazer algum tipo de tratamento para o trabalho ainda não concluído. Uma técnica utilizada para resolver esse problema é chamada de **Feature Toggle**. 496 | 497 | > **Feature Toggle?** 498 | > 499 | > Com certeza você já utilizou um interruptor para ligar uma lâmpada em algum cômodo de sua residência. Um interruptor de energia é algo bem simples de utilizar, pois possui apenas duas posições possíveis: ligado e desligado. 500 | > 501 | > Feature Toggle nada mais é do que uma técnica utilizada para se criar uma espécie de *interruptor*, mas ao invés de ligar/desligar uma lâmpada, ele serve para ativar/desativar uma funcionalidade em uma aplicação. 502 | > 503 | > Essa técnica pode ser utilizada para diversos objetivos, sendo um deles o de *esconder* as funcionalidades incompletas de uma aplicação, no caso do time estar trabalhando no modelo *trunk-based*. 504 | 505 | ## Feature-Branch vs. Trunk-Based 506 | 507 | Agora você deve estar se perguntando: Devo utilizar qual das duas práticas, feature-branch ou trunk-based? Qual delas é melhor? 508 | 509 | Na verdade não existe a melhor prática, pois ambas possuem vantagens e desvantagens, devendo você e seu time avaliar qual delas se encaixa melhor em seu contexto. 510 | 511 | Alguns especialistas renomados em desenvolvimento de software, como Martin Fowler, por exemplo, criticam a utilização de feature-branch, pais quando uma pessoa do time cria uma branch para desenvolver sua funcionalidade, ela está se **separando** da branch principal e do resto do time, podendo ficar bastante tempo sem integrar seu código. E já discutimos anteriormente que separar as pessoas em **silos** é algo ruim. 512 | 513 | Isso aumenta as chances de conflitos e dores de cabeça quando ela terminar sua funcionalidade e for integrar seu código com o código das outras pessoas, que também ficaram todo esse tempo trabalhando separadas. 514 | 515 | Mas essa crítica é bem antiga, da época em que ainda não existia o Git e o SVN era a principal ferramenta de controle de versão utilizada pelos times de desenvolvimento de software. 516 | 517 | Trabalhar com branches no SVN era bem difícil, pois uma branch era uma cópia completa do repositório, algo pouco performático. Além disso, naquela época não existia o termo DevOps e as pessoas não seguiam a prática de integração contínua. 518 | 519 | Ou seja, quando um time criava uma branch, ela costumava existir por muito tempo, geralmente meses, e ao realizar o merge com a branch principal, diversos conflitos e problemas aconteciam, forçando o time a parar seus trabalhos e focar na resolução desses problemas, algo que tomava muito tempo das pessoas. Com isso, criou-se uma cultura de medo e resistência à utilização de branches, pois elas eram traumáticas para as pessoas. 520 | 521 | Mas no Git isso é totalmente diferente, pois branches são simples e performáticas de se trabalhar, bem diferente das branches do SVN. 522 | 523 | Sendo assim, é totalmente possível de se trabalhar com branches no Git, no modelo de feature-branch, realizando o processo de integração contínua, para se evitar os pesadelos das traumáticas branches do SVN. 524 | 525 | A única recomendação é tentar manter o tempo de vida das branches curtas, dias ou poucas semanas, e orientar as pessoas do time a sempre sincronizarem seus repositório locais com o remoto, para não acumular commits quando o merge for realizado. Ou seja, evitar sincronizar apenas quando a funcionalidade for concluída. 526 | -------------------------------------------------------------------------------- /10-deploy-continuo.md: -------------------------------------------------------------------------------- 1 | # Deploy Contínuo 2 | 3 | Neste capítulo vamos aprender sobre Continuous Deployment(Deploy Contínuo) e entender sua diferença em relação ao Continuous Delivery, além de aprender a utilizar essa prática para levar o processo de automatização e entrega de software ao extremo, fazendo deploys a cada novo commit realizado. 4 | 5 | ## Continuous Deployment 6 | 7 | No capítulo anterior estudamos sobre continuous delivery e agora estudaremos sobre continuous deployment, que é mais uma prática relacionada com entrega de software. 8 | 9 | Mas se essa prática também está relacionada com entrega de software, qual é sua diferença em relação ao continuous delivery? 10 | 11 | A diferença está na **maneira** que a entrega do software é realizada. 12 | 13 | Enquanto no continuous delivery temos uma ferramenta com um *botão* para disparar o processo de entrega de software, ou seja, realizar o deploy de uma nova versão dele, no continuous deployment essa entrega é efetuada de maneira totalmente automatizada, sem a necessidade de intervenção de alguma pessoa para ser realizada. 14 | 15 | Ou seja, cada nova mudança realizada no software, ao ser registrada no controle de versão, vai disparar automaticamente o processo de deploy e realizar a entrega dele de maneira imediata, não havendo mais a necessidade de alguém ter de acessar uma ferramenta e apertar o *botão* que dispara o processo de deploy. 16 | 17 | Resumindo em termos técnicos, isso significa que cada novo commit realizado por alguma pessoa do time de desenvolvimento vai disparar automaticamente o processo de deploy, sendo que as alterações desse commit estarão disponíveis no ambiente de produção em questão de minutos. 18 | 19 | ## Vantagens e desvantagens do continuous deployment 20 | 21 | A grande vantagem de utilizar a prática de continuous deployment é o fato de que cada mudança registrada no controle de versão é imediatamente entregue e disponibilizada em ambiente de produção. 22 | 23 | Do ponto de vista das pessoas que vão utilizar o software isso é extremamente útil e vantajoso, pois elas terão acesso às novidades do software de maneira muito mais frequente e ágil, sem ter que esperar muito tempo por futuras releases. 24 | 25 | Principalmente para as pessoas que estão acostumadas a solicitar pequenos ajustes e melhorias e acabam tendo que esperar por ciclos muito longos, de semanas a meses, para receber tais mudanças entregues em produção, a prática de continuous deployment é vista com *bons olhos*, pois o time agora será capaz de entregar pequenas alterações para elas em questão de minutos ou horas. 26 | 27 | Uma desvantagem é que o time de desenvolvimento vai precisar se adaptar para utilizar essa prática, pois é comum que eles utilizem ciclos de desenvolvimento com frequência predefinida, sendo que a release, na teoria, costuma ser liberada apenas ao final de cada ciclo. 28 | 29 | Por exemplo, times que utilizam o Scrum como metodologia costumam ter ciclos, conhecidos como Sprints, que variam de uma a quatro semanas, sendo comum que eles estejam acostumados a realizarem a entrega do incremento do software apenas no final de cada Sprint. 30 | 31 | Outro problema é que o time de desenvolvimento precisa ter mais atenção ao realizar commits, pois cada commit vai disparar o processo de deploy, sendo que nem sempre um commit pode representar uma tarefa finalizada e com isso pode acontecer de existirem funcionalidades incompletas, ou até mesmo com bugs, em ambiente de produção. 32 | 33 | Nesse caso o time vai precisar separar de alguma maneira o trabalho finalizado do trabalho que está ainda em andamento, para evitar problemas em ambiente de produção. Existe uma prática utilizada para esse cenário, que ficou conhecida como **Feature Toggle**. 34 | 35 | ## Feature Toggle 36 | 37 | **Feature Toggle**, também conhecida como **Feature Flag**, é uma prática utilizada para controlar dinamicamente a liberação de funcionalidades em um software. A ideia consiste em ativar/desativar funcionalidades do software, podendo ser utilizada também para realizar testes de novas implementações de determinadas funcionalidades. 38 | 39 | Essa prática também pode ser utilizada com outros objetivos, além de controlar a release apenas das funcionalidades que estão concluídas, tais como: 40 | 41 | * Realização de testes A/B; 42 | * Validação de funcionalidades do ponto de vista de negócios; 43 | * Coletar métricas de impactos de performance de novas funcionalidades; 44 | * Desativar funcionalidades problemáticas; e 45 | * Release de funcionalidades seguindo o modelo de Canary Release. 46 | 47 | A implementação de feature toggles é feita diretamente no código do software, por exemplo de maneira simples utilizando `if/else`: 48 | 49 | ```java 50 | if (FeatureToggles.NOVA_VALIDACAO_TOPICO.isAtiva()) { 51 | return new ValidadorTopicoOtimizado(); 52 | } else { 53 | return new ValidadorTopico(); 54 | } 55 | ``` 56 | 57 | Repare que o código anterior faz uma verificação para saber qual validador de tópicos utilizar, sendo que no exemplo anterior existem duas diferentes versões dele. Com isso é possível controlar qual versão da funcionalidade será disponibilizada em produção para os usuários, ou até mesmo controlar qual versão determinado usuário vai ter acesso. 58 | 59 | Também é possível delegar essa liberação para alguma pessoa que seja administradora do sistema, criando para isso uma tela na qual ela poderá ativar/desativar determinadas funcionalidades, evitando assim que o código precise ser alterado pelo time de desenvolvimento. 60 | 61 | São inúmeras possibilidades de se utilizar feature toggles, além de inúmeras maneiras de se implementar tal prática no software, devendo o time de desenvolvimento fazer um alinhamento com a área de negócios sobre qual a melhor estratégia a ser utilizada. 62 | 63 | Entretanto, existe uma desvantagem de se utilizar feature toggles, que é o fato dessa prática aumentar a complexidade do software, visto que o time de desenvolvimento terá que implementar e dar manutenção também no código dos feature toggles em si, que, dependendo do tipo de implementação utilizada, pode ser bastante trabalhoso e complexo. 64 | 65 | ## Exercício: Continuous Deployment com Jenkins 66 | 67 | Nesse exercício vamos utilizar o Jenkins para realizar o processo de continuous deployment, disparando o processo de deploy de maneira automatizada a cada novo commit registrado no Git. 68 | 69 | 1. Acesse o Jenkins em: http://localhost:8082 70 | 71 | 2. Clique na opção **New Item**, localizado no menu lateral esquerdo, preencha o campo *item name* com **continuous deployment alura-forum**, na opção **Copy from** preencha com **deploy alura-forum** e clique no botão **Ok**. 72 | 73 | ![Tela de criação de novo item no Jenkins](imagens/capitulo-10/jenkins-copy-item.png) 74 | 75 | 3. Na seção **Build Triggers**, marque a opção **Poll SCM** e no campo **Schedule** preencha com: `* * * * *`. 76 | 77 | ![Build Triggers na tela de configuração de item no Jenkins](imagens/capitulo-08/jenkins-new-item-build-triggers.png) 78 | 79 | 4. Deixe as outras configurações conforme já estão preenchidas e clique no botão **Save**. 80 | 81 | 5. Efetue alguma alteração na aplicação, faça um commit para registrá-la e verifique no Jenkins se o processo de deploy foi disparado automaticamente. 82 | 83 | 6. Verifique também se o deploy foi realizado com sucesso, acessando a aplicação no browser em: http://localhost:8080/alura-forum 84 | -------------------------------------------------------------------------------- /11-monitoramento-continuo.md: -------------------------------------------------------------------------------- 1 | # Monitoramento Contínuo 2 | 3 | Neste capítulo vamos aprender sobre monitoramento de aplicações e como utilizar essa prática para detectar e antecipar possíveis problemas, contribuindo para uma maior agilidade na recuperação de falhas. 4 | 5 | ## O problema: Sistema fora do ar 6 | 7 | Nenhum sistema é à prova de falhas, sendo que problemas sempre poderão acontecer a qualquer momento. Entretanto, é comum que alguns times não tratem desse tópico com muita prioridade, o que pode ocasionar em sérios prejuízos para a organização. 8 | 9 | Sempre que uma aplicação fica indisponível a seus usuários, isso deve ser tratado como prioridade, e até com certa urgência, pois certamente esse fato pode ter interrompido e impactado o trabalho de diversas pessoas da organização, o que pode levar a enormes prejuízos. 10 | 11 | Já imaginou o impacto que uma indisponibilidade de várias horas de uma aplicação de internet banking pode causar à uma instituição financeira? 12 | 13 | Justamente por conta disso, algumas empresas estabelecem que a *disponibilidade* de uma aplicação é um dos fatores mais críticos e impactantes para a organização. 14 | 15 | Entretanto, não devemos nos preocupar com disponibilidade apenas nesses casos mais críticos, mas sim considerar que esse tópico é sempre importante, independente do tipo de aplicação, devendo o time DevOps discutir e pensar na melhor maneira possível de lidar com ele. 16 | 17 | Mas o foco não deve ser em como evitar que as aplicações fiquem indisponíveis a qualquer custo, pois isso é algo praticamente impossível, já que sempre estaremos sujeitos a falhas humanas e técnicas. Inclusive, grandes empresas de tecnologia como Google, Microsoft e Facebook, costumam ter indisponibilidade em seus produtos, algo que é raro de acontecer, mas não impossível. 18 | 19 | O foco deve ser em como lidar com indisponibilidade, bem como quaisquer outros problemas que possam acontecer com as aplicações e sua infraestrutura, e, principalmente, como descobrir rapidamente qual foi o problema que ocorreu, sua causa raiz, como corrigi-lo e como fazer para evitar que tal problema volte a acontecer no futuro. 20 | 21 | Esse é a melhor abordagem para lidar com o tema, além de também ser um grande desafio para muitos times DevOps que não tem conhecimento e experiência no assunto. 22 | 23 | ## A má prática: Apagar incêndios 24 | 25 | No mercado é bastante comum encontrar times que não sabem muito bem a melhor forma de lidar com problemas em aplicações e sua infraestrutura, sendo que eles acabam atuando como *bombeiros*, apenas *apagando os incêndios* que vão surgindo, sem de fato corrigir o problema para que um novo incêndio volte a ocorrer. 26 | 27 | Um exemplo dessa situação acontece quando uma aplicação está fora do ar e o time de Ops, ao analisar rapidamente o que pode ter acontecido, detecta que o servidor de aplicações caiu por algum motivo, o reiniciando. A aplicação voltará a funcionar após o servidor reiniciar, resolvendo assim a indisponibilidade, porém o problema não foi de fato resolvido, sendo comum que após algum tempo o servidor volte a cair. 28 | 29 | Existem organizações nas quais esse problema é pior ainda, pois o time de Ops não realiza nenhum tipo de monitoramento, não tendo nenhum tipo de controle sobre quais aplicações estão online e quais não, sendo comum que os próprios usuários precisem o avisar quando problemas acontecem e aplicações estão fora do ar. 30 | 31 | Esses são alguns exemplos de más práticas para lidar com problemas e indisponibilidade de aplicações, as quais os times DevOps devem evitar ao máximo, pois isso é considerado um dos principais motivos pela má fama da área de tecnologia, que, aos olhos das outras áreas da organização, está sempre causando problemas e nunca consegue os resolver de maneira definitiva. 32 | 33 | Inclusive esse é um dos principais motivos que levou a famosa rixa entre os times de Dev e Ops nas organizações, pois quando um problema ocorria um time empurrava a responsabilidade ao outro e vice-versa. 34 | 35 | ## A solução: Monitoramento Contínuo 36 | 37 | Os problemas citados anteriormente são bem comuns na grande maioria das empresas, pois muitos times não tem a preocupação do *pós-deploy*, ou seja, a partir do momento que uma aplicação é colocada em produção, considera-se como missão cumprida e o foco passa a ser em outras aplicações ou apenas em ajustes e correções de bugs. 38 | 39 | Mas o deploy não deveria ser considerado como *linha de chegada* e encerramento do ciclo, pois muito trabalho ainda pode ser necessário após esse marco. 40 | 41 | Uma das atividades importantes que o time de Ops, e também o time de Dev, deveria dar bastante atenção é o **monitoramento** da aplicação, para assim acompanhar como ela está se comportando no ambiente de produção, detectando previamente possíveis gargalos e problemas que precisam de atenção. Dessa maneira o time DevOps seria capaz, por exemplo, de agir antes de um problema *estourar*, evitando que o problema piore e a aplicação fique indisponível aos seus usuários. 42 | 43 | Monitoramento é mais uma das atividades que são consideradas extremamente importantes, principalmente em ambientes DevOps, pois além de buscar por mais agilidade e eficiência no processo de desenvolvimento da aplicação, também é importante ter agilidade e eficiência na detecção, correção e recuperação de falhas, que sempre podem acontecer a qualquer momento. 44 | 45 | A grande questão é que a atividade de monitoramento não deve ser realizada apenas uma única vez, por exemplo após o deploy ser realizado, e nem tampouco apenas quando problemas acontecerem. Monitoramento deve ser realizado de maneira **contínua**, da mesma forma que devemos integrar o código continuamente. 46 | 47 | Isso foi justamente o que motivou o surgimento de um termo conhecido como **Monitoramento Contínuo**, para demonstrar a necessidade dessa prática ser realizada de maneira constante pelo time DevOps, em especial o time de Ops, que geralmente é o time que acaba assumindo essa responsabilidade. 48 | 49 | A prática de monitoramento contínuo consiste em fazer um acompanhamento, contínuo e em tempo real, de como a aplicação está se comportando no ambiente de produção, em especial referente ao consumo dos recursos de hardware, como CPU, memória e disco. 50 | 51 | Isso permite ao time identificar se os recursos de hardware estão de acordo com o exigido pela aplicação, além de também permitir encontrar padrões de utilização de tais recursos e detectar quando há um uso fora desses padrões, que podem levar a possíveis problemas. 52 | 53 | Claro, isso deve ser feito com a utilização de ferramentas, que conseguem automatizar todo esse trabalho e exibir tais informações de maneira simplificada, com gráficos e dashboards bem elaborados, que agilizam na análise das informações e tomada de decisões. 54 | 55 | ![Exemplo de dashboard de uma ferramenta de monitoramento](imagens/capitulo-11/dashboard.jpg) 56 | 57 | ## Ferramentas de monitoramento 58 | 59 | No mercado existem diversas ferramentas de monitoramento, sendo algumas gratuitas e outras pagas. Não tem certo ou errado aqui, cada ferramenta tem suas vantagens e desvantagens, sendo que o time deve escolher as que fizerem mais sentido e atenderem às suas necessidades. 60 | 61 | Estas são algumas das principais ferramentas para monitoramento de infraestrutura e aplicações, que atualmente são utilizadas por times DevOps ao redor do mundo: 62 | 63 | * Nagios 64 | * Zabbix 65 | * Graylog 66 | * Prometheus 67 | * Grafana 68 | * InfluxDB 69 | * ELK Stack 70 | * Sensu 71 | * Glowroot 72 | 73 | A lista anterior apresenta apenas algumas das ferramentas de monitoramento existentes no mercado, sendo que existem dezenas de outras ferramentas disponíveis que não foram listadas, e serve apenas como uma sugestão de ferramentas que você e seu time DevOps podem pesquisar e estudar mais a respeito, escolhendo apenas as que forem mais relevantes para o seu contexto. 74 | 75 | Há também algumas ferramentas que funcionam como serviços Web, principalmente focadas em encontrar gargalos de performance em aplicações. Dentre elas temos: *NewRelic* e *Datadog*, que também recomendamos avaliar. 76 | 77 | Embora a prática de monitoramento seja mais uma preocupação do time de Ops do que do time de Dev, recomendamos que esse processo de análise, testes e escolha das ferramentas seja realizado em conjunto por ambos os times, para que assim se tenha uma visão tanto a nível de aplicação, quanto a nível de infraestrutura, e o time todo possa colaborar na decisão de quais ferramentas utilizar e também em como as utilizar da melhor maneira possível. 78 | 79 | ### Alertas e integrações 80 | 81 | Embora a recomendação seja para que a prática de monitoramento ocorra de maneira contínua, isso não significa que alguma pessoa do time precise estar 24h por dia observando os gráficos e dashboards das ferramentas. Isso seria um trabalho manual, chato e muito cansativo, além de também ser um desperdício de talento. 82 | 83 | O recomendado é configurar **alertas** de monitoramento nas ferramentas, para que caso algo de incomum aconteça, as pessoas responsáveis sejam notificadas o quanto antes. Geralmente essas ferramentas de monitoramento possuem configurações de alertas, que podem ser utilizadas pelo time para disparar notificações de acordo com parâmetros predefinidos. 84 | 85 | Uma outra coisa importante é que hoje em dia tais notificações podem ser feitas de diversas maneiras, com integrações a outros serviços, como Slack, WhatsApp, SMS, etc., bem melhor do que apenas por e-mail, como costumava ser antigamente. 86 | 87 | ## O que devemos monitorar? 88 | 89 | Monitoramento contínuo é uma prática muito importante para um time DevOps, entretanto vale ressaltar que nem tudo que é *monitorável* deve ser monitorado. Isso porque existem dezenas de informações que podem ser monitoradas em relação às aplicações e suas infraestruturas, porém muitas delas podem não ser tão relevantes. 90 | 91 | Sendo assim, o time deve avaliar quais os tipos de informações que são essenciais e mais críticos para cada aplicação, fazendo assim um melhor planejamento da estratégia de monitoramento a ser adotada. 92 | 93 | Uma dica é analisar quais são os *requisitos não funcionais* mais críticos da aplicação, tais como: performance, escalabilidade, disponibilidade, etc., pois a partir daí o time terá uma boa visão de quais informações devem ser monitoradas e quais não são tão críticas. 94 | 95 | Existem algumas categorias de monitoramento, das quais podemos classificar e agrupar os itens a serem monitorados. Dependendo do contexto, algumas delas podem ter muita, pouca ou até mesmo nenhuma relevância, devendo todo o time analisar e discutir sobre isso. 96 | 97 | Dentre as principais categorias listamos: 98 | 99 | * **Server Health**: Essa é principal e mais óbvia categoria, pois aqui se encontram os itens referentes a infraestrutura, tais como: CPU, memória, espaço em disco, tempo médio de requisições, disponibilidade dos serviços, etc. 100 | * **Logs**: Aqui o foco é no monitoramento dos logs gerados pelos servidores e aplicações, afim de detectar possíveis problemas que merecem atenção e uma melhor análise. 101 | * **Deploys**: Aqui o foco é monitorar o importante processo de deploy da aplicação, afim de detectar problemas que possam acontecer em qualquer uma de suas etapas. 102 | * **Segurança**: Aqui a ideia é monitorar itens relacionados à segurança da aplicação e de sua infraestrutura, tais como: tentativas de intrusão, detecção de scripts maliciosos, vulnerabilidades, etc. 103 | 104 | ## Monitoramento de negócios 105 | 106 | Além de monitorar informações técnicas da aplicação e sua infraestrutura, é extremamente importante também definir aspectos de negócios que também poderiam ser monitorados, gerando com isso mais valor para as pessoas da área de negócios que estejam envolvidas com o produto. 107 | 108 | Nesse caso, é essencial que o time DevOps colabore juntamente com o time de business da organização, para que todos consigam identificar informações de negócios que tem muito valor e deveriam também estar no leque dos itens a serem monitorados. 109 | 110 | Isso é algo muito útil para uma organização como um todo, embora não seja muito comum de encontrar times que o façam, pois geralmente monitoramento é restrito apenas a itens técnicos. 111 | 112 | Para facilitar o entendimento sobre monitoramento de negócios, vamos a um exemplo utilizando nossa aplicação, o fórum de dúvidas da Alura, como base. Pensando do ponto de vista de negócios, a seguir listamos algumas informações que podem ser consideradas como importantes e relevantes para serem monitoradas: 113 | 114 | * **Número de tópicos abertos por curso**: Para identificar gargalos de tópicos sendo abertos para um determinado curso, ou até mesmo uma situação incomum de nenhum tópico aberto a determinado tempo para o curso. 115 | * **Número de tópicos abertos por categoria**: Para identificar gargalos de tópicos sendo abertos para uma determinada categoria, ou até mesmo uma situação incomum de nenhum tópico aberto a determinado tempo para a categoria. 116 | * **Número de tópicos sem resposta**: Para identificar alunos(as) com tópicos não respondidos no fórum, o que poderia levar a uma insatisfação com a plataforma. 117 | * **Número de tópicos não solucionados**: Para identificar tópicos que mesmo possuindo respostas ainda não foram solucionados, o que poderia levar a uma insatisfação com a plataforma. 118 | 119 | Os exemplos citados acima poderiam ser relatórios disponibilizados como funcionalidades na própria aplicação, entretanto relatórios dependem que alguém os acessem e realizem uma analise das informações, algo que pode ser trabalhoso, chato e sujeito a erros humanos. 120 | 121 | Ao monitorar na aplicação tais informações, estamos automatizando o processo de coleta e analise delas, sem depender da necessidade de uma pessoa ter que interagir com a aplicação, além de que também é possível configurar alertas para serem disparados quando tais informações chegarem a um número considerado como crítico, para que assim alguém possa de imediato tomar uma ação. 122 | 123 | Essa é justamente a grande vantagem de se realizar monitoramento contínuo de negócios, além do técnico, visando em gerar mais valor para o produto, para a organização e também para seus clientes. 124 | 125 | ## Exercício: Monitoramento com Glowroot 126 | 127 | Nesse exercício vamos praticar o monitoramento de aplicações utilizando a ferramenta Glowroot, que é um dos APM(Application Performance Management) gratuitos mais populares utilizados em aplicações Java. 128 | 129 | 1. Altere o arquivo `Vagrantfile` para configurar o mapeamento da porta **4000**, porta padrão utilizada pelo Glowroot, entre a VM **alura-web** e o host: 130 | 131 | ``` 132 | web.vm.network "forwarded_port", guest: 4000, host: 4000 133 | ``` 134 | 135 | 2. Ainda no arquivo `Vagrantfile`, precisaremos adicionar mais dois passos no processo de criação da VM **alura-web**, para copiar para ela o `Glowroot` e seu arquivo de configurações. Adicione as seguintes linhas **antes** da linha que executa o shell de `post-install`: 136 | 137 | ``` 138 | web.vm.provision "file", source: "vagrant/web/glowroot.zip", destination: "/tmp/glowroot.zip" 139 | web.vm.provision "file", source: "vagrant/web/admin.json", destination: "/tmp/admin.json" 140 | ``` 141 | 142 | Confira se seu arquivo `Vagrantfile` está preenchido corretamente: 143 | 144 | ``` 145 | Vagrant.configure("2") do |config| 146 | 147 | config.vm.define "alura-database" do |db| 148 | db.vm.box = "ubuntu/bionic64" 149 | 150 | db.vm.network "private_network", ip: "192.168.56.110" 151 | db.vm.network "forwarded_port", guest: 3306, host: 3307 152 | 153 | db.vm.provision "shell", path: "vagrant/database/install.sh" 154 | db.vm.provision "file", source: "vagrant/database/mysqld.cnf", destination: "/tmp/mysqld.cnf" 155 | db.vm.provision "file", source: "vagrant/database/script-inicial.sql", destination: "/tmp/script-inicial.sql" 156 | db.vm.provision "shell", path: "vagrant/database/post-install.sh" 157 | end 158 | 159 | config.vm.define "alura-web" do |web| 160 | web.vm.box = "ubuntu/bionic64" 161 | 162 | web.vm.network "private_network", ip: "192.168.56.105" 163 | web.vm.network "forwarded_port", guest: 8080, host: 8080 164 | web.vm.network "forwarded_port", guest: 4000, host: 4000 165 | 166 | web.vm.provision "shell", path: "vagrant/web/install.sh" 167 | web.vm.provision "file", source: "vagrant/web/apache-tomcat-8.5.47.tar.gz", destination: "/tmp/apache-tomcat-8.5.47.tar.gz" 168 | web.vm.provision "file", source: "vagrant/web/tomcat.service", destination: "/tmp/tomcat.service" 169 | web.vm.provision "file", source: "target/alura-forum-0.0.1-SNAPSHOT.war", destination: "/tmp/alura-forum.war" 170 | web.vm.provision "file", source: "vagrant/web/glowroot.zip", destination: "/tmp/glowroot.zip" 171 | web.vm.provision "file", source: "vagrant/web/admin.json", destination: "/tmp/admin.json" 172 | web.vm.provision "shell", path: "vagrant/web/post-install.sh" 173 | end 174 | 175 | end 176 | ``` 177 | 178 | 3. Precisaremos instalar o programa `unzip` na VM. Altere o arquivo **install.sh** adicionando ao final dele a seguinte linha: 179 | 180 | ``` 181 | sudo apt-get install -y unzip 182 | ``` 183 | 184 | 4. Agora no arquivo **post-install.sh**, adicione as seguintes linhas logo após a linha que configura a cópia do `war` da aplicação: 185 | 186 | ``` 187 | sudo mv /tmp/glowroot.zip /opt/glowroot.zip 188 | sudo unzip /opt/glowroot.zip -d /opt 189 | sudo rm /opt/glowroot.zip 190 | sudo mv /tmp/admin.json /opt/glowroot/admin.json 191 | sudo chgrp -R tomcat /opt/glowroot 192 | sudo chown -R tomcat /opt/glowroot 193 | ``` 194 | 195 | Confira se seu arquivo `post-install.sh` está preenchido corretamente: 196 | 197 | ``` 198 | sudo useradd -r -m -U -d /opt/tomcat -s /bin/false tomcat 199 | 200 | sudo tar xf /tmp/apache-tomcat-8.5.47.tar.gz -C /opt/tomcat 201 | sudo mv /opt/tomcat/apache-tomcat-8.5.47 /opt/tomcat/tomcat8 202 | sudo mv /tmp/tomcat.service /etc/systemd/system 203 | sudo mv /tmp/alura-forum.war /opt/tomcat/tomcat8/webapps 204 | 205 | sudo mv /tmp/glowroot.zip /opt/glowroot.zip 206 | sudo unzip /opt/glowroot.zip -d /opt 207 | sudo rm /opt/glowroot.zip 208 | sudo mv /tmp/admin.json /opt/glowroot/admin.json 209 | sudo chgrp -R tomcat /opt/glowroot 210 | sudo chown -R tomcat /opt/glowroot 211 | 212 | sudo ufw allow 8080 213 | sudo chgrp -R tomcat /opt/tomcat 214 | sudo chown -R tomcat /opt/tomcat 215 | 216 | sudo systemctl daemon-reload 217 | sudo systemctl start tomcat 218 | sudo systemctl enable tomcat 219 | ``` 220 | 221 | 5. Por fim, altere no arquivo **tomcat.service** a seguinte linha, para adicionar o monitoramento via Glowroot: 222 | 223 | ``` 224 | Environment="CATALINA_OPTS=-Xms384M -Xmx384M -javaagent:/opt/glowroot/glowroot.jar" 225 | ``` 226 | 227 | 6. Realize um deploy da aplicação, utilizando o `item` **Deploy alura-forum** no Jenkins, e após o processo ser finalizado acesse o Glowroot pelo browser em: http://localhost:4000. 228 | 229 | 7. Para que o Glowroot exiba as informações de monitoramento é necessário disparar algumas requisições pela aplicação. Acesse a aplicação em: http://localhost:8080/alura-forum e navegue por suas funcionalidades, para que assim o Glowroot comece a coletar dados e exibir em sua interface. 230 | 231 | 8. Após disparar diversas requisições pela aplicação, acesse novamente o Glowroot e explore sua interface e as informações que ele disponibiliza. 232 | 233 | ## Métrica: Mean Time To Recover 234 | 235 | **Mean Time To Recover** é a última das quatro principais métricas DevOps, que ainda não havia sido discutida até então no curso, sendo que seu objetivo é medir o **tempo médio de recuperação** que um time leva para se recuperar de falhas. Essa métrica também é muito importante, pois demonstra a eficiência e agilidade de um time quando falhas ocorrem. 236 | 237 | Já discutimos aqui nesse capítulo que falhas são inevitáveis, sendo que o time deve assumir que uma hora ou outra elas vão acontecer, e por isso é tão importante realizar a prática de monitoramento contínuo, além de também estar preparado para quando elas acontecerem. 238 | 239 | Em ambientes tradicionais é comum encontrar times que têm dificuldades de detectar quando falhas ocorrem, de descobrir o que as ocasionou e também dificuldades em se recuperar delas, aumentando com isso o tempo médio de recuperação. 240 | 241 | Nos casos mais tensos é comum encontrar times que levam até semanas para se recuperar por completo de uma falha. Imagine o impacto para a organização em ter uma indisponibilidade dessas. 242 | 243 | O ideal é que o time leve poucas horas, no máximo 1 dia, para se recuperar de falhas, pois assim os impactos serão minimizados. Claro, isso é algo bem difícil de se alcançar, mas ao utilizar a prática de monitoramento contínuo se torna mais fácil. 244 | 245 | A recomendação aqui é para que o time colete essa métrica desde o início do processo de adoção ao DevOps, analisando sua evolução e utilizando práticas para diminuir seu valor com o passar do tempo. 246 | -------------------------------------------------------------------------------- /LICENSE.MD: -------------------------------------------------------------------------------- 1 | Attribution-NonCommercial-NoDerivatives 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More_considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 58 | International Public License 59 | 60 | By exercising the Licensed Rights (defined below), You accept and agree 61 | to be bound by the terms and conditions of this Creative Commons 62 | Attribution-NonCommercial-NoDerivatives 4.0 International Public 63 | License ("Public License"). To the extent this Public License may be 64 | interpreted as a contract, You are granted the Licensed Rights in 65 | consideration of Your acceptance of these terms and conditions, and the 66 | Licensor grants You such rights in consideration of benefits the 67 | Licensor receives from making the Licensed Material available under 68 | these terms and conditions. 69 | 70 | 71 | Section 1 -- Definitions. 72 | 73 | a. Adapted Material means material subject to Copyright and Similar 74 | Rights that is derived from or based upon the Licensed Material 75 | and in which the Licensed Material is translated, altered, 76 | arranged, transformed, or otherwise modified in a manner requiring 77 | permission under the Copyright and Similar Rights held by the 78 | Licensor. For purposes of this Public License, where the Licensed 79 | Material is a musical work, performance, or sound recording, 80 | Adapted Material is always produced where the Licensed Material is 81 | synched in timed relation with a moving image. 82 | 83 | b. Copyright and Similar Rights means copyright and/or similar rights 84 | closely related to copyright including, without limitation, 85 | performance, broadcast, sound recording, and Sui Generis Database 86 | Rights, without regard to how the rights are labeled or 87 | categorized. For purposes of this Public License, the rights 88 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 89 | Rights. 90 | 91 | c. Effective Technological Measures means those measures that, in the 92 | absence of proper authority, may not be circumvented under laws 93 | fulfilling obligations under Article 11 of the WIPO Copyright 94 | Treaty adopted on December 20, 1996, and/or similar international 95 | agreements. 96 | 97 | d. Exceptions and Limitations means fair use, fair dealing, and/or 98 | any other exception or limitation to Copyright and Similar Rights 99 | that applies to Your use of the Licensed Material. 100 | 101 | e. Licensed Material means the artistic or literary work, database, 102 | or other material to which the Licensor applied this Public 103 | License. 104 | 105 | f. Licensed Rights means the rights granted to You subject to the 106 | terms and conditions of this Public License, which are limited to 107 | all Copyright and Similar Rights that apply to Your use of the 108 | Licensed Material and that the Licensor has authority to license. 109 | 110 | g. Licensor means the individual(s) or entity(ies) granting rights 111 | under this Public License. 112 | 113 | h. NonCommercial means not primarily intended for or directed towards 114 | commercial advantage or monetary compensation. For purposes of 115 | this Public License, the exchange of the Licensed Material for 116 | other material subject to Copyright and Similar Rights by digital 117 | file-sharing or similar means is NonCommercial provided there is 118 | no payment of monetary compensation in connection with the 119 | exchange. 120 | 121 | i. Share means to provide material to the public by any means or 122 | process that requires permission under the Licensed Rights, such 123 | as reproduction, public display, public performance, distribution, 124 | dissemination, communication, or importation, and to make material 125 | available to the public including in ways that members of the 126 | public may access the material from a place and at a time 127 | individually chosen by them. 128 | 129 | j. Sui Generis Database Rights means rights other than copyright 130 | resulting from Directive 96/9/EC of the European Parliament and of 131 | the Council of 11 March 1996 on the legal protection of databases, 132 | as amended and/or succeeded, as well as other essentially 133 | equivalent rights anywhere in the world. 134 | 135 | k. You means the individual or entity exercising the Licensed Rights 136 | under this Public License. Your has a corresponding meaning. 137 | 138 | 139 | Section 2 -- Scope. 140 | 141 | a. License grant. 142 | 143 | 1. Subject to the terms and conditions of this Public License, 144 | the Licensor hereby grants You a worldwide, royalty-free, 145 | non-sublicensable, non-exclusive, irrevocable license to 146 | exercise the Licensed Rights in the Licensed Material to: 147 | 148 | a. reproduce and Share the Licensed Material, in whole or 149 | in part, for NonCommercial purposes only; and 150 | 151 | b. produce and reproduce, but not Share, Adapted Material 152 | for NonCommercial purposes only. 153 | 154 | 2. Exceptions and Limitations. For the avoidance of doubt, where 155 | Exceptions and Limitations apply to Your use, this Public 156 | License does not apply, and You do not need to comply with 157 | its terms and conditions. 158 | 159 | 3. Term. The term of this Public License is specified in Section 160 | 6(a). 161 | 162 | 4. Media and formats; technical modifications allowed. The 163 | Licensor authorizes You to exercise the Licensed Rights in 164 | all media and formats whether now known or hereafter created, 165 | and to make technical modifications necessary to do so. The 166 | Licensor waives and/or agrees not to assert any right or 167 | authority to forbid You from making technical modifications 168 | necessary to exercise the Licensed Rights, including 169 | technical modifications necessary to circumvent Effective 170 | Technological Measures. For purposes of this Public License, 171 | simply making modifications authorized by this Section 2(a) 172 | (4) never produces Adapted Material. 173 | 174 | 5. Downstream recipients. 175 | 176 | a. Offer from the Licensor -- Licensed Material. Every 177 | recipient of the Licensed Material automatically 178 | receives an offer from the Licensor to exercise the 179 | Licensed Rights under the terms and conditions of this 180 | Public License. 181 | 182 | b. No downstream restrictions. You may not offer or impose 183 | any additional or different terms or conditions on, or 184 | apply any Effective Technological Measures to, the 185 | Licensed Material if doing so restricts exercise of the 186 | Licensed Rights by any recipient of the Licensed 187 | Material. 188 | 189 | 6. No endorsement. Nothing in this Public License constitutes or 190 | may be construed as permission to assert or imply that You 191 | are, or that Your use of the Licensed Material is, connected 192 | with, or sponsored, endorsed, or granted official status by, 193 | the Licensor or others designated to receive attribution as 194 | provided in Section 3(a)(1)(A)(i). 195 | 196 | b. Other rights. 197 | 198 | 1. Moral rights, such as the right of integrity, are not 199 | licensed under this Public License, nor are publicity, 200 | privacy, and/or other similar personality rights; however, to 201 | the extent possible, the Licensor waives and/or agrees not to 202 | assert any such rights held by the Licensor to the limited 203 | extent necessary to allow You to exercise the Licensed 204 | Rights, but not otherwise. 205 | 206 | 2. Patent and trademark rights are not licensed under this 207 | Public License. 208 | 209 | 3. To the extent possible, the Licensor waives any right to 210 | collect royalties from You for the exercise of the Licensed 211 | Rights, whether directly or through a collecting society 212 | under any voluntary or waivable statutory or compulsory 213 | licensing scheme. In all other cases the Licensor expressly 214 | reserves any right to collect such royalties, including when 215 | the Licensed Material is used other than for NonCommercial 216 | purposes. 217 | 218 | 219 | Section 3 -- License Conditions. 220 | 221 | Your exercise of the Licensed Rights is expressly made subject to the 222 | following conditions. 223 | 224 | a. Attribution. 225 | 226 | 1. If You Share the Licensed Material, You must: 227 | 228 | a. retain the following if it is supplied by the Licensor 229 | with the Licensed Material: 230 | 231 | i. identification of the creator(s) of the Licensed 232 | Material and any others designated to receive 233 | attribution, in any reasonable manner requested by 234 | the Licensor (including by pseudonym if 235 | designated); 236 | 237 | ii. a copyright notice; 238 | 239 | iii. a notice that refers to this Public License; 240 | 241 | iv. a notice that refers to the disclaimer of 242 | warranties; 243 | 244 | v. a URI or hyperlink to the Licensed Material to the 245 | extent reasonably practicable; 246 | 247 | b. indicate if You modified the Licensed Material and 248 | retain an indication of any previous modifications; and 249 | 250 | c. indicate the Licensed Material is licensed under this 251 | Public License, and include the text of, or the URI or 252 | hyperlink to, this Public License. 253 | 254 | For the avoidance of doubt, You do not have permission under 255 | this Public License to Share Adapted Material. 256 | 257 | 2. You may satisfy the conditions in Section 3(a)(1) in any 258 | reasonable manner based on the medium, means, and context in 259 | which You Share the Licensed Material. For example, it may be 260 | reasonable to satisfy the conditions by providing a URI or 261 | hyperlink to a resource that includes the required 262 | information. 263 | 264 | 3. If requested by the Licensor, You must remove any of the 265 | information required by Section 3(a)(1)(A) to the extent 266 | reasonably practicable. 267 | 268 | 269 | Section 4 -- Sui Generis Database Rights. 270 | 271 | Where the Licensed Rights include Sui Generis Database Rights that 272 | apply to Your use of the Licensed Material: 273 | 274 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 275 | to extract, reuse, reproduce, and Share all or a substantial 276 | portion of the contents of the database for NonCommercial purposes 277 | only and provided You do not Share Adapted Material; 278 | 279 | b. if You include all or a substantial portion of the database 280 | contents in a database in which You have Sui Generis Database 281 | Rights, then the database in which You have Sui Generis Database 282 | Rights (but not its individual contents) is Adapted Material; and 283 | 284 | c. You must comply with the conditions in Section 3(a) if You Share 285 | all or a substantial portion of the contents of the database. 286 | 287 | For the avoidance of doubt, this Section 4 supplements and does not 288 | replace Your obligations under this Public License where the Licensed 289 | Rights include other Copyright and Similar Rights. 290 | 291 | 292 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 293 | 294 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 295 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 296 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 297 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 298 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 299 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 300 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 301 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 302 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 303 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 304 | 305 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 306 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 307 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 308 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 309 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 310 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 311 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 312 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 313 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 314 | 315 | c. The disclaimer of warranties and limitation of liability provided 316 | above shall be interpreted in a manner that, to the extent 317 | possible, most closely approximates an absolute disclaimer and 318 | waiver of all liability. 319 | 320 | 321 | Section 6 -- Term and Termination. 322 | 323 | a. This Public License applies for the term of the Copyright and 324 | Similar Rights licensed here. However, if You fail to comply with 325 | this Public License, then Your rights under this Public License 326 | terminate automatically. 327 | 328 | b. Where Your right to use the Licensed Material has terminated under 329 | Section 6(a), it reinstates: 330 | 331 | 1. automatically as of the date the violation is cured, provided 332 | it is cured within 30 days of Your discovery of the 333 | violation; or 334 | 335 | 2. upon express reinstatement by the Licensor. 336 | 337 | For the avoidance of doubt, this Section 6(b) does not affect any 338 | right the Licensor may have to seek remedies for Your violations 339 | of this Public License. 340 | 341 | c. For the avoidance of doubt, the Licensor may also offer the 342 | Licensed Material under separate terms or conditions or stop 343 | distributing the Licensed Material at any time; however, doing so 344 | will not terminate this Public License. 345 | 346 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 347 | License. 348 | 349 | 350 | Section 7 -- Other Terms and Conditions. 351 | 352 | a. The Licensor shall not be bound by any additional or different 353 | terms or conditions communicated by You unless expressly agreed. 354 | 355 | b. Any arrangements, understandings, or agreements regarding the 356 | Licensed Material not stated herein are separate from and 357 | independent of the terms and conditions of this Public License. 358 | 359 | 360 | Section 8 -- Interpretation. 361 | 362 | a. For the avoidance of doubt, this Public License does not, and 363 | shall not be interpreted to, reduce, limit, restrict, or impose 364 | conditions on any use of the Licensed Material that could lawfully 365 | be made without permission under this Public License. 366 | 367 | b. To the extent possible, if any provision of this Public License is 368 | deemed unenforceable, it shall be automatically reformed to the 369 | minimum extent necessary to make it enforceable. If the provision 370 | cannot be reformed, it shall be severed from this Public License 371 | without affecting the enforceability of the remaining terms and 372 | conditions. 373 | 374 | c. No term or condition of this Public License will be waived and no 375 | failure to comply consented to unless expressly agreed to by the 376 | Licensor. 377 | 378 | d. Nothing in this Public License constitutes or may be interpreted 379 | as a limitation upon, or waiver of, any privileges and immunities 380 | that apply to the Licensor or You, including from the legal 381 | processes of any jurisdiction or authority. 382 | 383 | ======================================================================= 384 | 385 | Creative Commons is not a party to its public licenses. 386 | Notwithstanding, Creative Commons may elect to apply one of its public 387 | licenses to material it publishes and in those instances will be 388 | considered the "Licensor." Except for the limited purpose of indicating 389 | that material is shared under a Creative Commons public license or as 390 | otherwise permitted by the Creative Commons policies published at 391 | creativecommons.org/policies, Creative Commons does not authorize the 392 | use of the trademark "Creative Commons" or any other trademark or logo 393 | of Creative Commons without its prior written consent including, 394 | without limitation, in connection with any unauthorized modifications 395 | to any of its public licenses or any other arrangements, 396 | understandings, or agreements concerning use of licensed material. For 397 | the avoidance of doubt, this paragraph does not form part of the public 398 | licenses. 399 | 400 | Creative Commons may be contacted at creativecommons.org. 401 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Apostila do curso de DevOps da Caelum 2 | 3 | ## Ementa: 4 | 5 | Sobre o Curso 6 | 1. DevOps 7 | 2. O curso 8 | 3. Código fonte 9 | 4. Bibliografia complementar 10 | 11 | DevOps 12 | 1. O que é DevOps? 13 | 2. A história do desenvolvimento de software 14 | 3. A história do DevOps 15 | 4. DevOps Anti-Patterns 16 | 5. A cultura em um ambiente DevOps 17 | 5. CALMS 18 | 6. Mudanças culturais para adotar DevOps 19 | 7. The Three Ways 20 | 8. O papel das ferramentas em um ambiente DevOps 21 | 22 | Lean 23 | 1. O que é Lean 24 | 2. Exercício: Lean Lego Game 25 | 3. Sobre Lean: o método Toyota 26 | 4. Push vs. Pull Systems 27 | 5. Kanban 28 | 6. Systems Thinking 29 | 7. Work Cells 30 | 8. Kaizen 31 | 9. Lean e DevOps 32 | 33 | O projeto do curso 34 | 1. Alura Fórum: o fórum da plataforma Alura 35 | 2. As funcionalidades da aplicação 36 | 3. Como rodar a aplicação? 37 | 4. Código fonte do projeto 38 | 5. Exercício: download do código fonte da aplicação 39 | 6. Build do projeto 40 | 7. Exercício: build manual da aplicação 41 | 8. Deploy do projeto 42 | 9. Exercício: deploy manual da aplicação 43 | 44 | Build automatizado 45 | 1. Build 46 | 2. Os problemas do build manual 47 | 3. Automatização do processo de build 48 | 4. Build tools 49 | 5. Automatizando o build do fórum da Alura 50 | 6. Exercício: Adicionando o Maven ao projeto 51 | 7. Exercício: Isolando os datasources com profiles 52 | 8. Realizando o build automatizado com Maven 53 | 9. Exercício: Gerando o build automatizado do projeto 54 | 55 | Controle de Versão 56 | 1. Backup e colaboração 57 | 2. Sistemas de Controle de Versão 58 | 3. Git 59 | 4. Utilizando o Git 60 | 5. Exercício: Utilizando o Git na aplicação 61 | 6. Mais detalhes do Git 62 | 7. Hospedando o repositório no GitLab 63 | 8. Exercício(opcional): Criando uma conta no GitLab 64 | 9. Exercício: Criando um repositório no GitLab 65 | 10. Sincronizando o repositório local com o GitLab 66 | 11. Exercício: Enviando os commits para o repositório remoto 67 | 12. Clonando um repositório já existente 68 | 13. Exercício: Renomeando o repositório remoto 69 | 14. E quanto ao time de Ops? 70 | 71 | Testes Automatizados 72 | 1. O processo de desenvolvimento de um software 73 | 2. Funcionalidades e bugs 74 | 3. Testes manuais e seus problemas 75 | 4. Testes automatizados 76 | 5. Exercício: Configurando o projeto para os testes automatizados 77 | 6. Exercício: Escrevendo testes automatizados na aplicação 78 | 7. Tipos de testes automatizados 79 | 8. Exercício: Testes automatizados com Mockito 80 | 9. Para saber mais: Pirâmide de Testes 81 | 10. Para saber mais: TDD (Test Driven Development) 82 | 11. Para saber mais: Refactoring 83 | 12. Cobertura de testes 84 | 13. Exercício: Code Coverage com JaCoCo 85 | 14. Métrica: Change Failure Rate 86 | 87 | Integração Contínua 88 | 1. Trabalhando em time 89 | 2. Integration hell 90 | 3. Integração Contínua 91 | 4. Princípios da integração contínua 92 | 5. Jenkins 93 | 6. Exercício: Instalação do Jenkins 94 | 7. Integração contínua com Jenkins 95 | 8. Exercício: Utilizando o Jenkins como servidor de integração contínua 96 | 9. Plugins do Jenkins 97 | 10. Exercício: Utilizando plugins do Jenkins 98 | 11. Branches 99 | 12. Feature-Branch vs. Trunk-Based 100 | 101 | Entrega Contínua 102 | 1. O trauma do deploy 103 | 2. Janela de deploy 104 | 3. Continuous Delivery 105 | 4. Os pilares da Continuous Delivery 106 | 5. Deployment Pipeline 107 | 6. Os problemas do deploy manual 108 | 7. Automatizando o deploy 109 | 8. Vagrant 110 | 9. Exercício: Automatizando a infra da aplicação com Vagrant 111 | 10. One-Click deploy 112 | 11. Exercício: One-click deployment com Jenkins 113 | 12. Immutable Infrastructure 114 | 13. Zero Downtime Deployment 115 | 14. Blue-Green Deployment 116 | 15. Canary Release 117 | 16. Métrica: Lead Time 118 | 17. Métrica: Deployment Frequency 119 | 18. O valor das métricas 120 | 19. Accelerate: State of DevOps Report 121 | 122 | Deploy Contínuo 123 | 1. Continuous Deployment 124 | 2. Vantagens e desvantagens do continuous deployment 125 | 3. Feature Toggle 126 | 4. Exercício: Continuous Deployment com Jenkins 127 | 128 | Monitoramento 129 | 1. O problema: Sistema fora do ar 130 | 2. A má prática: Apagar incêndios 131 | 3. A solução: Monitoramento Contínuo 132 | 4. Ferramentas de monitoramento 133 | 5. O que devemos monitorar? 134 | 6. Monitoramento de negócios 135 | 7. Exercício: Monitoramento com Glowroot 136 | 8. Métrica: Mean Time To Recover 137 | 138 | 139 | ## Para mais informações sobre o curso, acesse: https://www.caelum.com.br/curso-devops 140 | 141 | ## Licença 142 | 143 | Este obra está licenciado com uma Licença [Creative Commons Atribuição-NãoComercial-SemDerivações 4.0 Internacional](http://creativecommons.org/licenses/by-nc-nd/4.0/). 144 | 145 | ![](https://i.creativecommons.org/l/by-nc-nd/4.0/88x31.png) 146 | -------------------------------------------------------------------------------- /arquivos-curso/manual-build.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/arquivos-curso/manual-build.pdf -------------------------------------------------------------------------------- /arquivos-curso/manual-deploy.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/arquivos-curso/manual-deploy.pdf -------------------------------------------------------------------------------- /arquivos-curso/script-inicial.sql: -------------------------------------------------------------------------------- 1 | DROP DATABASE IF EXISTS `alura_forum`; 2 | CREATE DATABASE `alura_forum`; 3 | 4 | USE `alura_forum`; 5 | 6 | DROP TABLE IF EXISTS `Categoria`; 7 | CREATE TABLE `Categoria` ( 8 | `id` bigint(20) NOT NULL AUTO_INCREMENT, 9 | `nome` varchar(255) DEFAULT NULL, 10 | `pai_id` bigint(20) DEFAULT NULL, 11 | PRIMARY KEY (`id`), 12 | KEY `FKkoj40k1d2libv7v8xx9xjqfbu` (`pai_id`), 13 | CONSTRAINT `FKkoj40k1d2libv7v8xx9xjqfbu` FOREIGN KEY (`pai_id`) REFERENCES `Categoria` (`id`) 14 | ) ENGINE=InnoDB AUTO_INCREMENT=70 DEFAULT CHARSET=utf8; 15 | 16 | INSERT INTO `Categoria` VALUES (1,'Programação',NULL),(2,'Java',1),(3,'Design',NULL),(4,'Web Design',3),(5,'Mobile',NULL),(6,'Front-end',NULL),(7,'Infraestrutura',NULL),(8,'Business',NULL),(9,'Lógica de Programação',1),(10,'C#',1),(11,'Ruby',1),(12,'Java para Web',1),(13,'.NET para Web',1),(14,'Ruby on Rails',1),(15,'Integrações em Java',1),(16,'Integrações em .NET',1),(17,'Testes em Java',1),(18,'Testes em C#',1),(19,'Boas Práticas em Java',1),(20,'Boas Práticas em C#',1),(21,'Certificação Java',1),(22,'Persistência com Java',1),(23,'Programação Funcional',1),(24,'Linguagem C',1),(25,'Computação',1),(26,'Persistência com .NET',1),(27,'Desenvolvimento de Jogos',1),(28,'Análise de Dados',1),(29,'iOS',5),(30,'Android',5),(31,'Multiplataforma',5),(32,'Jogos',5),(33,'Introdução ao Design',3),(34,'Impressos',3),(35,'Vídeo e Motion',3),(36,'3D',3),(37,'Fotografia',3),(38,'UX',3),(39,'Apresentações',3),(40,'HTML e CSS',6),(41,'jQuery',6),(42,'JavaScript',6),(43,'Frameworks MVC',6),(44,'Automação e Performance',6),(45,'SQL',7),(46,'NoSQL',7),(47,'Linux',7),(48,'Builds e Versionamento',7),(49,'Entrega Contínua',7),(50,'Windows',7),(51,'Redes',7),(52,'Internet das Coisas',7),(53,'Embarcados',7),(54,'Cloud Computing',7),(55,'CCNA exame 100-105',7),(56,'Marketing Digital',8),(57,'Excel',8),(58,'Agilidade',8),(59,'SEO e Adwords',8),(60,'Documentação',8),(61,'Concursos',8),(62,'Carreira',8),(63,'Governança',8),(64,'Social Media',8),(65,'Construção de Sites',8),(66,'Startup',8),(67,'E-commerce',8),(68,'Liderança',8),(69,'Business Intelligence',8); 17 | 18 | DROP TABLE IF EXISTS `Curso`; 19 | CREATE TABLE `Curso` ( 20 | `id` bigint(20) NOT NULL AUTO_INCREMENT, 21 | `nome` varchar(255) DEFAULT NULL, 22 | `subcategoria_id` bigint(20) DEFAULT NULL, 23 | PRIMARY KEY (`id`), 24 | KEY `FK8okl60ifb3l8aox4cdaurxlsv` (`subcategoria_id`), 25 | CONSTRAINT `FK8okl60ifb3l8aox4cdaurxlsv` FOREIGN KEY (`subcategoria_id`) REFERENCES `Categoria` (`id`) 26 | ) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8; 27 | 28 | INSERT INTO `Curso` VALUES (1,'Java e Orientação a Objetos',2),(2,'Adobe XD',4),(3,'Bootstrap',40),(4,'React Native parte 2',31),(5,'MySQL I',45),(6,'Scrum',58); 29 | 30 | DROP TABLE IF EXISTS `Perfil`; 31 | CREATE TABLE `Perfil` ( 32 | `nome` varchar(255) NOT NULL, 33 | PRIMARY KEY (`nome`) 34 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 35 | 36 | INSERT INTO `Perfil` VALUES ('ROLE_ALUNO'),('ROLE_MODERADOR'); 37 | 38 | DROP TABLE IF EXISTS `Usuario`; 39 | CREATE TABLE `Usuario` ( 40 | `id` bigint(20) NOT NULL AUTO_INCREMENT, 41 | `email` varchar(255) NOT NULL, 42 | `nome` varchar(255) DEFAULT NULL, 43 | `senha` varchar(255) DEFAULT NULL, 44 | PRIMARY KEY (`id`), 45 | UNIQUE KEY `UK_4tdehxj7dh8ghfc68kbwbsbll` (`email`) 46 | ) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8; 47 | 48 | INSERT INTO `Usuario` VALUES (1,'moderador@gmail.com','Moderador','e10adc3949ba59abbe56e057f20f883e'),(2,'aluno1@gmail.com','Aluno 1','e10adc3949ba59abbe56e057f20f883e'),(3,'aluno2@gmail.com','Aluno 2','e10adc3949ba59abbe56e057f20f883e'); 49 | 50 | DROP TABLE IF EXISTS `Usuario_Perfil`; 51 | CREATE TABLE `Usuario_Perfil` ( 52 | `Usuario_id` bigint(20) NOT NULL, 53 | `perfis_nome` varchar(255) NOT NULL, 54 | KEY `FKedqq1fy8bq3glycqr8d95en2b` (`perfis_nome`), 55 | KEY `FKbk83sv4dmxtharkihuvu5kxg0` (`Usuario_id`), 56 | CONSTRAINT `FKbk83sv4dmxtharkihuvu5kxg0` FOREIGN KEY (`Usuario_id`) REFERENCES `Usuario` (`id`), 57 | CONSTRAINT `FKedqq1fy8bq3glycqr8d95en2b` FOREIGN KEY (`perfis_nome`) REFERENCES `Perfil` (`nome`) 58 | ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 59 | 60 | INSERT INTO `Usuario_Perfil` VALUES (1,'ROLE_ALUNO'),(1,'ROLE_MODERADOR'),(2,'ROLE_ALUNO'),(3,'ROLE_ALUNO'); 61 | 62 | DROP TABLE IF EXISTS `Topico`; 63 | CREATE TABLE `Topico` ( 64 | `id` bigint(20) NOT NULL AUTO_INCREMENT, 65 | `dataCriacao` datetime DEFAULT NULL, 66 | `dataUltimaAtualizacao` datetime DEFAULT NULL, 67 | `descricao` longtext, 68 | `status` varchar(255) DEFAULT NULL, 69 | `titulo` varchar(255) DEFAULT NULL, 70 | `curso_id` bigint(20) DEFAULT NULL, 71 | `autor_id` bigint(20) NOT NULL, 72 | PRIMARY KEY (`id`), 73 | KEY `FKeu1m6i8yc1o47slwy1wyvcb9c` (`curso_id`), 74 | KEY `FKe3s27bht5huqss48p04bhw106` (`autor_id`), 75 | CONSTRAINT `FK4gdd21ia46fb2e23opuphcdw4` FOREIGN KEY (`autor_id`) REFERENCES `Usuario` (`id`), 76 | CONSTRAINT `FKeu1m6i8yc1o47slwy1wyvcb9c` FOREIGN KEY (`curso_id`) REFERENCES `Curso` (`id`) 77 | ) ENGINE=InnoDB AUTO_INCREMENT=103 DEFAULT CHARSET=utf8; 78 | 79 | INSERT INTO `Topico` VALUES (1,'2019-01-08 17:00:00','2019-01-10 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 1',1,2),(2,'2019-01-07 17:00:00','2019-01-10 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 2',1,2),(3,'2019-01-06 17:00:00','2019-01-10 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 3',1,2),(4,'2019-01-05 17:00:00','2019-01-10 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 4',1,2),(5,'2019-01-04 17:00:00','2019-01-11 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 5',1,2),(6,'2019-01-03 17:00:00','2019-01-11 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 6',1,2),(7,'2019-01-02 17:00:00','2019-01-02 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 7',1,2),(8,'2019-01-01 17:00:00','2019-01-01 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 8',2,2),(9,'2018-12-31 17:00:00','2018-12-31 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 9',2,2),(10,'2018-12-30 17:00:00','2018-12-30 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 10',2,2),(11,'2018-12-29 17:00:00','2018-12-29 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 11',2,2),(12,'2018-12-28 17:00:00','2018-12-28 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 12',2,2),(13,'2018-12-27 17:00:00','2018-12-27 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 13',2,2),(14,'2018-12-26 17:00:00','2018-12-26 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 14',2,2),(15,'2018-12-25 17:00:00','2018-12-25 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 15',3,2),(16,'2018-12-24 17:00:00','2018-12-24 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 16',3,2),(17,'2018-12-23 17:00:00','2018-12-23 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 17',3,2),(18,'2018-12-22 17:00:00','2018-12-22 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 18',3,2),(19,'2018-12-21 17:00:00','2019-01-11 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 19',3,2),(20,'2018-12-20 17:00:00','2019-01-11 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 20',3,2),(21,'2018-12-19 17:00:00','2019-01-11 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 21',3,2),(22,'2018-12-18 17:00:00','2018-12-18 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 22',4,2),(23,'2018-12-17 17:00:00','2018-12-17 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 23',4,2),(24,'2018-12-16 17:00:00','2018-12-16 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 24',4,2),(25,'2018-12-15 17:00:00','2018-12-15 17:00:00','quem pode me ajudar???','NAO_RESPONDIDO','duvida 25',4,2); 80 | 81 | DROP TABLE IF EXISTS `Resposta`; 82 | CREATE TABLE `Resposta` ( 83 | `id` bigint(20) NOT NULL AUTO_INCREMENT, 84 | `dataCriacao` datetime DEFAULT NULL, 85 | `descricao` longtext, 86 | `solucao` bit(1) NOT NULL, 87 | `autor_id` bigint(20) NOT NULL, 88 | `topico_id` bigint(20) DEFAULT NULL, 89 | PRIMARY KEY (`id`), 90 | KEY `FKhw9shwkx1j0po6dbqqfc94t0t` (`topico_id`), 91 | KEY `FK391y1bp1lk7qe66t13v3da8bq` (`autor_id`), 92 | CONSTRAINT `FK391y1bp1lk7qe66t13v3da8bq` FOREIGN KEY (`autor_id`) REFERENCES `Usuario` (`id`), 93 | CONSTRAINT `FKhw9shwkx1j0po6dbqqfc94t0t` FOREIGN KEY (`topico_id`) REFERENCES `Topico` (`id`) 94 | ) ENGINE=InnoDB AUTO_INCREMENT=22 DEFAULT CHARSET=utf8; -------------------------------------------------------------------------------- /arquivos-curso/tomcat.service: -------------------------------------------------------------------------------- 1 | [Unit] 2 | Description=Tomcat 8 3 | After=network.target 4 | 5 | [Service] 6 | Type=forking 7 | 8 | User=tomcat 9 | Group=tomcat 10 | 11 | Environment="JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64" 12 | Environment="JAVA_OPTS=-Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true" 13 | 14 | Environment="CATALINA_BASE=/opt/tomcat/tomcat8" 15 | Environment="CATALINA_HOME=/opt/tomcat/tomcat8" 16 | Environment="CATALINA_PID=/opt/tomcat/tomcat8/temp/tomcat.pid" 17 | Environment="CATALINA_OPTS=-Xms384M -Xmx384M" 18 | 19 | ExecStart=/opt/tomcat/tomcat8/bin/startup.sh 20 | ExecStop=/opt/tomcat/tomcat8/bin/shutdown.sh 21 | 22 | [Install] 23 | WantedBy=multi-user.target -------------------------------------------------------------------------------- /book.properties: -------------------------------------------------------------------------------- 1 | TITLE="DevOps na prática com cultura, colaboração, ferramentas e automatização" 2 | DESCRIPTION="DevOps na prática com cultura, colaboração, ferramentas e automatização" 3 | AUTHOR=Caelum 4 | THEME=caelum-tema 5 | -------------------------------------------------------------------------------- /cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/cover.jpg -------------------------------------------------------------------------------- /imagens/capitulo-02/agile-manifesto.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-02/agile-manifesto.png -------------------------------------------------------------------------------- /imagens/capitulo-02/apollo-11.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-02/apollo-11.jpg -------------------------------------------------------------------------------- /imagens/capitulo-02/eniac-devs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-02/eniac-devs.png -------------------------------------------------------------------------------- /imagens/capitulo-02/eniac.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-02/eniac.png -------------------------------------------------------------------------------- /imagens/capitulo-02/margaret-hamilton.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-02/margaret-hamilton.png -------------------------------------------------------------------------------- /imagens/capitulo-02/nato.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-02/nato.png -------------------------------------------------------------------------------- /imagens/capitulo-02/patrick-debois.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-02/patrick-debois.png -------------------------------------------------------------------------------- /imagens/capitulo-02/tools.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-02/tools.png -------------------------------------------------------------------------------- /imagens/capitulo-03/kanban-base.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-03/kanban-base.png -------------------------------------------------------------------------------- /imagens/capitulo-03/kanban-pull.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-03/kanban-pull.png -------------------------------------------------------------------------------- /imagens/capitulo-03/kanban-push.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-03/kanban-push.png -------------------------------------------------------------------------------- /imagens/capitulo-04/alura-home.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-04/alura-home.png -------------------------------------------------------------------------------- /imagens/capitulo-04/forum-cadastro.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-04/forum-cadastro.png -------------------------------------------------------------------------------- /imagens/capitulo-04/forum-dashboard.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-04/forum-dashboard.png -------------------------------------------------------------------------------- /imagens/capitulo-04/forum-login.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-04/forum-login.png -------------------------------------------------------------------------------- /imagens/capitulo-04/forum-perfil.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-04/forum-perfil.png -------------------------------------------------------------------------------- /imagens/capitulo-04/forum-senha.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-04/forum-senha.png -------------------------------------------------------------------------------- /imagens/capitulo-04/forum-topico-detalhe.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-04/forum-topico-detalhe.png -------------------------------------------------------------------------------- /imagens/capitulo-04/forum-topico-responder.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-04/forum-topico-responder.png -------------------------------------------------------------------------------- /imagens/capitulo-04/forum-topicos.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-04/forum-topicos.png -------------------------------------------------------------------------------- /imagens/capitulo-05/convert-maven-project.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-05/convert-maven-project.png -------------------------------------------------------------------------------- /imagens/capitulo-05/maven-build-artefatos.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-05/maven-build-artefatos.png -------------------------------------------------------------------------------- /imagens/capitulo-05/maven-build-eclipse-sucesso.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-05/maven-build-eclipse-sucesso.png -------------------------------------------------------------------------------- /imagens/capitulo-05/maven-build-eclipse.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-05/maven-build-eclipse.png -------------------------------------------------------------------------------- /imagens/capitulo-05/maven-info.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-05/maven-info.png -------------------------------------------------------------------------------- /imagens/capitulo-06/download-git.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-06/download-git.png -------------------------------------------------------------------------------- /imagens/capitulo-06/gitlab-new-project.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-06/gitlab-new-project.png -------------------------------------------------------------------------------- /imagens/capitulo-06/gitlab-site.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-06/gitlab-site.png -------------------------------------------------------------------------------- /imagens/capitulo-07/build-path-add-folder.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/build-path-add-folder.png -------------------------------------------------------------------------------- /imagens/capitulo-07/build-path-finalizado.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/build-path-finalizado.png -------------------------------------------------------------------------------- /imagens/capitulo-07/build-path-folder-name.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/build-path-folder-name.png -------------------------------------------------------------------------------- /imagens/capitulo-07/build-path-lista.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/build-path-lista.png -------------------------------------------------------------------------------- /imagens/capitulo-07/build-path-opcao.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/build-path-opcao.png -------------------------------------------------------------------------------- /imagens/capitulo-07/build-path-output-folder.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/build-path-output-folder.png -------------------------------------------------------------------------------- /imagens/capitulo-07/jacoco-relatorio.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/jacoco-relatorio.png -------------------------------------------------------------------------------- /imagens/capitulo-07/junit-new-test-case.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/junit-new-test-case.png -------------------------------------------------------------------------------- /imagens/capitulo-07/junit-teste-falha-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/junit-teste-falha-2.png -------------------------------------------------------------------------------- /imagens/capitulo-07/junit-teste-falha.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/junit-teste-falha.png -------------------------------------------------------------------------------- /imagens/capitulo-07/junit-teste-sucesso-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/junit-teste-sucesso-2.png -------------------------------------------------------------------------------- /imagens/capitulo-07/junit-teste-sucesso.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/junit-teste-sucesso.png -------------------------------------------------------------------------------- /imagens/capitulo-07/piramide-testes.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-07/piramide-testes.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-build-now.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-build-now.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-build-resultado.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-build-resultado.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-form-admin.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-form-admin.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-home.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-home.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-instancia.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-instancia.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-logo.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-manage-plugins-available.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-manage-plugins-available.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-manage-plugins-install.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-manage-plugins-install.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-manage-plugins.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-manage-plugins.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-new-item-build-triggers.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-new-item-build-triggers.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-new-item-build.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-new-item-build.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-new-item-scm.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-new-item-scm.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-new-item.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-new-item.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-plugin-green-ball.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-plugin-green-ball.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-plugin-radiator-botao.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-plugin-radiator-botao.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-plugin-radiator-form.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-plugin-radiator-form.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-plugin-radiator-tela.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-plugin-radiator-tela.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-plugin-test-results-analyzer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-plugin-test-results-analyzer.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-plugins-git.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-plugins-git.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-plugins-modo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-plugins-modo.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-plugins-none.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-plugins-none.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-senha-tela.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-senha-tela.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-senha-terminal.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-senha-terminal.png -------------------------------------------------------------------------------- /imagens/capitulo-08/jenkins-site-plugins.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/jenkins-site-plugins.png -------------------------------------------------------------------------------- /imagens/capitulo-08/tv-build.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-08/tv-build.jpeg -------------------------------------------------------------------------------- /imagens/capitulo-09/blue-green-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/blue-green-1.png -------------------------------------------------------------------------------- /imagens/capitulo-09/blue-green-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/blue-green-2.png -------------------------------------------------------------------------------- /imagens/capitulo-09/canary-release.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/canary-release.png -------------------------------------------------------------------------------- /imagens/capitulo-09/deployment-pipeline.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/deployment-pipeline.png -------------------------------------------------------------------------------- /imagens/capitulo-09/jenkins-build-now.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/jenkins-build-now.png -------------------------------------------------------------------------------- /imagens/capitulo-09/jenkins-new-item-build-maven.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/jenkins-new-item-build-maven.png -------------------------------------------------------------------------------- /imagens/capitulo-09/jenkins-new-item-build-vagrant.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/jenkins-new-item-build-vagrant.png -------------------------------------------------------------------------------- /imagens/capitulo-09/jenkins-new-item-scm.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/jenkins-new-item-scm.png -------------------------------------------------------------------------------- /imagens/capitulo-09/jenkins-new-item.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/jenkins-new-item.png -------------------------------------------------------------------------------- /imagens/capitulo-09/lead-time.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/lead-time.png -------------------------------------------------------------------------------- /imagens/capitulo-09/metricas-performance.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/metricas-performance.png -------------------------------------------------------------------------------- /imagens/capitulo-09/vagrant-cloud.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/vagrant-cloud.png -------------------------------------------------------------------------------- /imagens/capitulo-09/vagrant-download.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/vagrant-download.png -------------------------------------------------------------------------------- /imagens/capitulo-09/vagrant-logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/vagrant-logo.png -------------------------------------------------------------------------------- /imagens/capitulo-09/vagrant-vm-virtualbox.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/vagrant-vm-virtualbox.png -------------------------------------------------------------------------------- /imagens/capitulo-09/war-room.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-09/war-room.png -------------------------------------------------------------------------------- /imagens/capitulo-10/jenkins-copy-item.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-10/jenkins-copy-item.png -------------------------------------------------------------------------------- /imagens/capitulo-11/dashboard.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/caelum/apostila-devops/19e75f7e8c72dabac95dcbeca50de6b66d8e6897/imagens/capitulo-11/dashboard.jpg --------------------------------------------------------------------------------