Fundamentos da Integração Contínua

1
FUNDAMENTOS DA INTEGRAÇÃO CONTÍNUA: AUTOMAÇÃO NA GERAÇÃO DE
BINÁRIOS E IMPLANTAÇÃO DE SOFTWARE
Átilla Silva Barros
Professor orientador: Ms. Thiago Chierici Cunha
MBA em Arquitetura de Software
Resumo
Atualmente, é comum que empresas realizem entregas do software seguindo
processos ágeis. A medida que o processo de desenvolvimento e entrega amadurece,
os processos são documentados e os responsáveis pela implantação do sistema
seguem uma rotina para efetuar a implantação, mas não são todos os casos. Também
há empresas que possuem responsáveis pela implantação e o processo não é
documentado. Este estudo expõe os impactos da automação do processo de geração
de binários e implantação de software, utilizando ferramentas/frameworks que servirão
de base para a automação e execução de todo o processo. Um estudo de caso com
um projeto open source é utilizado como procedimento técnico e obtenção dos
resultados, sendo uma pesquisa aplicada como natureza, fazendo uma abordagem
qualitativa. O procedimento amostral é baseado em um projeto relativamente pequeno,
sendo necessário vários processos para implantação de cada módulo. A automatização
destes processos possibilitará à empresa implantações mais rápidas, frequentes e
menos passíveis de erros humanos, garantindo feedbacks constantes de todo o
processo, aumentando autonomia da equipe e receber o investimento de volta.
Palavras-chave: Integração Contínua, Entrega Contínua, DevOps, Ágil.
Abstract
Nowadays, it’s common that businesses deliver software following agile standards. As
the development and delivery process evolves, the processes become documented and
the team responsible for system deployment follow a routine to deploy the system, but
not in all cases. In some cases, there are companies that have deployment staff and the
processes are not documented. This paper exposes the pros and cons of the build in
one step, using tools/frameworks that will support the automation and the whole
execution. A study case with an open source project is used as technical procedure and
for getting results, as an applied research is its origin and follow a qualitative approach.
The sampling procedure is based on a small project, as it needs many ways to deploy
its modules. These processes automation will allow faster, frequent and less liable to
human error deployments for the company, allowing constant feedbacks of the entire
process, increasing team autonomy and get paid back.
Keywords: Continuous Integration, Continuous Delivery, DevOps, Agile.

2
1. INTRODUÇÃO
A medida que a tecnologia evolui, software vem se tornando indispensável no dia-a-dia
das pessoas, fazendo com que novos produtos e empresas surjam diariamente e a
indústria tenha cada vez mais crescimento (CAFFERY et al, 2007; ARGENTO;
HAMILTON, 2009; SATO, 2013). Diante da evolução das metodologias de
desenvolvimento de software, ainda assim o processo de transformação de ideias em
código envolve atividades como levantamento de requisitos, design, arquitetura,
implementação, teste e entrega (SATO, 2013).
As metodologias ágeis surgiram com o objetivo de organizar as atividades de
desenvolvimento de software para que elas sejam realizadas no menor tempo possível
e garantindo qualidade, obtendo feedback constante e rápido, fazendo com que a
satisfação dos clientes seja prioridade da empresa (RASMUSSON, 2010). Contudo, o
processo de entrega de uma versão do software ainda é bastante manual em muitos
projetos (HUMBLE; FARLEY, 2014).
Dois papéis no processo são detectados na separação de responsabilidades,
são eles: desenvolvimento e operações. A equipe de desenvolvimento é responsável
pela criação e manutenção do código e publicação dos binários em um local que esteja
disponível para a equipe de operações. Esta equipe, por sua vez, é responsável por
realizar a implantação (deploy é o termo comumente conhecido) dos artefatos em seus
respectivos servidores, além de criar, manter e monitorar esses servidores (SATO,
2013).
Realizar a implantação de um software seguindo processos em suma é
complexo, onde cada atividade deve ser executada seguindo uma ordem específica
para evitar possíveis problemas e nenhum erro humano pode ser cometido, fazendo
com que o sistema funcione como deve (HUMBLE; FARLEY, 2014). Essa
complexidade gera aflição ao realizar um deploy, fazendo com que a frequência
diminua e a entrega passe a ser mais cheia de mudanças, consequentemente
aumentando as chances da versão do software não agregar o valor desejado pelo

