Você está na página 1de 58
Uma proposta para centralizar praticas´ do gitlab DevOps com uso por Jonnatas Matias Ribeiro Cabral

Uma proposta para centralizar praticas´ do gitlab

DevOps com uso

por

Jonnatas Matias Ribeiro Cabral

Trabalho de Graduac¸ ao˜

Jonnatas Matias Ribeiro Cabral Trabalho de Graduac¸ ao˜ UNIVERSIDADE FEDERAL DE PERNAMBUCO ´ CIN - CENTRO

UNIVERSIDADE FEDERAL DE PERNAMBUCO

´

CIN - CENTRO DE INFORM ATICA

˜

˜

GRADUAC¸ AO EM SISTEMAS DE INFORMAC¸ AO

www.cin.ufpe.br

RECIFE, ABRIL DE 2017

UNIVERSIDADE FEDERAL DE PERNAMBUCO ´ CIN - CENTRO DE INFORM ATICA ˜ ˜ GRADUAC¸ AO
UNIVERSIDADE FEDERAL DE PERNAMBUCO ´ CIN - CENTRO DE INFORM ATICA ˜ ˜ GRADUAC¸ AO

UNIVERSIDADE FEDERAL DE PERNAMBUCO

´

CIN - CENTRO DE INFORM ATICA

˜

˜

GRADUAC¸ AO EM SISTEMAS DE INFORMAC¸ AO

Jonnatas Matias Ribeiro Cabral

´

UMA PROPOSTA PARA CENTRALIZAR PR ATICAS DEVOPS COM

USO DO GITLAB

Projeto de Graduac¸ao˜ apresentado no Cen-

tro de Informatica´ da Universidade Federal

de Pernambuco, como requisito parcial

para a obtenc¸ao˜ do grau de Bacharel em

Sistemas de Informac¸ao.˜

Orientador: Vin´ıcius Cardoso Garcia

RECIFE, ABRIL DE 2017

“A menos que modifiquemos a nossa maneira de pensar, nao˜ seremos capazes de resolver os problemas causados pela forma como nos acostumamos a ver o mundo”.

Albert Einstein

Agradecimentos

