{"id":87467,"date":"2020-07-08T13:42:11","date_gmt":"2020-07-08T11:42:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn"},"modified":"2020-07-08T13:42:11","modified_gmt":"2020-07-08T11:42:11","slug":"rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/rukovodstvo-dlya-nachinayushhih-sozdaem-devops-pajplajn","title":{"rendered":"Guia para iniciantes: como criar um pipeline DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Se voc\u00ea \u00e9 novo em DevOps, consulte este guia para criar seu primeiro pipeline em cinco etapas.<\/i><\/p>\n

\"Guia<\/p>\n

DevOps tornou-se a solu\u00e7\u00e3o padr\u00e3o para corrigir processos de desenvolvimento de software lentos, fragmentados ou n\u00e3o funcionais. O problema \u00e9 que, se voc\u00ea \u00e9 novo em DevOps e n\u00e3o sabe por onde come\u00e7ar, pode faltar compreens\u00e3o sobre esses m\u00e9todos. Este artigo abordar\u00e1 a defini\u00e7\u00e3o de um pipeline DevOps e fornecer\u00e1 um guia para sua cria\u00e7\u00e3o em cinco etapas. Embora este tutorial n\u00e3o seja abrangente, ele deve fornecer uma base para que voc\u00ea comece sua jornada e expanda seu conhecimento no futuro. Mas vamos come\u00e7ar com uma hist\u00f3ria.<\/p>\n

Minha jornada em DevOps<\/h3>\n

\nAntes, eu trabalhava na equipe de nuvem da Citi Group, desenvolvendo um aplicativo web Infrastructure-as-a-Service (IaaS) para gerenciar a infraestrutura em nuvem da Citi, mas sempre me interessei em como tornar o processo de desenvolvimento mais eficiente e trazer mudan\u00e7as culturais positivas para a equipe de desenvolvedores. A resposta eu encontrei em um livro recomendado por Greg Lavender, diretor t\u00e9cnico de arquitetura em nuvem e infraestrutura da Citi. O livro se chamava \"Projeto F\u00eanix\" (The Phoenix Project<\/a><\/noindex>), e nele s\u00e3o explicados os princ\u00edpios do DevOps, sendo lido como um romance.<\/p>\n

A tabela no verso do livro mostra com que frequ\u00eancia diferentes empresas implantam seus sistemas em ambientes para o lan\u00e7amento de vers\u00f5es:<\/p>\n

Amazon: 23.000 por dia
\nGoogle: 5.500 por dia
\nNetflix: 500 por dia
\nFacebook: Uma vez por dia
\nTwitter: 3 vezes por semana
\nUma empresa t\u00edpica: Uma vez a cada 9 meses<\/p>\n

Como s\u00e3o poss\u00edveis as frequ\u00eancias da Amazon, Google e Netflix? Tudo porque essas empresas descobriram como implementar um pipeline DevOps quase perfeito.
\n<\/a><\/noindex>
\nEst\u00e1vamos longe disso at\u00e9 implementarmos o DevOps no Citi. Naquela \u00e9poca, minha equipe tinha diferentes ambientes, mas a implanta\u00e7\u00e3o no servidor de desenvolvimento era completamente manual. Todos os desenvolvedores tinham acesso apenas a um servidor de desenvolvimento baseado no IBM WebSphere Application Server Community Edition. O problema era que o servidor desligava sempre que v\u00e1rios usu\u00e1rios tentavam implantar ao mesmo tempo, ent\u00e3o os desenvolvedores precisavam se comunicar sobre suas inten\u00e7\u00f5es, o que era bastante doloroso. Al\u00e9m disso, havia problemas com a cobertura de testes de baixo n\u00edvel do c\u00f3digo, processos manuais de implanta\u00e7\u00e3o complicados e a falta de um sistema para rastrear a implanta\u00e7\u00e3o de c\u00f3digo relacionada a uma determinada tarefa ou hist\u00f3ria de usu\u00e1rio.<\/p>\n

Percebi que era necess\u00e1rio fazer algo e encontrei um colega com mentalidade semelhante. Decidimos colaborar na cria\u00e7\u00e3o do pipeline DevOps inicial \u2013 ele configurou uma m\u00e1quina virtual e um servidor de aplicativos Tomcat, enquanto eu trabalhava no Jenkins, integrando o Atlassian Jira e o BitBucket, al\u00e9m de melhorar a cobertura de testes de c\u00f3digo. Este projeto paralelo foi muito bem-sucedido: conseguimos quase automatizar muitos processos, alcan\u00e7amos praticamente 100% de disponibilidade do nosso servidor de desenvolvimento, garantimos rastreamento e melhoramos a cobertura de testes de c\u00f3digo, al\u00e9m de adicionar a capacidade de vincular branches no Git a tarefas no Jira ou implanta\u00e7\u00f5es. A maioria das ferramentas que usamos para construir nosso pipeline DevOps tinha c\u00f3digo aberto.<\/p>\n

Agora eu entendo o qu\u00e3o simples era nosso pipeline DevOps: n\u00e3o us\u00e1vamos extens\u00f5es como arquivos Jenkins ou Ansible. No entanto, esse pipeline simples funcionava bem, possivelmente devido ao princ\u00edpio de Pareto (tamb\u00e9m conhecido como regra 80\/20).<\/p>\n

Uma breve introdu\u00e7\u00e3o ao DevOps e ao pipeline CI\/CD<\/h3>\n

\nSe voc\u00ea perguntar a v\u00e1rias pessoas: \"O que \u00e9 DevOps?\", provavelmente receber\u00e1 diferentes respostas. DevOps, assim como Agile, evoluiu para abranger v\u00e1rias disciplinas diferentes, mas a maioria das pessoas concorda em alguns pontos: DevOps \u00e9 uma pr\u00e1tica de desenvolvimento de software ou ciclo de vida de desenvolvimento de software (SDLC), cujo princ\u00edpio central \u00e9 a mudan\u00e7a na cultura em que desenvolvedores e n\u00e3o desenvolvedores coexistem em um ambiente onde:<\/p>\n

As opera\u00e7\u00f5es que antes eram manuais s\u00e3o automatizadas;
\nCada um faz o que sabe fazer melhor;
\nO n\u00famero de implanta\u00e7\u00f5es em um determinado per\u00edodo de tempo aumenta; A capacidade de entrega aumenta;
\nA flexibilidade do desenvolvimento \u00e9 aprimorada.<\/p>\n

Embora ter as ferramentas de software certas n\u00e3o seja a \u00fanica coisa necess\u00e1ria para criar um ambiente DevOps, algumas ferramentas s\u00e3o essenciais. Uma ferramenta chave \u00e9 integra\u00e7\u00e3o cont\u00ednua e entrega cont\u00ednua (CI\/CD). Nesse pipeline, os ambientes t\u00eam v\u00e1rias etapas (por exemplo, DEV, INT, TST, QA, UAT, STG, PROD), muitas opera\u00e7\u00f5es s\u00e3o automatizadas, e os desenvolvedores podem escrever c\u00f3digo de alta qualidade, alcan\u00e7ar flexibilidade no desenvolvimento e alta frequ\u00eancia de implanta\u00e7\u00f5es.<\/p>\n

Este artigo descreve uma abordagem em cinco etapas para criar um pipeline DevOps, semelhante ao mostrado no pr\u00f3ximo diagrama, usando ferramentas de c\u00f3digo aberto.<\/p>\n

Passo 1: M\u00e9todos CI\/CD<\/h3>\n

\nA primeira coisa que voc\u00ea precisa \u00e9 de uma ferramenta para CI\/CD. O Jenkins, uma ferramenta de c\u00f3digo aberto baseada em Java e licenciada sob a MIT, \u00e9 o meio que popularizou a abordagem DevOps e se tornou o padr\u00e3o de fato.<\/p>\n

Ent\u00e3o, o que \u00e9 Jenkins? Considere-o como um controle remoto m\u00e1gico que pode se comunicar com v\u00e1rios servi\u00e7os e ferramentas e organiz\u00e1-los. Por si s\u00f3, uma ferramenta CI\/CD como o Jenkins \u00e9 in\u00fatil, mas se torna mais poderosa \u00e0 medida que se conecta a diferentes ferramentas e servi\u00e7os.<\/p>\n

O Jenkins \u00e9 apenas uma das muitas ferramentas de c\u00f3digo aberto para CI\/CD que voc\u00ea pode usar para construir um pipeline DevOps.<\/p>\n

Jenkins: Creative Commons e MIT
\nTravis CI: MIT
\nCruiseControl: BSD
\nBuildbot: GPL
\nApache Gump: Apache 2.0
\nCabie: GNU<\/p>\n

Veja como os processos DevOps aparecem com uma ferramenta CI\/CD:<\/p>\n

\"Guia<\/p>\n

Voc\u00ea tem uma ferramenta CI\/CD funcionando em seu localhost, mas no momento voc\u00ea pode fazer pouco com isso. Vamos avan\u00e7ar para a pr\u00f3xima etapa da jornada no mundo DevOps.<\/p>\n

Passo 2: Gerenciamento de sistemas de controle de vers\u00e3o<\/h3>\n

\nA melhor (e talvez a mais simples) maneira de testar se sua ferramenta CI\/CD pode fazer m\u00e1gica \u00e9 integrando-a a uma ferramenta de controle de c\u00f3digo-fonte (SCM). Por que voc\u00ea precisa de controle de c\u00f3digo-fonte? Suponhamos que voc\u00ea esteja desenvolvendo um aplicativo. Sempre que voc\u00ea cria um aplicativo, voc\u00ea programa, e n\u00e3o importa se voc\u00ea est\u00e1 usando Java, Python, C++, Go, Ruby, JavaScript ou qualquer uma das in\u00fameras linguagens de programa\u00e7\u00e3o. O c\u00f3digo que voc\u00ea escreve \u00e9 chamado de c\u00f3digo-fonte. No in\u00edcio, especialmente quando voc\u00ea est\u00e1 trabalhando sozinho, pode ser que voc\u00ea consiga colocar tudo em um diret\u00f3rio local. Mas quando o projeto cresce e voc\u00ea convida outras pessoas para colaborar, voc\u00ea precisa de um m\u00e9todo para evitar conflitos ao compartilhar modifica\u00e7\u00f5es de forma eficaz. Voc\u00ea tamb\u00e9m precisa de uma maneira de restaurar vers\u00f5es anteriores, porque fazer backups e copiar\/colar neles j\u00e1 est\u00e1 obsoleto. Voc\u00ea (e seus colegas de equipe) precisam de algo melhor.<\/p>\n

\u00c9 aqui que a ferramenta de controle de c\u00f3digo-fonte se torna praticamente uma necessidade. Essa ferramenta armazena seu c\u00f3digo em reposit\u00f3rios, controla vers\u00f5es e coordena o trabalho dos participantes do projeto.<\/p>\n

Embora existam v\u00e1rias ferramentas de controle de c\u00f3digo-fonte, o Git \u00e9 o padr\u00e3o, e isso \u00e9 verdade. Eu recomendo fortemente o uso do Git, embora existam outras op\u00e7\u00f5es de c\u00f3digo aberto, se preferir.<\/p>\n

Git: GPLv2 e LGPL v2.1
\nSubversion: Apache 2.0
\nConcurrent Versions System (CVS): GNU
\nVesta: LGPL
\nMercurial: GNU GPL v2+<\/p>\n

Assim \u00e9 um pipeline DevOps com a adi\u00e7\u00e3o de ferramentas de controle de c\u00f3digo-fonte.<\/p>\n

\"Guia<\/p>\n

Uma ferramenta CI\/CD pode automatizar os processos de verifica\u00e7\u00e3o, obten\u00e7\u00e3o de c\u00f3digo-fonte e colabora\u00e7\u00e3o entre os membros. N\u00e3o \u00e9 ruim? Mas como transformar isso em um aplicativo funcional que bilh\u00f5es de pessoas possam usar e avaliar?<\/p>\n

Passo 3: Criando uma ferramenta de automa\u00e7\u00e3o de builds<\/h3>\n

\n\u00d3timo! Voc\u00ea pode verificar o c\u00f3digo e fazer altera\u00e7\u00f5es no sistema de controle de vers\u00e3o, al\u00e9m de convidar seus amigos para colaborar no desenvolvimento. Mas voc\u00ea ainda n\u00e3o criou um aplicativo. Para fazer um aplicativo da web, voc\u00ea precisa compil\u00e1-lo e empacot\u00e1-lo em um formato de pacote implant\u00e1vel ou execut\u00e1-lo como um arquivo execut\u00e1vel. (Observe que linguagens de programa\u00e7\u00e3o interpretadas, como JavaScript ou PHP, n\u00e3o precisam de compila\u00e7\u00e3o).<\/p>\n

Use uma ferramenta de automa\u00e7\u00e3o de builds. Independentemente da ferramenta de automa\u00e7\u00e3o de builds que voc\u00ea escolher, todas elas t\u00eam o mesmo objetivo: compilar o c\u00f3digo-fonte em um formato desejado e automatizar a tarefa de limpeza, compila\u00e7\u00e3o, teste e implanta\u00e7\u00e3o em um ambiente espec\u00edfico. As ferramentas de build variar\u00e3o dependendo da sua linguagem de programa\u00e7\u00e3o, mas aqui est\u00e3o algumas op\u00e7\u00f5es comuns de c\u00f3digo aberto.<\/p>\n

Nome
\nLicen\u00e7a
\nLinguagem de programa\u00e7\u00e3o<\/p>\n

Maven
\nApache 2.0
\n Java<\/p>\n

Ant
\nApache 2.0
\nJava<\/p>\n

Gradle
\nApache 2.0
\nJava<\/p>\n

Bazel
\nApache 2.0
\nJava<\/p>\n

Make
\nGNU
\nN\/A<\/p>\n

Grunt
\nMIT
\nJavaScript<\/p>\n

Gulp
\nMIT
\nJavaScript<\/p>\n

Buildr
\nApache
\nRuby<\/p>\n

Rake
\nMIT
\nRuby<\/p>\n

A-A-P
\nGNU
\nPython<\/p>\n

SCons
\nMIT
\nPython<\/p>\n

BitBake
\nGPLv2
\nPython<\/p>\n

Cake
\nMIT
\nC#<\/p>\n

ASDF
\nExpat (MIT)
\nLISP<\/p>\n

Cabal
\nBSD
\nHaskell<\/p>\n

Legal! Voc\u00ea pode colocar arquivos de configura\u00e7\u00e3o da ferramenta de automa\u00e7\u00e3o de builds no sistema de controle de vers\u00e3o e permitir que sua ferramenta CI\/CD una tudo.<\/p>\n

\"Guia<\/p>\n

Tudo bem, n\u00e3o \u00e9? Mas onde voc\u00ea vai implantar seu aplicativo?<\/p>\n

Passo 4: Servidor para aplicativos da web<\/h3>\n

\nPor enquanto, voc\u00ea tem um arquivo empacotado que pode ser tanto execut\u00e1vel quanto instal\u00e1vel. Para que qualquer aplicativo seja realmente \u00fatil, ele deve fornecer algum servi\u00e7o ou interface, mas voc\u00ea precisa de um cont\u00eainer para hospedar seu aplicativo.<\/p>\n

Um servidor para aplicativos da web \u00e9 exatamente esse cont\u00eainer. O servidor fornece um ambiente onde pode ser definida a l\u00f3gica do pacote implant\u00e1vel. Al\u00e9m disso, o servidor oferece uma interface e oferece servi\u00e7os da web, abrindo soquetes para o mundo externo. Voc\u00ea precisa de um servidor HTTP, bem como de um ambiente (como uma m\u00e1quina virtual) para hosped\u00e1-lo. E por enquanto, vamos supor que voc\u00ea aprender\u00e1 mais sobre isso depois (embora eu fale sobre cont\u00eaineres abaixo).<\/p>\n

Existem v\u00e1rios servidores de aplicativos da web de c\u00f3digo aberto.<\/p>\n

Nome
\nLicen\u00e7a
\nLinguagem de programa\u00e7\u00e3o<\/p>\n

Tomcat
\nApache 2.0
\nJava<\/p>\n

Jetty
\nApache 2.0
\nJava<\/p>\n

WildFly
\nGNU Lesser Public
\nJava<\/p>\n

GlassFish
\nCDDL & GNU Less Public
\nJava<\/p>\n

Django
\n3-Clause BSD
\nPython<\/p>\n

Tornado
\nApache 2.0
\nPython<\/p>\n

Gunicorn
\nMIT
\nPython<\/p>\n

Python
\nMIT
\nPython<\/p>\n

Rails
\nMIT
\nRuby<\/p>\n

Node.js
\nMIT
\nJavascript<\/p>\n

Seu pipeline DevOps est\u00e1 quase pronto para uso. Bom trabalho!<\/p>\n

\"Guia<\/p>\n

Embora voc\u00ea possa parar aqui e lidar com a integra\u00e7\u00e3o sozinho, a qualidade do c\u00f3digo \u00e9 uma quest\u00e3o importante para os desenvolvedores de aplicativos, e deve ser uma preocupa\u00e7\u00e3o.<\/p>\n

Passo 5: Cobertura de teste de c\u00f3digo<\/h3>\n

\nA implementa\u00e7\u00e3o de testes pode ser mais uma exig\u00eancia pesada, mas os desenvolvedores devem capturar quaisquer erros no aplicativo desde o in\u00edcio e melhorar a qualidade do c\u00f3digo para garantir que os usu\u00e1rios finais fiquem satisfeitos. Felizmente, existem v\u00e1rias ferramentas de c\u00f3digo aberto para testar seu c\u00f3digo e gerar recomenda\u00e7\u00f5es sobre como melhorar sua qualidade. Melhor ainda, a maioria das ferramentas de CI\/CD pode se conectar a essas ferramentas e automatizar o processo.<\/p>\n

O teste de c\u00f3digo consiste em duas partes: frameworks de teste que ajudam a escrever e executar testes, bem como ferramentas de sugest\u00f5es que ajudam a melhorar a qualidade do c\u00f3digo.<\/p>\n

Sistemas de teste de c\u00f3digo<\/b><\/p>\n

Nome
\nLicen\u00e7a
\nLinguagem de programa\u00e7\u00e3o<\/p>\n

JUnit
\nEclipse Public License
\nJava<\/p>\n

EasyMock
\nApache
\nJava<\/p>\n

Mockito
\nMIT
\nJava<\/p>\n

PowerMock
\nApache 2.0
\nJava<\/p>\n

Pytest
\n MIT
\nPython<\/p>\n

Hypothesis
\nMozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Sistemas de recomenda\u00e7\u00f5es para melhorar o c\u00f3digo<\/b><\/p>\n

Nome
\nLicen\u00e7a
\nLinguagem de programa\u00e7\u00e3o<\/p>\n

Cobertura
\nGNU
\nJava<\/p>\n

CodeCover
\nEclipse Public (EPL)
\nJava<\/p>\n

Coverage.py
\n Apache 2.0
\nPython<\/p>\n

Emma
\nCommon Public License
\nJava<\/p>\n

JaCoCo
\n Eclipse Public License
\nJava<\/p>\n

Hypothesis
\n Mozilla
\nPython<\/p>\n

Tox
\nMIT
\nPython<\/p>\n

Jasmine
\nMIT
\nJavaScript<\/p>\n

Karma
\nMIT
\nJavaScript<\/p>\n

Mocha
\n MIT
\nJavaScript<\/p>\n

Jest
\nMIT
\nJavaScript<\/p>\n

Observe que a maioria das ferramentas e frameworks mencionados acima s\u00e3o escritos para Java, Python e JavaScript, j\u00e1 que C++ e C# s\u00e3o linguagens de programa\u00e7\u00e3o propriet\u00e1rias (embora o GCC tenha c\u00f3digo aberto).<\/p>\n

Agora que voc\u00ea implementou ferramentas de cobertura de c\u00f3digo com testes, seu pipeline DevOps deve se parecer com o diagrama mostrado no in\u00edcio deste guia.<\/p>\n

Passos Adicionais<\/h3>\n

\nCont\u00eaineres<\/b><\/p>\n

Como j\u00e1 mencionei, voc\u00ea pode hospedar seu servidor em uma m\u00e1quina virtual ou servidor, mas os cont\u00eaineres s\u00e3o uma solu\u00e7\u00e3o popular.<\/p>\n

O que s\u00e3o cont\u00eaineres? A explica\u00e7\u00e3o breve \u00e9 que uma m\u00e1quina virtual precisa de um grande volume de mem\u00f3ria do sistema operacional, maior que o tamanho do aplicativo, enquanto um cont\u00eainer precisa apenas de algumas bibliotecas e configura\u00e7\u00f5es para executar o aplicativo. \u00c9 evidente que a m\u00e1quina virtual ainda possui \u00e1reas de aplica\u00e7\u00e3o importantes, mas o cont\u00eainer \u00e9 uma solu\u00e7\u00e3o leve para hospedagem de aplicativo, incluindo servidores de aplicativos.<\/p>\n

Embora existam outras op\u00e7\u00f5es de cont\u00eaineres, os mais populares s\u00e3o o Docker e o Kubernetes.<\/p>\n

Docker: Apache 2.0
\nKubernetes: Apache 2.0<\/p>\n

Ferramentas de automa\u00e7\u00e3o intermedi\u00e1ria<\/b><\/p>\n

Nosso pipeline DevOps \u00e9 principalmente voltado para a colabora\u00e7\u00e3o na cria\u00e7\u00e3o e deployment de aplicativos, mas h\u00e1 muitas outras coisas que podem ser feitas com ferramentas DevOps. Uma delas \u00e9 o uso de ferramentas de Infraestrutura como C\u00f3digo (IaC), que tamb\u00e9m s\u00e3o conhecidas como ferramentas de automa\u00e7\u00e3o intermedi\u00e1ria. Essas ferramentas ajudam a automatizar a instala\u00e7\u00e3o, gerenciamento e outras tarefas para middleware. Por exemplo, uma ferramenta de automa\u00e7\u00e3o pode extrair aplicativos como servidores de aplica\u00e7\u00e3o, banco de dados e ferramentas de monitoramento, com as configura\u00e7\u00f5es corretas e implant\u00e1-los em servidores de aplica\u00e7\u00e3o.<\/p>\n

Aqui est\u00e3o algumas ferramentas de automa\u00e7\u00e3o intermedi\u00e1ria de c\u00f3digo aberto:<\/p>\n

Ansible: GNU Public
\nSaltStack: Apache 2.0
\nChef: Apache 2.0
\nPuppet: Apache ou GPL<\/p>\n

\"Guia<\/p>\n

Saiba mais detalhes sobre como obter uma profiss\u00e3o em alta demanda do zero ou elevar suas habilidades e sal\u00e1rio, fazendo cursos online pagos da SkillFactory:<\/p>\n