3
cliente (SATO, 2013). Esse risco pode ser evitado realizando as entregas em um
processo automatizado, frequente e previsível (HUMBLE; FARLEY, 2014).
A entrega contínua aborda justamente esses problemas. Pode-se dizer que
entrega contínua é uma disciplina de desenvolvimento de software que trata a
construção do software como se ele pudesse ser liberado para produção a qualquer
momento (FOWLER, 2013 [A]). Será possível atingir esse feito a partir do momento em
que as mudanças realizadas no código-fonte forem enviadas para um ambiente
espelho de produção e toda a suíte de testes automatizados sejam executadas e a
qualidade do código seja analisada gerando os respectivos indicadores após a
execução. A construção e execução de tudo isso, então, poderá ser realizada com um
simples apertar de um botão (HUMBLE; FARLEY, 2014).
Os benefícios de se automatizar esses processos são frequentemente citados
por vários autores, como aumentar a autonomia da equipe; reduzir custos; priorização
e aumento na qualidade do código; feedback constante; aumento da satisfação do
cliente; entregas frequentes e confiáveis (FOWLER, 2013 [A]; SATO, 2013; HUMBLE;
FARLEY, 2014; CHEN, 2015).
Vários trabalhos apresentam os conceitos de entrega contínua, mostrando os
pontos positivos e negativos (CHEN, 2015; GMEINER et al, 2015; NEELY; STOLT,
2013), porém, as abordagens são de toda a disciplina de Entrega e Integração
Contínua. Grande parte das empresas possuem processos consolidados, mesmo que
em melhoria contínua, mas como poderiam mudar todo seu processo de
desenvolvimento e implantar a metodologia de uma só vez?
Este estudo tem como objetivo apresentar uma abordagem rápida de se
implantar Integração Contínua num escopo reduzido da disciplina, composto por um
estudo de caso utilizando tecnologias diferentes e mostrar em quanto tempo o
investimento feito na automatização retornará para a instituição.
Metodologias foram utilizadas como base deste estudo (seção 2). Uma revisão
de literatura das principais referências (seção 3) e um estudo de caso (seção 4) foi feito
para obtenção de resultados (seção 5) e conclusões (seção 6).

4
2. METODOLOGIA
Foi adotado como procedimento técnico para esta pesquisa um estudo de caso. Os
resultados apresentados na pesquisa serão obtidos através de estudo de caso e
análise das informações de diversos autores especialistas em Integração Contínua,
sendo a natureza do estudo uma pesquisa aplicada para auxiliar as empresas na
adoção da metodologia em seu contexto atual.
Foram feitas pesquisas sobre automação no processo de geração de binários e
implantação de software e entrega contínua em geral, seguindo uma abordagem
qualitativa sobre as análises do estudo de caso, onde as buscas ocorreram no período
de janeiro de 2017 a abril de 2017. O procedimento amostral do estudo baseia-se em
um projeto relativamente pequeno e open source devido a facilidade de se mensurar a
aplicação da proposta, desconsiderando um projeto grande corporativo pela
complexidade de aplicação se comparado ao projeto escolhido.
O referencial teórico foi obtido através de buscas na base de dados do Google
Acadêmico, Biblioteca Digital de Teses e Dissertações da USP, Banco de Teses e
Dissertações CAPES, Biblioteca Digital da Unicamp, Biblioteca Digital Brasileira de
Teses e Dissertações com as palavras-chave: DevOps, Entrega Contínua, Integração
Contínua, Implantação Contínua, Plano de Implantação, Desenvolvimento Ágil e suas
respectivas representações em inglês.
3. REVISÃO DE LITERATURA
Automação é uma das chaves para colher os benefícios da Entrega Contínua, assim o
processo torna-se frequente. Com uma frequência maior, as versões terão menos
riscos de impactos/incompatibilidade com versões anteriores, serão menores, a entrega
será mais fácil e o feedback mais rápido (DUVALL et al, 2007). Para que seja possível
ter essa frequência maior, será exigido do time que o software esteja sempre pronto
para produção, funcionando e com o máximo de qualidade possível (HUMBLE;

5
FARLEY, 2014).
A Integração Contínua (IC) do software é a chave para alcançar a essa garantia.
Essa prática exige a integração do código-fonte com o processo de geração de binários
e a execução automatizada de testes durante todo o processo de desenvolvimento do
software (FOWLER, 2013 [A]). A origem da IC foi como uma das práticas da
metodologia ágil extreme programming (XP) (MEYER, 2014), sendo necessário uma
mudança de paradigma nos processos e exige que as equipes envolvidas durante a
construção do software tenham ciência de que quanto mais tempo as mudanças ficam
sem se integrarem, as chances de ocorrência de conflitos só aumentam (SATO, 2013).
Se a integração frequente do código-fonte é boa, então isso deve ser realizado o tempo
todo (BECK, 1999).
Ainda que haja muitas recomendações, não existe uma receita fixa para se
implantar IC, e muitas coisas dependerão do contexto e ambiente organizacional da
empresa e das pessoas envolvidas (FOWLER, 2013 [A]). Contudo, existem alguns
pré-requisitos básicos para a criação do ambiente (HUMBLE; FARLEY, 2014). Estas
premissas são divididas em três partes e são representadas abaixo.
3.1 Versionamento
O processo de gerenciamento de liberação e entrega de software possui várias
atividades, uma delas é o controle de versão, sendo que tudo isso faz parte da
Gerência de Configuração de Software (GCS) (IEEE, 2005 [A]). No processo de GCS é
possível armazenar, identificar, modificar e recuperar artefatos sempre que necessário
(HUMBLE; FARLEY, 2014).
O versionamento garante que múltiplas versões de um arquivo estejam
armazenados, podendo então o arquivo sofrer modificações e versões anteriores
serem recuperadas. Esse é um dos principais mecanismos utilizados pelo time durante
a construção e entrega do software (HUMBLE; FARLEY, 2014). Garantir a integridade
de todos os artefatos de um produto em todos os seus aspectos é o objetivo do