Agradec¸o a` minha fam´ılia pelo amor, dedicac¸ao˜

e paciencia.ˆ

Agradec¸o aos meus amigos pelo incentivo e apoio durante toda a graduac¸ao.˜

Agradec¸o a minha namorada Jessica´ que me apoiou nos dias que passei estudando pela noite. Ao meu L´ıder tecnico´ Arthur, que me deu um tempo para pesquisar e colocar em pratica´ alguns estudos que compoem˜ esse trabalho.

Agradec¸o ao meu orientador Vin´ıcius Garcia pela sua disponibilidade e por todo o apoio fornecido. Ao co-orientador Fish, que ajudou na ideia do projeto, alem´ de dar aquela forc¸a.

Agradec¸o a todos os professores do CIn por todo o conhecimento e dedicac¸ao˜ durante o curso.

fornecidos

E a voceˆ leitor, que doara´ um pouco do seu tempo para ler a pesquisa.

Resumo

Embora os processos ageis´ de entrega de sistemas tragam varios´ pontos positivos para

 

´

as organizac¸oes,˜ na pratica,´ varios´ problemas sao˜ encontrados em sua execuc¸ao.˜

E

necessario´ bastante esforc¸o para que o caminho de um release ate´ a disponibilizac¸ao˜ aos

usuarios´ seja todo automatizado. Nao˜ ha´ um ferramenta robusta que possa ser usada

ao longo do processo, permitindo assim, que cada organizac¸ao˜ ou projeto construa sua

propria´ infraestrutura da sua maneira, utilizando o que conhece ou tem mais facilidade de

colocar em pratica.´ Essa realidade acarreta em problemas relacionados a manutenc¸ao,˜

integrac¸ao˜ e aprendizado do uso de diferentes ferramentas.

Neste trabalho de graduac¸ao,˜ propoe-se˜ uma alternativa para as diferentes ambientes de

entrega de sistemas existentes, sugerindo a utilizac¸ao˜ de uma unica´ ferramenta proposta

que e´ o gitlab, configurada na arquitetura de servic¸os da AWS. Facilitando o gerencia-

mento de releases disponibilizados em diferentes ambientes (estagio,´ homologac¸ao˜ e

produc¸ao)˜ a partir de uma unica´ visao˜ proporcionada pela ferramenta.

Palavras-chave: DevOps, infra-estrutura, release, Deploy, AWS .

i

Abstract

Although DevOps brings several positives to organizations, in practice, several problems are encountered in its execution. It takes a lot of effort to get the road from a release to the availability to users all automated. There are a number of tools available to all parties to this process, allowing each organization or project to build its own infrastructure in its own way, using what it knows or is easier to put in practice. This reality leads to problems related to maintenance, integration and learning of the use of different tools.

In this undergraduate work, an alternative is proposed for the different existing infras- tructures, suggesting the use of a single proposed tool that is emphgitlab, configured in emphAWS services architecture. Facilitating the management of releases made avai- lable in different environments (stage, homologation and production) from a single view provided by the tool.

Keywords: DevOps, release,infrastructure, gitlab.

iii

Sumario´

1 Introduc¸ ao˜

1

1.1 Contexto .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

1

1.2 Objetivos

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3

1.2.1 Objetivos Gerais

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3

1.2.2 Objetivos Espec´ıficos

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3

1.3 Organizac¸ao˜

do Trabalho

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3

2 Conceitos

5

DevOps

2.1 .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

5

Deploy .

2.2 .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

6

2.3 Integrac¸ao˜

cont´ınua

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

6

2.4 Entrega cont´ınua

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

7

2.5 Deployment Pipeline

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

7

2.6 Microservices .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

8

2.7 Conteineresˆ

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

8

2.7.1

Docker

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

9

2.8 Django .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

9

v

2.9 GitLab

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

10

2.10 Considerac¸oes˜

Finais

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

10

3 Ambiente de Entrega Cont´ınua

 

11

3.1 do Processo de Entrega Cont´ınua

A Adoc¸ao˜

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

11

Pipeline

3.2 .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

12

3.3 The commit stage (Etapa de validac¸ao˜

das mudanc¸as no codigo)´

.

.

.

.

.

.

12

3.3.1

Controle de Versao˜

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

13

3.3.2

Build .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

13

3.4 Testes

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

14

3.5 Ambientes .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

15

3.6 Trabalho em equipe

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

15

3.7 Desafios .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

15

3.8 Ferramentas

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

16

3.8.1 Jenkins

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

16

3.8.2 Travis-CI

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

17

3.8.3 CodeShip

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

17

3.8.4 GitLab-ce (Community edition)

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

19

3.8.5 Analise das Ferramentas

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

20

3.9 Considerac¸oes˜

Finais

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

4 Construc¸ ao˜

do ambiente com a ferramenta gitlab-ce

 

22

4.1 Arquitetura

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

22

4.2 Configurando as ferramentas

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

23

vi

 

4.2.1 Configurando Gitlab server

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

24

4.2.2 Configurando Gitlab Runner

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

26

 

´

 

4.2.3 Descrevendo o Pipeline em um Unico Arquivo

.

.

.

.

.

.

.

.

.

.

.

.

29

4.3 Executando Fluxo da Ferramenta .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

31

4.4 Considerac¸oes˜

Finais

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

36

5

Conclusao˜

38

vii

Lista de Tabelas

4.1 Custos .

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

37

4.2 Custos do ambiente com gitlab

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

37

viii

Lista de Figuras

2.1

Arquitetura do docker, evidenciando o compartilhamento de

 

9

2.2

Abrangenciaˆ

da arquitetura do gitlab, evidenciando o englobamento dos

pipelines de CI e

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

10

3.1

Corpo do pipeline descrito no paragrafo acima.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

12

3.2

Precificac¸ao˜

de servic¸os do Travis-ci.[6]

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

18

3.3

Precificac¸ao˜

de servic¸os do CodeShip.[1]

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

18

3.4

Visualizac¸ao˜ das da cobertura de atapas do processo de CD proporciona-

das pelas ferramentas descritas.[6], [1], [4]

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

4.1

Ambiente proposto para o uso do gitlab.

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

23

4.2

Exemplo de VM’s que tem o Docker pre-instalado.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

24

4.3

Configurac¸oes˜

das portas ao acesso

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

25

4.4

Obtenc¸ao˜

de token para o GitLab

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

28

4.5

Primeira parte do gitlab-ci.yml.

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

29

4.6

Exibic¸ao˜

dos ambientes implementados no

 

.

.

.

.

.

.

.

.

.

.

30

4.7

Exibic¸ao˜

dos ambientes implementados no

.

.

.

.

.

.

.

.

.

.

32

4.8

Tela para analise de alterac¸oes˜

de codigo

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

34

4.9

Exibic¸ao˜

inicial da execuc¸ao˜

do pipeline

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

35

ix

4.10 Imagem de acompanhamento de execuc¸ao˜

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

35

4.11 Exibic¸ao˜

inicial da execuc¸ao˜

do pipeline

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

36

4.12 Prec¸os das VMs do servic¸o EC2 da

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

37

x

Cap´ıtulo 1

Introduc¸ ao˜

Neste cap´ıtulo sera´ apresentada a motivac¸ao˜

tivos esperados e como este trabalho esta´ estruturado, a fim de facilitar o entendimento do leitor.

deste trabalho, os obje-

para a realizac¸ao˜

1.1

Contexto

A computac¸ao˜ em nuvem (Cloud computing) e´ um modelo que permite acesso on- demand a uma rede de recursos computacionais configuraveis´ (por exemplo, redes, cpu, servidores, armazenamento, aplicativos e servic¸os) que pode ser rapidamente provisio- nado e liberado com o m´ınimo de esforc¸o de gerenciamento ou interac¸ao˜ do provedor de servic¸os [20]. Segundo o estudo [8] a computac¸ao˜ em nuvem permite que os donos desses recursos de hardware possam oferecer esses ativos em forma de servic¸o e de maneira transparente a qualquer lugar do mundo que possua internet. Assim facilitando o acesso a servidores e diversos servic¸os dispon´ıveis na web.

Recentemente, computac¸ao˜ em nuvem tem sido considerada uma tecnologia do tipo must-to-have ao inves´ de should-to-have [14]. Computac¸ao˜ em nuvem tem viabilizado flexibilidade da proposta pay-per-use contida nos modelos Software as a Service (SaaS), Platform as a Service (PaaS) e Infrastructure as a Service (IaaS). Alem´ disso a alta disponibilidade (um dos fundamentos basico´ da proposta) [20] e as diversas platafor- mas presentes atualmente (PaaS) permite que organizac¸oes˜ desenvolvam software com

1. Introduc¸ao˜

2

maior velocidade e estabilidade (alta disponibilidade), que (i) aumenta a competitividade

de organizac¸oes˜

e (ii) proporciona qualidade do ponto de vista do cliente ou consumidor.

Embora pontos importantes tenham sido apresentados, estudos recentes revelam que implantac¸oes˜ em cloud computing tem obtido um resultado inesperado [14]. Em outras palavras, o software nao˜ tem obtido a estabilidade esperada e a entrega do produto (software), na realidade, tem sido atrasada.

Esse fato esta´ diretamente relacionado a divisao˜ e barreira organizacional entre os times de desenvolvimento e operac¸oes˜ [14]. Essa realidade pode ser relacionada a custos di- retos a` organizac¸ao,˜ ao qual pode-se citar a falta de compartilhamento de conhecimento entre os times. Por exemplo, o desenvolvedor nao˜ constroi´ aplicac¸oes˜ que facilitem sua

analise´ em tempo de execuc¸ao˜ (em produc¸ao),˜ disponibilizando logs idiossincraticos´ (que apenas pessoas com o background de dev possa entender). Deste modo, possivelmente

o time de operac¸oes,˜ deve levar mais tempo (mais custo) analisando a causa de pro- blema.

Visando quebrar tais barreiras, DevOps surge com intuito de aproximar os times de de- senvolvimento e operac¸ao˜ mantendo a visao˜ agil,´ ”DevOps e´ um conjunto de praticas´ destinada a reduzir o tempo entre o efetuar uma alterac¸ao˜ em um sistema ate´ que a alterac¸ao˜ seja colocada em Produc¸ao,˜ assegurando ao mesmo tempo qualidade ”. Tendo em vista que de uma pequena alterac¸ao˜ no codigo´ ate´ chegar em produc¸ao,˜ deve pas- sar por diversas etapas do processo de desenvolvimento, o conjunto dessas etapas e´ conhecido como pipeline.

Um pipeline de entrega de sistema e´ constitu´ıdo de varias´ etapas, que sao˜ desenvol-

ver o codigo,´ armazena-lo´ em uma ferramenta de configurac¸ao˜ de codigo,´ revisar, testar, validar e colocar o codigo´ em produc¸ao.˜ Como descrito no artigo DevOps and Its Prac- tices IBM [10] existem diversas ferramentas para cada parte especificas desse pipeline