6
controle de mudanças (IEEE, 2005 [A]). Dessa forma é possível fazer um
acompanhamento e gerenciar as modificações que são realizadas durante a
construção e manutenção do software (SALES et al, 2009).
3.2 Build e deploy automatizados
No gerenciamento da construção acopla-se todas as atividades referentes à construção
e entrega do software, onde todas as tarefas de geração de binários (build), entrega
(delivery) e implantação (deploy) são destacadas (SALES et al, 2009).
3.2.1 Geração de binários
A execução do build automatizado não é simplesmente compilar os arquivos (DUVALL
et al, 2007). O gerenciamento de dependências também faz parte do processo de build,
assim como a execução de testes automatizados, análise estática do código, geração
de percentual de cobertura, documentação e o deploy (SATO, 2013; HUMBLE;
FARLEY, 2014). Seja por linha de comando, script ou por meio de algum sistema de
IC, o processo de geração de binários deve ser realizado de forma automatizada
O servidor de IC é responsável por monitorar o repositório do código-fonte
versionado e iniciar um novo build sempre que for detectado alguma alteração (check
in), ou seja, sempre que houver uma mudança no código-fonte todas as rotinas
automatizadas serão executadas para garantir que após aquela alteração o software
continuará funcionando corretamente (SATO, 2013). Entende-se a infraestrutura
quando se tem um servidor de IC na figura 1 ilustrada por Duvall et al (2007).
Há dois possíveis resultados após realizar-se um build através do servidor de IC.
A primeira é o sucesso na execução, fazendo com que aquele commit torne-se uma
versão candidata a ser implantada nos respectivos servidores (testes, homologação
e/ou produção); e a segunda é a falha na execução, resultando em um aviso imediato

7
Figura 1: Infraestrutura de componentes com um servidor de IC.
Fonte: DUVALL et al, 2007. (Adaptado pelo autor).
aos responsáveis pelo código-fonte (FOWLER, 2013 [B]; HUMBLE; FARLEY, 2014).
3.2.2 Testes automatizados
Todos os testes deverão ser construídos para que sua execução em conjunto seja
rápida, confiável e acessível (NEELY; STOLT, 2013). Automatizando os testes
garante-se feedback instantâneo sobre o sistema e torna a equipe segura para realizar
seu trabalho com o código-fonte (BERNARDO; KON, 2008). A criação e manutenção
de testes devem ser prioridades na construção de um software, sendo praticadas
durante todo seu desenvolvimento e desta forma atingir uma alta qualidade do código
A quantidade de tempo gasto com identificação e correção de erros diminuirá
com os testes automatizados e os feedbacks constantes proporcionados pelo servidor
de IC (BERNARDO; KON, 2008). Um detalhe estratégico importante no avanço da
construção do software é que, para cada novo estágio do projeto, o custo com

8
correções aumenta exponencialmente dez vezes, ou seja, corrigir os defeitos durante o
desenvolvimento é mais barato do que serem corrigidos em estágios mais avançados
ou com o software em produção (MYERS et al, 2011). Ainda, mesmo com este
aumento grande de custo, muitas empresas simplesmente ignoram a fase de testes
(DE SOUZA; GASPAROTTO, 2013).
Vale lembrar que os testes manuais continuam tendo seu valor, mesmo com
todos os processos automatizados. Os cenários mais comuns poderão ser facilmente
garantidos com a automação dos testes de forma eficaz, desta forma os analistas de
testes poderão trabalhar mais tempo com os cenários incomuns e com testes
exploratórios (GMEINER et al, 2015). Com os processos de testes, geração de binários
e implantação automatizados é identificado um pipeline de implantação, isto é, agora
existe maneira automática do processo de levar o software do código-fonte versionado
até o usuário de uma maneira tão simples quanto o apertar de um botão (HUMBLE;
FARLEY, 2014).
3.3 Cultura do time
O envolvimento de todos do time no processo de IC é essencial e esse envolvimento
começa quando todos compreendam que IC é uma prática, não uma ferramenta, e que
além das ferramentas selecionadas exige-se muita disciplina da equipe. A
comunicação eficaz entre os membros do time também é de extrema importância para
se ter entregas rápidas e com qualidade (ADBUL; FHANG, 2012; HUMBLE; FARLEY,
2014).
Uma das principais filosofias de IC é o monitoramento dos builds, onde o time
deverá acompanhar toda construção iniciada até o fim e, caso o processo falhe, o
responsável pare tudo que esteja fazendo e se envolva para consertar o código e
iniciar um novo build estável (MEYER, 2014; HUMBLE; FARLEY, 2014). Dessa forma
será possível deixar o restante do time trabalhando normalmente e integrando novas
mudanças no ambiente de desenvolvimento (ABDUL; FHANG, 2012).