e a integrac¸ao˜ desse codigo´ e´ “hand-tailored” algo feito a mao˜ pelos desenvolvedores.

Nao˜ ha´ uma ferramenta que abrace todas as etapas desse processo de entrega de siste- mas. Com isso gera um grande esforc¸o para distribuic¸ao˜ de conhecimento, manutenc¸ao,˜ gerenciamento e visualizac¸ao˜ das ferramentas e praticas´ em uso.

1. Introduc¸ao˜

3

1.2 Objetivos

1.2.1 Objetivos Gerais

O objetivo dessa pesquisa e´ propor um ambiente efetivo para o uso dos processos De-

vOps, propondo o uso de uma ferramenta que engloba uma maior parte dos processos de entrega cont´ınua. Demonstrando os processos que nos dao˜ base a` construc¸ao˜ de um ambiente de entrega cont´ınua. Abordando ferramentas dispostas no mercado, e seus re- cursos. Por fim demonstrar como criar um ambiente de uso para a ferramenta escolhida, fazendo uso de uma aplicac¸ao˜ web exemplo que percorra o fluxo proposto.

1.2.2 Objetivos Espec´ıficos

Fazer um estudo acerca dos conceitos DevOps, e explorar dos processos de en- trega cont´ınua;

Fazer um estudo sobre ferramentas de entrega cont´ınua dispostas no mercado ;

Implementar e analisar um ambiente de entrega cont´ınua que use uma ferramenta que auxilie uma maior parte do processo. Observar os benef´ıcios ao aderir tal ferramenta. E por fim demonstrar como utilizar o fluxo de entrega cont´ınua de uma aplicac¸ao˜ web de exemplo, usando a ferramenta proposta.

1.3 Organizac¸ ao˜

do Trabalho

O presente trabalho esta´ organizado em 5 cap´ıtulos, dos quais o primeiro e´ a introduc¸ao˜

e os proximos´

4 cap´ıtulos estao˜

descritos abaixo:

No Cap´ıtulo 2 e´ apresentado um conjunto de definic¸oes˜ mento do trabalho;

relevantes para o entendi-

O cap´ıtulo 3 e´ responavel´ pelo entendimento de como funciona os de continuous Integration e Continuous Deployment nas empresas e quais sao˜ os maiores proble- mas enfrentados devido a essa decisao;˜

1. Introduc¸ao˜

4

O cap´ıtulo 4 apresenta uma proposta para implantac¸ao˜ tiva para o aux´ılio no processo de CI e CD.

de uma ferramenta alterna-

O cap´ıtulo 5 apresenta as conclusoes˜

retiradas de toda a pesquisa.

Cap´ıtulo 2

Conceitos

Este cap´ıtulo e´ responsavel´ por apresentar conceitos chave para o melhor entendimento

deste trabalho, trazendo a definic¸ao˜ dos conceitos e uma visao˜ geral sobre os seguin-

tes temas: DevOps , Continuous Deployment e Deployment Pipeline, microservices,

Django,Docker e o gitlab.

2.1

DevOps

O DevOps trata de processos de desenvolvimento e entrega de sistemas com um foco

no agil.´ Ele integra eficientemente as areas´ de desenvolvimento e operac¸oes,˜ facilitando

assim uma conexao˜ flu´ıda dessas areas´ tradicionalmente separadas [12].

´

E

uma mudanc¸a organizacional em que, em vez de grupos distribu´ıdos desempenhando

func¸oes˜ separadamente, equipes multifuncionais trabalham em entregas de recursos

operacionais cont´ınuos. Essa abordagem ajuda a fornecer valor de forma mais rapida´

e cont´ınua, reduzindo problemas devido a` falta de comunicac¸ao˜ entre os membros da

equipe acelerando a resoluc¸ao˜ de problemas.

2. Conceitos

6

2.2 Deploy

O termo deploy, no contexto de desenvolvimento de software, significa a ac¸ao˜ de dispo-