9
As equipes podem atingir os objetivos trabalhando em conjunto e com um nível
de qualidade e controle muito mais alto com a implantação de IC (HUMBLE; FARLEY,
2014). De acordo com Fowler (2006 [A]), Duvall et al (2007) e Humble and Farley
(2014), alguns dos benefícios da implantação de IC são: garantia de qualidade do
produto; redução de erros e riscos; flexibilidade de implantação; redução de processos
manuais repetitivos e passíveis de erros humanos; entregas confiáveis e aumento da
satisfação e visibilidade do projeto por parte dos clientes. Atendendo os pré-requisitos
será possível usufruir de todos os benefícios do ambiente de IC.
4. APRESENTAÇÃO DA PESQUISA
Integração e entrega contínua de software são de interesse de várias empresas. Nos
dias de hoje há empresas especializadas em consultorias DevOps e atendem uma
vasta gama de clientes. A necessidade de uma consultoria especializada se dá pelo
fato de que não se implanta uma metodologia de um dia para o outro, mudando muitos
processos, infraestrutura e cultura das equipes (NEELY; STOLT, 2013).
Mesmo que para muitas empresas a implantação de IC seja cara, muitas ainda
optam por sua implantação. Por outro lado algumas empresas optam por não mudar
seus processos e infraestrutura pelo mesmo motivo: pode ser financeiramente inviável.
Porém, os benefícios são de consenso entre as principais referências e autores sobre o
assunto (HUMBLE; FARLEY, 2014; CHEN, 2015; ABDUL; FHANG, 2012; SATO,
2013).
Com o objetivo de orientar quem deseja implantar a disciplina de IC, o presente
trabalho apresenta algumas maneiras eficazes para se começar essa implantação do
zero, mesmo que ainda considere alguns pré-requisitos que são comuns no meio
corporativo durante o processo. Começamos a estruturar um ambiente de IC instalando
um servidor.
Com um servidor de IC é possível automatizar os processos de geração de
binários e implantação do software. Os servidores de IC podem monitorar repositórios e

10
iniciar o processo de build sempre que houver mudanças. Há vários servidores de IC,
dentre os principais - Jenkins, TeamCity e CruiseControl - o Jenkins é o servidor com
mais aderência pela comunidade e é o servidor de IC utilizado neste trabalho (PINTO;
TERRA et al, 2015; SATO, 2013; CI, 2017 [A]). Para que o servidor consiga monitorar
um repositório ou, mesmo sem um monitoramento de alterações, iniciar uma
construção quando solicitado pelo usuário é necessário que se tenha gerência de
configuração. É obrigatório ter tudo que for necessário para a construção do software
sob um controle de versão.
A estratégia utilizada para a GCS determinará como são gerenciadas as
mudanças que ocorrem no projeto. É na GCS que acompanhamos a evolução do
sistema, além de controlar a forma que o time colabora. É de extrema necessidade a
adoção de um sistema de controle de versão como o GIT, SVN ou outro semelhante
(HUMBLE; FARLEY, 2014). O presente estudo de caso baseia-se na automatização do
build e deploy de um projeto open source hospedado em um repositório versionado
com a tecnologia GIT e pode ser acessado no site do host (GITHUB, 2017 [A]).
Uma recomendação é que todo o processo de build e deploy sejam feitos em um
ambiente com as mesmas configurações do ambiente de produção para evitar
problemas relacionados a diferença nos ambientes. Isso é mais um motivo para se
manter sob a GCS toda configuração relacionada ao ambiente de execução do
software (HUMBLE; FARLEY, 2014).
Para a criação de um ambiente semelhante ao de produção o estudo faz uso de
uma máquina virtual (VM) no provedor DigitalOcean (DIGITALOCEAN, 2017 [A]). Para
que seja feito uma atualização do projeto é necessário acessar a VM e executar os
comandos de build e deploy manualmente, além de atualizar o código-fonte que servirá
de base para os processos. Começamos a automatização documentando todos os
passos executados manualmente para que seja possível padronizar e reproduzir
sempre que necessário através do servidor de IC (HUMBLE; FARLEY, 2014; SATO,
2013). Ao servidor com um usuário que tenha permissões para reiniciar processos do
sistema operacional (SO), os passos para atualização do software são os seguintes:

11
1. Finalizar os processos do SO relacionados ao servidor do primeiro projeto
(notes-api).
2. Finalizar os processos do SO relacionados ao servidor do segundo projeto
(notes-web).
3. Acessar o diretório do código-fonte versionado e realizar o checkout das
atualizações.
4. Acessar o diretório raiz e iniciar os processos do SO relacionados ao servidor do
projeto notes-api (não é necessário geração de binários neste projeto).
5. Acessar o diretório raiz e executar o processo de build do projeto notes-web (o
projeto necessita de compilação para a geração de binários).
6. Atualizar os binários gerados do projeto notes-web no respectivo servidor.
7. Iniciar os processos do SO relacionados ao servidor do projeto notes-web.
O Quadro 1 apresenta os comandos utilizados para realização dos passos
mencionados no sistema operacional em que o software está implantado (Linux). Cada
passo será detalhado a seguir com uma introdução às ferramentas envolvidas.
Quadro 1. Comandos utilizados em cada passo.
Comandos
Passo 1 sudo pm2 stop www
Passo 2 sudo service nginx stop
Passo 3 cd /home/atilla8huno/mean2-course/
sudo git pull
Passo 4 cd notes-api/
sudo pm2 start www
Passo 5 cd ../notes-web/
sudo ng build --prod
Passo 6 sudo rm -rf /var/www/notes-web/html/*
sudo cp -a ./dist/. /var/www/notes-web/html/
Passo 7 sudo service nginx start
Fonte: o autor, 2017.

12
No primeiro passo é necessário parar a execução do servidor do projeto
notes-api. Este projeto foi desenvolvido na linguagem JavaScript, utilizando a
plataforma Node.js (NODE.JS, 2017 [A]). Para a execução do sistema é utilizado o
PM2, um sistema de execução multithread desenhado para suportar várias aplicações
simultaneamente. Essas aplicações podem ter suas threads arbitrariamente finalizadas
durante a execução, mesmo que o sistema esteja com um fluxo grande de requisições.
O PM2 provê um controle eficiente dessas threads, podendo reiniciar a execução de
um processo quando o mesmo é finalizado irregularmente (ANTONIU; BOUGÉ;
NAMYST, 1999).
O projeto notes-web, como o nome sugere, é um projeto web com interfaces que
são acessadas através de um browser que submete requisições HTTP para o servidor.
No passo 2 é necessário parar a execução do servidor web que hospeda o sistema. O
Nginx é o servidor utilizado. A arquitetura do Nginx foi projetada para aproveitar ao
máximo os recursos do hardware, sendo mais leve e rápido que a maioria dos
servidores concorrentes (RAHUL, 2016).
Após parar a execução de todos os servidores é necessário atualizar o
código-fonte local (no servidor) no terceiro passo. Dentre várias ferramentas de
controle de versão (SCM), GIT é utilizado no projeto por oferecer suporte ao
desenvolvimento centralizado e distribuído, além de ser o SCM utilizado no host GitHub
(PINTO; TERRA, 2015).
O projeto notes-api foi desenvolvido como o backend da aplicação. Escrito em
JavaScript não é necessário nenhum processo de compilação para sua execução na
plataforma Node.js. No passo 4, após realizar checkout do código atualizado, é
iniciado o processo PM2 correspondente ao projeto, fazendo com que o servidor passe
a receber novas requisições.
Finalizado o processo de reinicialização do servidor com as APIs do projeto
notes-api é necessário iniciar o processo de geração de binários do projeto notes-web.
No quinto passo é executado o comando para geração do build. O projeto foi
desenvolvido com as tecnologias Angular e TypeScript, e a ferramenta utilizada para a

13
compilação é a Angular Command Line Interface (angular-cli), que torna o processo de
geração de binários muito mais fácil, já que é necessário fazer o processo de
transpiling do código TypeScript para JavaScript antes de servir a aplicação em um
servidor web (JAMEEL; KHANNA; RANGAPPA; PATIL; KHALKAR, 2017; ANGULAR,
2017 [A]).
Uma vez gerado os artefatos do sistema é necessário atualizá-los no respectivo
servidor, o que é feito no passo número 6. É executado um comando para remover os
artefatos antigos no diretório do Nginx e logo em seguida faz-se a cópia dos novos
artefatos para a pasta. Após atualização o servidor é reiniciado no sétimo passo.
Todos os passos executados estão documentados e prontos para serem
automatizados no servidor de IC. O próximo passo é a instalação e configuração do
Jenkins.
A função mais básica de uma ferramenta de IC é o monitoramento do
código-fonte em um sistema de controle de versão e iniciar um build após alguma
mudança (SMART, 2011). O servidor de IC deve executar uma série de atividades
predefinidas para realizar o build automatizado e os desenvolvedores devem manter
esse processo o mais rápido possível (FARLEY; HUMBLE, 2014). O projeto do estudo
de caso está em um repositório no GitHub e será configurado o monitorando após a
instalação (GITHUB, 2017 [A]).
Para que seja possível instalar o servidor de IC é necessário configurar o
ambiente de execução. O Jenkins é uma aplicação Java web e necessita do Java
Runtime Environment (JRE) instalado para executar as aplicações corretamente
(SMART, 2011). Os instaladores e passo-a-passo de instalação são disponibilizados no
site do Java (JAVA, 2017 [A]). O servidor web que o Jenkins será hospedado é o
Tomcat. Diversos autores introduzem maneiras de instalar o Jenkins no Tomcat
(SATO, 2013; SMART, 2011; HUMBLE; FARLEY, 2014). A maneira específica de um
SO também pode ser acessada na documentação oficial do Jenkins (JENKINS, 2017
[A]). Seguindo os passos para instalação do servidor de IC e selecionando plugins
recomendados podemos iniciar as configurações da automatização (FIG. 2).

14
Figura 2: Página inicial do Jenkins.
Com o servidor de IC instalado inicia-se o processo de configuração da
ferramenta para atender o cenário do projeto na implantação automatizada. Para
facilitar o manuseio da ferramenta a configuração de idioma foi definida na linguagem
português do Brasil. No menu lateral esquerdo, opção “Gerenciar Jenkins”, ilustrado na
FIG. 2, pode-se configurar os plugins, segurança, acessar logs, manipular a
configuração geral do Jenkins e outras opções (SMART, 2011).
Após passar pelos primeiros passos com o Jenkins seguindo a documentação,
andamos um passo à frente: criar um novo job. No Jenkins um job - trabalho - quer
dizer tarefa que será executada repetidamente. É no job que se configura o pipeline de
execuções que compõem o build, além de armazenar todo o histórico de construções
anteriores e gerar logs de feedbacks (SATO, 2013).
Para criar um novo job é necessário escolher um nome identificador. Para o
estudo de caso o nome escolhido foi “NotesApp”. Além do nome o Jenkins fornece
opções para vários tipos de jobs. Para o projeto a opção é a primeira, “Construir um
projeto de software free-style”, que nos permite personalizar o build independente de
tecnologia ou ambiente. A configuração deste job é dividida em seis partes:
Configurações gerais; gerenciamento de código-fonte; trigger de builds; ambiente de
build; comandos do build e; ações pós-build.

15
Na primeira parte definimos as configurações gerais de definição como nome
do projeto e descrição, além de outras definições que identificam o projeto e
repositório, se a construção recebe parâmetros e outras definições avançadas. No
segundo passo conectamos o job ao repositório do projeto para que o servidor de IC
consiga monitorar e disparar ações sempre que houver novas mudanças. Nessa parte,
com o servidor de IC configurado com os plugins recomendados, temos três opções de
repositório: Nenhum; Git e; Subversion. Na opção Git deve-se definir a URL do
repositório, a branch e credenciais de acesso como usuário e senha.
É no terceiro passo onde dizemos ao servidor de IC que deve ser iniciada uma
construção do projeto sempre que houver uma mudança. Marcamos então a opção de
post-commit hook, uma espécie de evento que é chamada pelo SCM em quem o
escuta, executando então o script de build que é definido nos passos seguintes.
Marcamos também a opção “Consultar periodicamente o SCM”. Marcando essa opção
pode-se especificar no servidor de IC o período de tempo, no formato cron, em que
haverá uma consulta por mudanças no repositório e, havendo, inicia-se uma nova
construção. O valor “* * * * *” diz no formato esperado que a consulta deve ser realizada
uma vez por minuto (SMART, 2011).
Antes de configurar os comandos do build pode-se especificar no quarto passo
algumas opções do ambiente usado pelo servidor de IC. Inclui-se as opções de excluir
os arquivos temporários da realização do build após a conclusão, tempo limite para
conclusão da construção, dentre outras. Para o estudo de caso é opcional selecionar
alguma das opções.
É na quinta parte que se define o build de fato. O tipo do job escolhido durante
a criação foi o estilo freestyle build. Isso diz que pode-se configurar o build quebrando a
execução em vários passos. Isso torna fácil a personalização da construção em
subprocessos procedurais (SMART, 2011). Esta seção possui um item de seleção com
algumas opções, uma delas é a “Executar shell”, que permite definir uma série de
comandos que serão executados diretamente no SO da máquina. Também há opções
para outros cenários, como “Executar no comando do Windows” e “Chamar alvos

16
Maven de alto nível” para projetos Java. A opção que se encaixa no cenário deste
estudo de caso é a “Executar shell”. Selecionamos e, então, finalmente definimos todos
os comandos que deverão ser executados no servidor para realizar a construção e a
implantação do sistema, conforme figura 3. Observa-se que os comandos inseridos no
campo de texto são os mesmos documentados no Quadro 1.
Figura 3: Definições do quinto passo da criação de um job.
A sexta e última etapa de criação de um job consiste nas ações pós-build. Essa
parte é muito importante nos processos de IC, pois é nesta etapa que se configura o
envio de feedbacks (ADBUL; FHANG, 2012; SATO, 2013; HUMBLE; FARLEY, 2014).
Além disso esta etapa torna possível geração de relatório de qualidade do código,
salvar os artefatos gerados em um repositório, publicar uma release do software,
disparar e-mails, dentre outras opções. Para o estudo de caso o acompanhamento do
feedback é feito na análise de logs durante a construção, não sendo necessário
selecionar uma opção.
Após seguir os seis passos basta apertar o botão “Salvar” e o job está criado. Ao
acessar o job na página inicial do Jenkins é possível visualizar três das principais
opções, são elas: “Configurar”; “Histórico de builds” e; “Construir agora”, podendo ser

17
visualizadas na figura 4. A opção “Configurar” permite alterar as definições do job,
então inseridas nos primeiros passos da criação. Essa opção é muito utilizada nas
primeiras configurações, onde é comum enfrentar erros e corrigi-los até que o job
esteja pronto. No “Histórico de builds” é possível acessar os logs de todas as
construções.
O botão “Construir agora” aciona o job com todas as configurações definidas
anteriormente. Para este trabalho o servidor de IC foi instalado na mesma máquina que
os servidores dos projetos notes-api e notes-web, sendo assim não foi necessário
efetuar nenhuma conexão remota via SSH para executar os comandos. Porém, como
ilustrado na FIG. 1, caso o servidor de IC estiver numa localização diferente, como é o
caso da grande parte dos projetos corporativos, o Jenkins possui o suporte necessário,
podendo acessar diferentes servidores via SSH com autenticação simples ou baseada
em par de chaves (SMART, 2011).
Figura 4: Página inicial do job.

18
O funcionamento do sistema será testado antes do monitoramento do repositório
e da execução do build (FIG. 5). Pode-se observar que os servidores respondem a
aplicação normalmente. Para o estudo de caso vamos efetuar alguma alteração no
projeto, enviar a alteração para o repositório do código-fonte e então acompanhar o log
de execução automática do build.
O acompanhamento do build poderá ser feito no histórico de construções do job
no Jenkins. Garantir a qualidade do produto é prioridade, então a codificação de testes
unitários e testes de aceitação são de extrema importância para o restante do
processo. Com automação dos testes o build do projeto se torna auto-testável,
definindo o sucesso ou falha da construção (FOWLER, 2006 [A]; DUVALL et al, 2007).
Figura 5: Página inicial do sistema antes de gerar um build automático.
O servidor de IC está monitorando o repositório a cada minuto. Assim que
houver qualquer mudança, por mínima que seja, o build será iniciado e todo o processo
de geração de binários e deploy será realizado (SMART, 2011). Será alterado a label
dos botões da tela inicial como exemplo. Essa alteração pode ser feita na branch
master do repositório no GitHub com algum usuário que tenha permissão de escrita.
Após realizar essa alteração é possível acessar o histórico da construção que foi

19
iniciada automaticamente pelo Jenkins, configurado como ação de post-commit.
Ao acessar o link no identificador #21 vemos os detalhes da construção, como
data/hora do build; lista de commits que o build acopla; identificador da revisão e
branch; além de outros detalhes (SMART, 2011). No menu lateral esquerdo é possível
acessar a “Saída do console” que detalha o sucesso ou falha da execução de cada
parte do build (SATO, 2013). Neste caso o resultado obtido no feedback da construção
foi: Finished: SUCCESS. Ao acessar a página inicial do sistema (FIG. 6) certificamos
que as mudanças foram entregues em alguns segundos, do repositório ao cliente,
seguindo processos repetíveis e automatizados.
Figura 6: Página inicial do sistema após finalização do build automático.
A automatização do processo de geração de binários e implantação de software
foi concluída. Com esse processo automatizado a construção e implantação do sistema
não levarão mais dias para concluírem, pois se tornaram tão simples quanto o apertar
de um botão. Agora os desenvolvedores podem focar na qualidade de suas atividades
recebendo os feedbacks das implementações (HUMBLE; FARLEY, 2014; SATO,
2013).

20
5. DISCUSSÃO DOS RESULTADOS
A construção automatizada deste projeto gasta em média 45 segundos para total
conclusão. A duração e status do último build pode ser visualizado na página inicial do
Jenkins onde há um resumo da última construção de cada job, conforme ilustrado na
figura 7. No último caso a construção demorou apenas 43 segundos para concluir.
Mensurando a execução do mesmo processo de forma manual leva-se em média 5
minutos e 40 segundos, levando em conta que cada passo está disponível em
alguma documentação e que as ferramentas necessárias para conexão remota no
servidor estão disponíveis de imediato no ambiente do operador.
Figura 7: Resumo da última construção do job NotesApp.
O tempo gasto com instalação/configuração do servidor de IC para o estudo de
caso foi de 6 horas e 30 minutos. Para configuração do job o tempo médio foi 3 horas
e 15 minutos. Somando o tempo total gasto com instalação do servidor de IC mais a
criação do job se tem o total de 9 horas e 45 minutos. Ainda, somando este total com
a duração média de um build (45 segundos), chega-se no total de 9 horas, 45 minutos
e 45 segundos para implantar um servidor de IC, configurar um job e executar um
build automatizado. Considerando o tempo de 5 minutos e 40 segundos para uma
construção manual, serão necessárias 104 construções manuais para chegar no total
gasto com a automatização: 9 horas, 43 minutos e 40 segundos. Essas mesmas 104
construções de forma automatizada levariam em média 1 hora e 18 minutos.
Chega-se à conclusão que o tempo gasto com a automatização dos processos deste
estudo de caso será compensado após 120 construções automatizadas.

21
6. CONSIDERAÇÕES FINAIS
Por ser necessário mudanças nos processos muitas empresas optam por não adotar
Integração Contínua, mesmo com os ambientes cada vez mais dinâmicos e a
necessidade por entregas mais rápidas serem maior por parte dos clientes. O processo
manual é passível de erros, toma um grande tempo da organização e pode ser muito
estressante em alguns cenários. A Entrega Contínua surgiu como uma alternativa às
más experiências com processos manuais e garante versões do software mais
confiáveis. A contribuição do presente trabalho foi o auxílio para adoção das
ferramentas de IC nos passos iniciais, propondo uma abordagem de automatização
dos processos de geração de binários e implantação, desde a conexão ao servidor até
o feedback com os resultados.
Conclui-se que é possível implantar Integração Contínua inicialmente em um
escopo reduzido e colher seus frutos iniciais, independente da homogeneidade do
projeto. Foi mensurado o tempo gasto com a automatização, comparando com o
processo manual e concluindo os objetivos com a quantidade de construções
automatizadas necessárias para se ter o retorno do investimento.
Os benefícios de se adotar a proposta são vários e de consenso entre diversos
autores, mas ainda há pontos negativos. É recomendado que se tenha especialistas
em IC na equipe. Manter um servidor de IC, a gerência de configuração, evolução dos
processos, envolvimento da equipe, tomada de decisão para adoção de ferramentas
especializadas e várias outras responsabilidades são exigidas de uma equipe que
trabalhe com Integração Contínua e quer colher os frutos da metodologia, o que pode
exigir da empresa investimento em consultorias e especializações para os
profissionais.
Como trabalhos futuros pretende-se envolver os processos de feedback com
uma abrangência maior, automatização de testes e a dependência dos mesmos no
sucesso da construção. A pipeline da Entrega Contínua e a gerência de versões
também podem ser customizados e automatizados através do servidor de IC.

22
REFERÊNCIA
ABDUL, Fazreil A.; FHANG, Mensely C. S. Implementing Continuous Integration
towards rapid application development. Malaca: International Conference on
Innovation Management and Technology Research, 2012.
ANGULAR, Google. QuickStart. 2017 [A]. Disponível em:
https://angular.io/guide/quickstart. Data de acesso: 15 mar. 2017.
ANTONIU, Gabriel; BOUGÉ, Luc; NAMYST, Raymond. An efficient and transparent
thread migration scheme in the PM2 runtime system. IPPS, Berlin, v. 1586, p. 496-510,
1999.
ARGENTO, Roberto; HAMILTON, Valerie. Lowering business costs: Mitigating risk in
the software delivery lifecycle. Nova Iorque: IBM, 2009.
BERNARDO, Paulo C.; KON, Fabio. A Importância dos testes automatizados.
Engenharia de Software Magazine, Rio de Janeiro, v. 1, p. 54-57, 2008.
CAFFERY, Fergal Mc; TAYLOR, Philip S.; COLEMAN, Gerry. Adept: A unified
assessment method for small software companies. IEEE Software, California, v. 24, p.
24-31, 2007.
JENKINS, CI. Jenkins Documentation. 2017 [A]. Disponível em: https://jenkins.io/doc/.
Data de acesso: 15 mar. 2017.
CHEN, Lianping. Continuous Delivery: Huge benefits, but challenges too. IEEE
Software, California, v. 32, p. 50-54, 2015.
DE SOUZA, Karla P.; GASPAROTTO, Angelita M. S. A importância da atividade de
teste no desenvolvimento de software. Bahia: Abepro, 2013.
DUVALL, Paul M.; MATYAS, Steve; GLOVER, Andrew. Continuous Integration:
Improving software quality and reducing risk. Londres: Addison-Wesley Professional,
2007.
NODE.JS. Docs. 2017 [A]. Disponível em: https://nodejs.org/en/docs/. Data de acesso:
15 mar. 2017.
FOWLER, Martin. Continuous Delivery. 2013 [A]. Disponível em:

23
https://martinfowler.com/bliki/ContinuousDelivery.html. Data de acesso: 15 mar. 2017.
FOWLER, Martin. Continuous Integration. 2006 [A]. Disponível em:
https://martinfowler.com/articles/continuousIntegration.html. Data de acesso: 02 abr.
2017.
FOWLER, Martin. Deployment Pipeline. 2013 [B]. Disponível em:
https://martinfowler.com/bliki/DeploymentPipeline.html. Data de acesso: 15 mar. 2017.
GITHUB, Inc. Source Code From MEAN 2 Course. 2017 [A]. Disponível em:
https://github.com/atilla8huno/mean2-course. Data de acesso: 12 jan. 2017.
GMEINER, Johannes; RAMLER, Rudolf; HASLINGER, Julian. Automated testing in
the continuous delivery pipeline: A case study of an online company. Graz: IEEE
International Conference on Software Testing, Verification and Validation, 2015.
HUMBLE, Jez; FARLEY, David. Entrega Contínua: Como entregar software de forma
rápida e confiável. Porto Alegre: Bookman, 2014.
IEEE, Software. IEEE Standard for software configuration management plans.
2005 [A]. Disponível em: http://ieeexplore.ieee.org/document/1502775/. Data de
acesso: 11 fev. 2017.
DIGITALOCEAN, Inc. DigitalOcean Cloud Computing. 2017 [A]. Disponível em:
https://www.digitalocean.com. Data de acesso: 15 mar. 2017.
JAMEEL, Shakir; KHANNA, Stuti; RANGAPPA, Sakshi; PATIL, Sheetal; KHALKAR, R.
G. MEAN-vs-JAX RS for RESTful web services: Performance and efficiency analysis.
IJAIEM, Gwalior, v. 6, p. 155-161, 2017.
JAVA, Oracle. Software Java. 2017 [A]. Disponível em:
https://www.oracle.com/br/java/index.html. Data de acesso: 11 fev. 2017.
MEYER, Mathias. Continuous Integration and its tools. IEEE Software, Nova Jersey, v.
31, p. 14-16, 2014.
MYERS, Glenford J.; SANDLER, Corey; BADGETT, Tom. The art of software testing.
3. ed. Nova Jersey: Wiley, 2011.
NEELY, Steve; STOLT, Steve. Continuous Delivery? Easy! Just change everything
(well, maybe it is not that easy). Nashville: Agile Conference, 2013.

24
PINTO, Arthur F.; TERRA, Ricardo. Processo de conformidade arquitetural em
integração contínua. Lavras: Universidade Federal de Lavras, 2015.
RAHUL, Soni. Nginx: From beginner to pro. Nova Iorque: Apress, 2016.
RASMUSSON, J. The Agile Samurai: How Agile Masters Deliver Great Software
(Pragmatic Programmers). Carolina do Norte: Pragmatic Bookshelf, 2010.
SALES, Ernani; REIS, Carla L.; REIS, Rodrigo Q. Apoio a gerência de configuração
de artefatos de software integrado a execução de processos de software. Belém:
Universidade Federal do Pará, 2009.
SATO, Danilo. DevOps na prática: Entrega de software confiável e automatizada. São
Paulo: Casa do código, 2013.
SMART, John F. Jenkins: The definitive guide. Califórnia: O’Reilly, 2011.

Fundamentos da Integração Contínua

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Fundamentos da Integração Contínua

Semelhante a Fundamentos da Integração Contínua (20)

Fundamentos da Integração Contínua