nibilizar seu software na nuvem ou em qualquer ambiente que possa ser utilizado pelos seus usuarios. O deploy e´ realizado em uma serie´ de etapas sequenciais, assim como uma receita de bolo, com o proposito´ de atualizar um sistema, ou disponibilizar um sis- tema completamente novo [17]. As etapas de um deploy vao˜ depender da arquitetura do sistema e da infra-estrutura utilizada.

2.3 Integrac¸ ao˜

cont´ınua

A integrac¸ao˜ cont´ınua foi escrita pela primeira vez no livro de Kent Beck, Extreme

Programming Explained (publicado pela primeira vez em 1999). A ideia´ por tras´ da integrac¸ao˜ cont´ınua era que, se a integrac¸ao˜ da sua base de codigo´ e´ bom, por que nao˜ faze-loˆ o tempo todo? No contexto de integrac¸ao,˜ ”todo o tempo”significa cada vez que alguem´ efetua qualquer alterac¸ao˜ ao sistema de controle de versao˜ [17].

As boas praticas´ de CI exigem que todos os desenvolvedores enviem seu trabalho para um repositorio´ de codigo´ comum em uma base diaria.´ Alem´ do que, apos´ cada integrac¸ao,˜ o sistema deve ser reconstru´ıdo e testado, para garantir que o sistema ainda esteja funcional apos´ cada alterac¸ao˜ [13]. Assim os desenvolvedores podem continuar seu trabalho em cima das alterac¸oes˜ feitas e aprovadas.

As organizac¸oes˜ que aderem a` pratica´ de integrac¸ao˜ cont´ınua de forma eficaz sao˜ capa- zes de desenvolver um software muito mais rapido,´ e com menos bugs, do que os times que nao˜ utilizam. Os bugs sao˜ detectados muito mais cedo no ciclo de entrega, quanto mais rapido´ essa detecc¸ao˜ menos custoso e´ para soluciona-lo,´ representando uma sig- nificativa economia de custos e tempo. Por isso, essa pratica´ e´ considerada essencial, e para os paradigmas enfrentados pelas organizac¸oes˜ hoje em dia talvez seja uma pratica´ tao˜ importante quanto usar o controle de versao˜ no desenvolvimento.

2. Conceitos

7

2.4 Entrega cont´ınua

A entrega cont´ınua (CD) e´ uma disciplina de desenvolvimento de software em que estuda

como o software pode ser disponibilizado para a produc¸ao˜ a qualquer momento [15]. O Continuous Deployment e´ uma extensao˜ do CD em que cada alterac¸ao˜ e´ constru´ıda, testada e implantada automaticamente na produc¸ao.˜ Assim, em contraste com CD, nao˜

ha´

etapas ou decisoes˜ manuais entre um commit de desenvolvedor e uma implantac¸ao˜

de

produc¸ao.˜ A motivac¸ao˜ para automatizar a implantac¸ao˜ na produc¸ao˜ e´ Obter feedback

mais rapido´ do uso da produc¸ao˜ para corrigir defeitos ficam caros com o mais tardar da detecc¸ao.˜

A

diferenc¸a entre CI e CD e´ mais destacada na Fig. 2.2, onde se mostra que, embora o

CI

seja constitu´ıdo por apenas uma unica´

gase, o CD consiste em varios´

estagios´

que

verificam se o software esta´ em condic¸oes˜

de ser disponibilizado para uso [15].

2.5 Deployment Pipeline

Em um n´ıvel abstrato, ”o Deployment Pipeline e´ uma execuc¸ao˜ automatizada do todo

o seu processo para ,entregar o software nas maos˜ ferramenta de controle de versao”.˜ [17].

a partir de uma

de seus usuarios,´

Toda mudanc¸a em seu software passa por um processo complexo no corpo do De- ployment Pipeline ate´ ser aprovada. Esse processo envolve a construc¸ao˜ do software

(build), seguido de progressos destas compilac¸oe˜ atraves´ de multiplos´ estagios´ de testes

e implantac¸ao.˜ Este, por sua vez, requer colaborac¸ao˜ entre muitos indiv´ıduos, e talvez

equipes. O pipeline de implantac¸ao˜ modela este processo em uma ferramenta de ge- renciamento de releases e integrac¸ao˜ cont´ınua e´ o que permite controlar o progresso de cada mudanc¸a a` medida que se move do controle de versao˜ para varios´ conjuntos de testes e implementac¸oes˜ para liberar aos usuarios.´

2. Conceitos

8

2.6 Microservices

A arquitetura monol´ıtica e´ um padrao˜ comumente usado para o desenvolvimento de

aplicac¸oes˜ de grandes empresas.”Esse padrao˜ funciona razoavelmente bem para peque-

nas aplicac¸oes,˜ pois o desenvolvimento, testes e implantac¸ao˜ de pequenas aplicac¸oes˜

monol´ıticas e´ relativamente simples”[21]. No entanto, para aplicac¸oes˜ mais complexas,

acabam dificultando a utilizac¸ao˜ de uma entrega cont´ınua, devido a uma grande quan-

tidade de componentes que estao˜ dentro da aplicac¸ao.˜ Para aplicac¸oes˜ desse porte e´

interessante dividi-la em um conjunto de servic¸os.

A arquitetura de microservices tem muitas vantagens, por exemplo, servic¸os individuais

sao˜ mais faceis´ de entender e podem ser desenvolvidos e implantados de forma indepen-

dente. Adotar novas tecnologias e frameworks torna-se mais facil,´ pois a adoc¸ao˜ pode

˙

ser aplicada em um servic¸o de cada vez Ao escolher o uso de uma arquitetura de micro-

services A aplicac¸ao˜ e´ decomposta em diversos servic¸os de front end, que implementam

diferentes partes da interface do usuario´ e multiplos´ servic¸os de back end [19].

2.7 Conteineresˆ

Usando conteineresˆ para receber seu projeto, tudo o que e´ necessario´ para fazer um

pedac¸o de sistema executado e´ empacotado em conteineresˆ isolados. Ao contrario´ das

maquinas´ virtuais, os conteineresˆ nao˜ agrupam um sistema operacional completo, ape-

nas sao˜ necessarias´ bibliotecas e configurac¸oes˜ necessarias´ para que o trabalho do soft-

ware seja necessario.´ Isso faz com que sistemas eficientes, leves e autonomosˆ garantam

que o software sempre seja o mesmo, independentemente de onde ele e´ implantado [2].

A ideia por tras´

de projetos, ao fazer o uso dessa tecnologia. Permitindo assim que esses conteineresˆ

e´ permitir unificar o deploy de diferentes tipos

do uso de conteineresˆ

funcionem em diferentes tipos de sistemas operacionais.

2. Conceitos

9

2.7.1

Docker

O Docker surgiu como uma das grandes forc¸as para o DevOps, e´ uma ferramenta que

permite a criac¸ao˜ de microservices e facilita a configurac¸ao˜ de diversos ambientes de desenvolvimento [7]. Assim como na sua descric¸ao:˜

O Docker e´ a principal plataforma de conteineresˆ de software no mercado. Os desenvol-

vedores usam o Docker para eliminar os problemas da famosa frase ”funciona na minha maquina”ao´ colaborar no codigo´ com colegas de trabalho. Os operadores usam o Docker para executar e gerenciar aplicativos lado a lado em recipientes isolados para obter uma melhor densidade de computac¸ao.˜ As empresas usam o Docker para criar pipelines de entrega de software agil´ para enviar novos recursos de forma mais rapida,´ segura e com confianc¸a para aplicativos Linux e Windows Server [2].

confianc¸a para aplicativos Linux e Windows Server [2]. Figura 2.1: Arquitetura do docker, evidenciando o

Figura 2.1: Arquitetura do docker, evidenciando o compartilhamento de recursos.

2.8

Django

O Django e´ um framework web que sera´ usado na execuc¸ao˜ do ambiente proposto na

pesquisa. ”O Django e´ um framework Python Web de alto n´ıvel que incentiva o desen- volvimento rapido´ e o design limpo e pragmatico”[3].´ A idea do framework e´ facilitar o desenvolvimento de aplicac¸oes˜ web, servindo diversas funcionalidades basicas´ que esse tipo de projeto exige, tais como autenticac¸ao˜ de usuario´ e formularios,´ alem´ de criar uma interface com alguns bancos de dados, com isso o desenvolvedor nao˜ precisa se preocupar em entender consultas em SQL, basta ter conhecimento da ferramenta e da linguagem python.

2. Conceitos

10

2.9