Monografia-Devops

UCAM - UNIVERSIDADE CANDIDO MENDES
RACHEL REUTERS DA SILVA
O crescimento de DevOps no mercado de Tecnologia da
Informação
Rio de Janeiro
2016

UCAM - UNIVERSIDADE CANDIDO MENDES
RACHEL REUTERS DA SILVA
O crescimento de DevOps no mercado de Tecnologia da
Informação
Orientador: Prof. Antonio Muniz
Rio de Janeiro
2016
Trabalho de Conclusão de Curso de
Pós-Graduação da Universidade
Candido Mendes - UCAM, como
requisito parcial para a obtenção do
título de Pós Graduação em Gestão
da Tecnologia da Informação e da
Comunicação.

CATALOGAÇÃO NA FONTE
Autorizo, apenas para fins acadêmicos e científicos, a reprodução total ou
parcial desta monografia.
Assinatura: Data:
___________________________________________ _________

RESUMO
O objetivo do presente trabalho é apresentar a nova cultura de DevOps que vem se
expandindo em um ritmo acelerado nas organizações voltadas para produção de software. São
apontadas as razões pelas quais as empresas estão adotando essa nova cultura, seus principais
objetivos e características. Diversos conceitos de Entrega Contínua, essenciais para a
implementação do DevOps, são explicados, como controle de versão, automação de testes e
integração contínua. Além disso são indicadas as ferramentas mais conhecidas que auxiliam
na automação de processos, como Docker, Chef, Vagrant, Ansible e Puppet.
Palavras-chave: DevOps, cultura, Entrega Contínua, versionamento, ferramentas.

SUMÁRIO
Introdução............................................................................................................................................... 7
Capítulo 1 ................................................................................................................................................ 9
DEVOPS – UM MOVIMENTO CULTURAL............................................................................................. 9
1. O que é DevOps?............................................................................................................................. 9
2. O Paradigma original..................................................................................................................... 10
3. Comparativo do DevOps com a metodologia tradicional ............................................................. 10
4. Capacidades do DevOps................................................................................................................ 12
5. Quem está adotando o DevOps? .................................................................................................. 13
5. Maiores beneficiados no DevOps.................................................................................................. 14
7. Responsabilidades chave do DevOps............................................................................................ 15
8. Modelo C.A.L.M.S.......................................................................................................................... 16
9. Relatório anual de DevOps da Puppet Labs de 2015 .................................................................... 16
10. Gartner e o Nexo das Forças....................................................................................................... 17
11. A matemática do DevOps............................................................................................................ 19
CAPÍTULO 2 ........................................................................................................................................... 21
ENTREGA CONTÍNUA......................................................................................................................... 21
1. Pipeline de Implantação............................................................................................................ 21
2. Controle de Versão.................................................................................................................... 22
2.1. Sistemas de Controle de Versão Centralizados.......................................................................... 23
2.2. Sistemas Distribuídos de Controle de Versão ............................................................................ 24
3. Integração Contínua.................................................................................................................. 25
3.1. Pré-requisitos para a Integração Contínua ................................................................................ 27
3.2. Características de um servidor de Integração Contínua ............................................................ 27
3.3. Ferramentas de Integração Contínua ........................................................................................ 28
CAPÍTULO 3 ........................................................................................................................................... 29
AS FERRAMENTAS DE TRABALHO DO DEVOPS ................................................................................. 29
1. Infraestrutura ágil...................................................................................................................... 29
2. Containers ................................................................................................................................. 31
3. Ferramentas de Gerenciamento de Configuração.................................................................... 31
3.1. Puppet................................................................................................................................... 32
3.2. Chef ....................................................................................................................................... 33

3.3. Ansible................................................................................................................................... 34
3.4. Comparativo entre Puppet, Ansible e Chef........................................................................... 36
4. Ferramentas de virtualização por containers............................................................................ 37
4.1. Docker ................................................................................................................................... 38
5. Ferramentas de virtualização por Máquinas Virtuais ............................................................... 39
Conclusão.............................................................................................................................................. 41

Introdução
Devido ao rápido avanço da tecnologia, o desenvolvimento de software tem se tornado
fundamental para o valor de negócio nas empresas. No setor de Tecnologia de Informação, a
entrega de aplicações para o cliente é o principal objetivo. No entanto, esse processo costuma
ser muito custoso, tanto com relação ao tempo quanto ao esforço das equipes. Longos ciclos
de teste e a distância entre os times de desenvolvimento e de operações são fatores críticos
que geram essa deficiência.
Com a elevada concorrência no mercado, diversas metodologias de desenvolvimento de
software evoluíram com o intuito de elevar a eficiência desse trabalho, trazendo maiores
benefícios tanto para a empresa quanto para os recursos envolvidos nas demandas de
sistemas.
Em 2001, um grupo de renomados desenvolvedores, autores e consultores de software,
assinaram o Manifesto para o Desenvolvimento Ágil de Software (CUNNINGHAM, 2001),
que abordava o desenvolvimento ágil. Essa metodologia propunha uma nova abordagem para
organizar as atividades constituídas no processo de elaboração de software, tais como:
levantamento de requisitos, arquitetura, implementação e testes. Ao invés de realizar cada
etapa em uma fase distinta, compreendendo o modelo cascata, as mesmas sucedem de modo
paralelo, em curtas iterações.
Muitas organizações dividem o setor de desenvolvimento de software e o setor de operações.
O primeiro é guiado pela elaboração de código que corresponde às solicitações do cliente em
um curto intervalo de tempo. Já o setor de operações tem como objetivo manter o sistema
estável e performático. Isto é, enquanto um objetiva entregar rapidamente, o outro deseja
entregar um sistema o máximo otimizado possível. Esses dois fatores são concorrentes, pois
normalmente quando se intuita entregar em um curto intervalo de tempo, a qualidade sofre,
por outro lado, quando o foco é a qualidade, acaba por demandar maior esforço e tempo.
DevOps, popularizado em 2009, é um movimento cultural cujo foco é a entrega para o cliente.
A fim de agilizar e tornar esse processo menos custoso, práticas como automação,
colaboração e uso de ferramentas constituem o tripé dessa nova cultura. O termo DevOps (do
inglês Developers and Operations) surgiu pois o maior diferencial dessa cultura é a redução

da distância entre as equipes de desenvolvedores e de operações, maximizando a cooperação e
a comunicação entre ambos.

9
Capítulo 1
DEVOPS – UM MOVIMENTO CULTURAL
Existem muitas opiniões sobre DevOps, mas um fato é inegável: DevOps é real. Desde
pequenas startups às 500 maiores empresas estão adotando DevOps em uma taxa acelerada.
1. O que é DevOps?
Em 2007, enquanto estava em uma consultoria sobre migração de Data Center para o
governo da Bélgica, o administrador de sistemas Patrick Debois viu-se frustado com os
constantes conflitos entre desenvolvedores e administradores de sistemas. No ano seguinte, na
conferência de Desenvolvimento Ágil em Toronto, o desenvolvedor de software Andrew
Shafer anunciou a sessão de Infraestrutura Ágil. Patrick se interessou e ambos conversaram e
formaram o grupo de Administração de Sistemas Ágil (PAUL, 2014).
No ano de 2009, na conferência de O’Reilly Velocity 09, John Allspaw e Paul Hammond
fizeram seu discurso entitulado “10+ Deploys a Day: Dev and Ops Cooperation at Flickr”.
Patrick gostou da ideia e resolveu organizar um evento de Velocidade na Bélgica, nomeado
DevOpsDays. No Twiter, o assunto foi abreviado para #DevOps, e assim ficou conhecido. A
palavra DevOps é formada pela combinação de desenvolvimento (do inglês Development)
com operações (do inglês Operations).
DevOps não é considerado como um processo, tecnologia ou padrão, mas sim como uma
cultura, que visa estressar a comunicação, colaboração e integração entre os desenvolvedores
de software e os profissionais de operações de TI. Uma implementação da cultura de DevOps
bem sucedida corresponde a um respeito mútuo entre desenvolvimento e operações. O
primeiro entrega qualidade de código e o segundo uma infraestrutura adequada para executar
o código da melhor forma possível. É possível que haja divergência de opiniões ao longo do
ciclo, porém o objetivo final é de entregar o software que executa como combinado e atende
às necessidades do cliente.

10
2. O Paradigma original
O grande paradigma que levou a implantação dessa cultura é que de um lado o cliente
demanda novas funcionalidades e inovações com prazos curtos, do outro lado o mesmo exige
que o sistema seja estável e sem interrupções (MUELLER, 2010).
No processo tradicional de desenvolvimento de sistemas, esses dois requisitos são
concorrentes, isto é, a empresa deve escolher qual priorizar. No entanto, nenhuma delas
separadamente é vantagem para a empresa muito menos para o cliente. Os dois requisitos
devem andar em conjunto a fim de prover uma melhor solução.
O objetivo dessa nova cultura é integrar todas as partes interessadas em um único fluxo de
trabalho, com boa qualidade de software que atende aos requisitos de integridade e
estabilidade como um todo. Como grupos distintos podem unir forças? A partir da adesão de
um grupo de princípios que transcendem as fronteiras disciplinares tradicionais:
 Assegurar que todas as equipes trabalhem seguindo a mesma meta e estejam
utilizando as mesmas métricas de negócio.
 Manter curtos ciclos de desenvolvimento que permitam ao negócio se adaptar
rapidamente às mudanças.
 Utilizar sinalizadores de recursos e estratégias progressivas de desenvolvimento que
tornem mais fácil a implantaçao de novas funcionalidades em produção.
 Criar iterações de rápido feedback que possibilitam a identificação de problemas de
forma veloz, a fim de reagir imediatamente.
 Sempre buscar ser mais eficiente como equipe.
3. Comparativo do DevOps com a metodologia tradicional
Comparando a metodologia tradicional de Tecnologia da Informação (TI), DevOps possui
políticas e práticas que diferem ao longo das seis dimensões apresentadas na Tabela 1 (LIRA,
2015).
A metodologia tradicional objetiva aumentar a carga a carga de trabalho. Maior parte do
mercado cresceu com a metodologia em cascata, que por natureza demanda um longo período
de tempo para realizar a primeira entrega. Além disso, como essas entregas são custosas, as
fábricas de desenvolvimento costumam maximizar a produtividade de código, isto é, resumir

11
maior extensão de código fonte em uma única entrega e lançado em produçao de uma só vez.
Uma organizaçao aderente à cultura do DevOps segue uma estratégia diferente. Como
entregas volumosas correspondem a grandes riscos e são difíceis de coordenar, é preferível
diminuir a carga e realizar diversas entregas, visto que é mais simples, corresponde a menos
riscos e significa maior facilidade nos testes. Isto é, executando entregas mais compactas e de
forma frequente melhora a responsividade da empresa com as demandas solicitadas pelo
cliente. Por regra, a cada um quarto de redução no tempo de cada ciclo, a produtividade dobra
e os custos operacionais são reduzidos em 20% (GARTNER, 2016).
Tabela 1 – Comparativo entre cultura tradicional e o DevOps
Dimensão TI Tradicional DevOps
Carga de trabalho Volumosa Mínima
Divisão das equipes Por habilidade Células dedicadas
Entrega Evento único de alto risco Múltiplos eventos de baixo risco
Informação Segregada Disseminada
Cultura Não se deve falhar O melhor é falhar cedo
Métrica Custo e Capacidade Custo, Capacidade e fluxo
Outro fator diferenciado do DevOps é a divisão das equipes por células dedicadas, onde cada
equipe está focada em uma aplicação inteira, constituída por desenvolvedores, testadores,
analistas de negócio e operadores, isto é, cada equipe é auto suficiente, diminuindo o tempo
em que a informação trafega dentro da empresa, assim como promover o treinamento
cruzado.
O histórico de performance de TI não é agradável, estudos revelam que 30% de novos
projetos são entregues em atraso, 50% das melhorias não são mantidas por questões de
qualidade e 40% dos atrasos ocorrem devido a problemas de infra-estrutura. A cultura do
DevOps está adaptada ao fato de que erros são inevitáveis, ao invés de tentar eliminar o erro,
é preferível controlar quando e como a falha irá ocorrer. Assim, quanto mais cedo é
descoberta, mais cedo é possível se recuperar.
Com relação a métrica, foi adicionado o parâmetro de fluxo, impulsionando as organizações a
atentarem para todo o ciclo de vida (de ponta a ponta). Possibilitando, assim, melhor detecção
das áreas de maior desperdício, gerando dados estatísticos com maior precisão, quantificando
a qualidade e evidenciando as atividades de maior valor para a empresa.

12
4. Capacidades do DevOps
A cultura de DevOps tem o foco nas seguintes capacidades: colaboração; automação;
integração, entrega, teste e monitoramento contínuos (SHARMA e COYNE, 2015).
 Colaboração: ao invés de apontar o erro para o outro, os desenvolvedores e operadores
de TI, apesar de suas diferenças, trabalham juntos com um objetivo em comum. O
foco na colaboração conduz a uma melhor confiabilidade, maior destaque para o
negócio, agilidade de mercado e maior satisfação dos clientes. É importante que se
pratique a colaboração em 3 camadas:
o Equipes: pequenas equipes trabalhando juntas para alcançar grandes objetivos;
o Grupos de equipes: grupos de equipes trabalhando em cadência e de forma
sincronizada;
o Ideias: alinhamento de ideias e conceitos que forem identificados, analisados e
aprovados para entrega.
Os principais pontos chave dessa capacidade são: voz do cliente, melhoria, interação,
transparência, demonstração, rápido feedback;
 Automação: incentiva fortemente o uso de ferramentas de automação a fim de agilizar
o processo de desenvolvimento;
 Integração contínua: é uma pratica de engenharia de software em que mudanças
pontuais são testadas imediatamente e relatadas assim que são acrescentadas ao código
fonte. O seu principal objetivo é possibilitar um rápido feedback, assim que um erro
ocorre, é logo identificado e corrigido. A regra é que cada integrante da equipe aponte
diariamente o trabalho realizado e o pacote recompilado em cada mudança
significativa. Para isso é necessária integração do trabalho de cada desenvolvedor
diariamente, expondo imediatamente conflitos e problemas de integração, exigindo
comunicação mais efetiva;
 Teste contínuo: “O custo da qualidade é o custo da falha”. Todos estão envolvidos
com os testes, não somente a equipe de qualidade. É essencial que esta teste
rapidamente, para isso é importante que os desenvolvedores entreguem um código
com o mínimo de erros, isto é, que seja testado previamente ao máximo. Além disso,
pode ser uma boa prática do desenvolvedor fornecer conjuntos de dados de teste para
agilizar o processo ainda mais. É, também, uma boa prática automatizar o máximo de

13
processos de teste possível. Por fim, é importante que a equipe de operações sempre
mantenha estável o ambiente de testes, podendo inclusive participar dos testes de
carga, de stress e de estabilidade;
 Monitoramento Contínuo: em produção, é o time de operações que se certifica de que
a aplicação e o ambiente estão com seu desempenho e se estão estáveis de acordo com
o esperado. No DevOps, essa equipe, além de possuir as ferramentas necessárias para
monitorar o ambiente, também deve possuir ferramentas para monitorar as aplicações,
garantindo sua máxima otimização. Outra prática do DevOps sugere que as equipes de
operações trabalhem com a equipe de desenvolvimento a fim de monitorar a aplicação
ao longo de todo seu ciclo de vida.
5. Quem está adotando o DevOps?
A adoção do DevOps pelas empresas está acelerando a cada ano. Alguns estudiosos mostram
que o DevOps está se expandindo por todos os tipos de empresa, desde startups a gigantes da
tecnologia (RIGHSCALE, 2016). Outro grupo de pesquisadores infere que a cultura está
acelerando mais rapidamente em pequenas empresas, pois para mudar os processos em
grandes empresas tende a ser mais complexo, visto a quantidade de burocracias que essas
possuem.
O fato é que DevOps está evoluindo de forma tão acelerada, que torna-se difícil caracterizar o
nível de adoção por tipo de empresa. No entanto, as evidências apontam que o tamanho da
empresa não é um fator significante para que o DevOps seja um sucesso.
As mais famosas empresas que abraçaram essa cultura são: Google, Twitter, Amazon, Netflix
e Facebook. Juntas, essas empresas somavam um capital de mais de $717 bilhões de dólares
em 2014, deixando de exceder o PIB (Produto Interno Bruto) de apenas 19 países em todo o
mundo. Com relação às startups e às empresas de médio porte, DevOps foi adotado pelas
empresas Tumblr, Evernote, Etsy e Github, que hoje possuem receitas extremamente
competitivas no mercado.
Na Figura 1 pode-se verificar a porcentagem de adoção do DevOps ao longo dos dois últimos
anos.

14
Figura 1 – Adoção de DevOps até 2016 (RIGHTSCALE, 2016)
5. Maiores beneficiados no DevOps
É possível verificar diversos pontos de vantagens para todas as equipes dentro da cadeia de
produção de um software: desenvolvedores, operações, testes e até mesmo gerentes e
executivos.
Para os desenvolvedores, o provisionamento automatizado é uma das grandes vantagens, pois
eles mesmos podem arquitetar um ambiente de desenvolvimento sem a necessidade de
demasiadas burocracias. Quando um desenvolvedor pode preparar um ambiente funcional
com todos os recursos necessários em menos de quinze minutos, o processo de criação de
software é agilizado, favorecendo a criatividade e a inovação, além de reduzir as horas-
extras, provendo maior qualidade de vida e satisfação.
Na TI tradicional, o time de operações é o único responsável pelo ambiente de produção. Em
caso de qualquer problema, não podem contar com o apoio dos desenvolvedores, reduzindo as
chances de encontrar uma rápida e efetiva solução. Em DevOps, por outro lado, esse time
conta com o auxílio dos desenvolvedores e com diversas ferramentas de automação que
ajudam a eliminar erros comuns e ainda reduzir o tempo gasto em tarefas repetitivas de rotina.
O impacto da adoção de DevOps na equipe de testes também está relacionado com a
automatização de diversos testes. Assim, é possível separar uma fatia maior de tempo para os
testes que necessitam realmente de processos manuais, possibilitando analisar ao máximo
todo o sistema. Além disso, com a facilidade de replicação de ambientes, é mais simples de
reproduzir um ambiente mais próximo possível ao ambiente de produção, antecipando
problemas que poderiam vir a ocorrer e ademais provendo testes de desempenho com maior
precisão. A Netflix desenvolveu um grupo de ferramentas chamado Simian Army cujo

15
objetivo é automatizar testes de condições anormais, como por exemplo, desligando uma ou
mais máquinas virtuais e verificando como o sistema vai se comportar. Com isso, é possível
preparar-se para erros inesperados antes que ocorram em ambiente de produção (NETFLIX,
2011).
DevOps permite que a organização consiga analisar em tempo real os dados da aplicação,
dados de máquina e dados estruturais, provendo uma visão geral de quem realmente está
entregando valor ao negócio. É possível entender melhor o comportamento de clientes e traçar
uma comparação entre eles. Além disso, torna-se mais fácil realizar análises “e-se” em
mudanças de interface ou novas ofertas de produto, provendo uma rápida resposta às
necessidades de mercado. Em um ambiente com DevOps, os stakeholders possuem grande
influência no processo de desenvolvimento. Graças ao espírito colaborativo, os
desenvolvedores se interessam mais com as regras de negócio além de se aproximarem dos
seus gerentes. Com DevOps, é possível ainda, obter uma resposta imediata sobre o impacto de
novos preços e de melhorias no produto, permitindo o teste de variações e a avaliação da
eficácia de todo o processo.
Um fator do DevOps almejado pelos executivos é que a aplicação entra no mercado
rapidamente, providenciando a vantagem competitiva que tanto anseiam. Outro fator
importante é de atrair e manter desenvolvedores, administradores de sistemas e engenheiros
de testes de alto nível. Finalmente, quando todos trabalham de forma colaborativa, raramente
ocorrem disputas inter-departamentais, o que permite aos executivos focarem na elaboração
dos objetivos de negócio.
7. Responsabilidades chave do DevOps
A cultura de DevOps constitui diversas práticas baseadas em métodos ágeis que reduzem o
risco de sistemas não seguirem a especificação, além de aumentar a eficiência e a eficácia das
equipes de TI.
A partir de diversos princípios adotados pelo DevOps, é possível entregar softwares
rapidamente, com qualidade, performance e inovação, produzindo feedback dos clientes
instantaneamete.
As responsabilidades chave do DevOps são:

16
 Ser colaborativo, buscando envolver outras pessoas assim que possível;
 Automatizar o máximo possível;
 Basear-se em métricas;
 Buscar sempre aprimoração;
 Compreender e respeitar os objetivos de negócio;
 Comunicar-se ;
 Trabalhar em paralelo com pequenas cargas de trabalho;
 Permitir refatorar o produto;
 Provar o valor de negócio para a gerência.
8. Modelo C.A.L.M.S.
O modelo C.A.L.M.S. é considerado uma alternativa para ITSM (Information Technology
Service Management). ITSM é uma abordagem estratégica para a concepção, fornecimento,
gestão e eficiência da tecnologia da informação (TI), muitas vezes associada a ITIL
(Information Technology Infrastructure Library), uma estrutura que fornece as melhores
práticas para alinhar a TI com as necessidades do negócio. De acordo com alguns
especialistas, ITIL é incompatível com ambientes DevOps. C.A.L.M.S. é por vezes
considerado como uma forma de negociar as diferenças entre as duas abordagens (RILEY,
2015).
O modelo C.A.L.M.S. foi introduzido por Damon Edwards e posteriormente refinado por Jez
Humble. O acrônimo simboliza: Cultura, Automação, Lean, Métricas e Compartilhamento (do
inglês Sharing).
Lean em inglês quer dizer magro, isto é, manter ferramentas, reuniões e até mesmo sprints no
mínimo. Até mesmo se aplica às equipes, deve manter-se equipes pequenas, a fim de
minimizar os erros, priorizar a comunicação e principalmente facilitar a priorização de tarefas.
9. Relatório anual de DevOps da Puppet Labs de 2015
O quarto relatório anual do DevOps confirmou que o desempenho de TI provisiona real valor
de negócio. Um bom desempenho das organizações de TI causa grandes e positivos impactos
no desempenho geral de seus clientes (PUPPET LABS, 2014). O relatório de 2015 mostrou
que:

17
 Organizações de TI com DevOps implantam melhorias com trinta vezes mais
frequência, com um tempo reduzido em duzentas vezes, com sessenta vezes menos
falhas e se recuperam de falhas 168 vezes mais rapidamente;
 Alto desempenho é alcançável independentemente do tipo de aplicação que está
sendo entregue (greenfield – aplicação nova, brownfield – aplicação pré-existente
normalmente são grandes atualizações ou legado), ao menos que ela seja
desenvolvida respeitando os princípios de tastabilidade e projetabilidade;
 Gerentes de TI têm um papel fundamental em qualquer transformação de DevOps;
 Diversidade é essencial. Pesquisas mostram que equipes com um maior número de
mulheres têm maior inteligência coletiva e alcançam melhores resultados.
10. Gartner e o Nexo das Forças
Na primeira semana do ano de 2012, a empresa reconhecida mundialmente do ramo de
pesquisas e consultoria de Tecnologia da Informação, Gartner, publicou um estudo apontando
as principais direções que o mercado de Tecnologia seguiria a partir do ano de 2013. As
quatro tendências do mercado foram apelidadas de Nexo das Forças, de acordo com a
pesquisa (HOWARD, 2014). São elas: mobilidade, redes sociais, nuvem e Big Data como
mostra a Figura 2.
Figura 2 – Nexo das Forças de Gartner
Com preveu o vice-presidente e analista da Gartner, Kimberly Harris-Ferrante, "Essas
mudanças vão forçar transformações fundamentais nos processos de negócios que, por sua
vez, remodelarão as empresas". Entre elas, estão a consolidação do uso de tecnologias para

18
tornar automático o controle de automóveis, uso do Big Data na manipulação de dados na
educação e a popularização do NFC (Near field Communication), para pagamentos móveis. O
vice-presidente frisou, ainda, a importância das escolhas feitas pelos gerentes e diretores de TI
devido às mudanças nos processos de negócios que os novos enfoques trariam.
A empresa mundial publicou as dez previsões para o setor de TI até o ano de 2017. São elas:
 Até 2016, três montadoras anunciarão planos concretos para lançamentos de
automóveis baseados em tecnologia para tornar os veículos automáticos.
 Em 2016, os pacientes serão prejudicados ou colocados em risco por uma violação de
segurança em dispositivos médicos.
 Em 2016, os governos nacionais vão exigir que as instituições de educação adotem
ferramentas de Big Data para análise das informações dos currículos e dados dos
alunos para corte de custos.
 Em 2015, a linguagem de processamento natural (PNL) a ser usada entre grandes
organizações de saúde em países de língua Inglês vai quintuplicar, alimentada por
documentação, codificação, elaboração de relatórios de qualidade e pesquisa.
 Em 2016, metade dos clientes de serviços públicos dos Estados Unidos terá acesso a
dados padronizados sobre uso de energia, mas apenas 20% irão usá-los.
 No final do ano de 2014, o sistema de pagamento dos seguros da carro no modelo pay-
as-you-drive vai aumentar significativamente. Esse sistema deverá representar 10% do
total seguros premium de automóvel registrado anualmente.
 Em 2014, menos de 2% dos consumidores no mundo estarão adotando a tecnologia
NFC para pagamentos móveis.
 Em 2017, mais de 50% dos anúncios veiculados nos meios de comunicação serão
pagos pelas agências de publicidade com base no desempenho de exibições.
 Em 2015, cerca de 50% do fabricantes de bens de consumdo vão investir em
tecnologia de empresas start-ups para acessar o mercado.
 Em 2016, pelo menos 25% das manufaturas discretas adotarão impressão 3D para
produzir partes e peças de produtos.

19
11. A matemática do DevOps
Lee Reid, especialista de TI da IBM, em conjunto com sua equipe, observaram importantes
clientes aplicando a cultura de DevOps (REID, 2015). Conseguiram abstrair alguns pontos
chave que ressonam com os tomadores de decisão, que precisam definir um novo rumo para
as suas equipes visando as grandes forças que lideram o mercado que são: o desenvolvimento
de aplicativos móveis, a hospedagem de grande massa de dados na nuvem, a revolução da
Internet das Coisas (Internet of Things) e Big Data.
O principal objetivo dos grandes líderes de negócios é entregar valor o mais rapidamente
possível, obtendo assim, feedback com maior frequência. Assim, é necessária uma abordagem
holística, que tem por base as suas capacidades existentes. Lee comprovou que o tempo de
entrega em um mundo ideal poderia ser definido através da Equação 1, isto é, o tempo de
entrega (TE) corresponde ao somatório dos tempos de planejamento (TP), análise (TAN),
implementação (TIM), build (TB), deploy (TDP), teste (TT), manutenção (TM), lançamento
(TL) e avaliação (TAV). Isto é, em um cenário ideal, o tempo de entrega pode ser otimizado
diminuindo o tempo de cada etapa do ciclo de vida do sistema (REID, 2015).
(Eq. 1)
Grande parte das organizações utilizam o ciclo de vida tradicional do desenvolvimento de
sistemas, onde as tarefas são divididas em partes volumosas, consumindo, assim, uma maior
fatia de tempo. Como resultado, a indústria tem cerca de 50% ou mais de taxa de falha quando
se trata de concluir um projeto dentro do tempo estimado. Gerando uma perda de valor no
negócio, visto que grande maioria dos projetos são entregues com atraso.
Como a aplicação é um conjunto de tarefas executadas por humanos, um fator chave de
confiabilidade (CF) deve ser inserido na equação para um cálculo mais apurado do tempo
total de entrega, pois quando um erro ocorre, muito tempo é gasto com retrabalho. A nova
equação que define o tempo de entrega está definido pela Equação 2. Assim, quando há um
fator de confiança de valor 0, o tempo de entrega (TE) tende ao infinito. Por outro lado,
quanto mais se aproximar de 1, mais o tempo total irá depender somente do somatório de todo
o trabalho desempenhado em cada etapa. Esse fator de confiança vem sendo considerado um

20
fator crítico nos projetos de software, pois acaba criando um multiplicador no tempo total de
entrega, gerando muito desperdício.
(Eq. 2)
DevOps possui uma abordagem de focar suas forças no fator de confiança e simultaneamente
reduzir o tempo gasto em cada etapa do processo a fim de reduzir o tempo total de entrega do
sistema. Por exemplo, dividindo as tarefas do projeto em partes menores, sendo entregues
para o usuário mais cedo e adquirindo um feedback imediato. O tempo de entrega (TE) é
reduzido, pois tanto o numerador decresceu, visto que cargas menores demandam tempos
mais curtos, quanto o fator de confiança aumentou, pois com o decréscimo no tamanho de
cada tarefa gera maior compreensão do escopo, menor esforço para transformar cada ideia em
código e facilita também os testes e o deploy.
Assim como diversas práticas podem ser aplicadas aos projetos, é importante que haja uma
análise para descobrir onde estão os gargalos de cada projeto e, assim, aplicar os facilitadores
corretos a fim de reduzir os custos e melhorar o feedback do cliente.
De acordo com Lee (REID, 2015), as práticas adotadas pelo DevOps são impactantes no fator
de confiança devido a três pontos chave dessa cultura:
 Clareza: definição apurada sobre a necessidade e o desejo do cliente, a fim de alcançar
o máximo valor do negócio. É atingida a partir da redução de cada tarefa em partes
menores, da busca pelo Mínimo Produto Viável, da comunicação constante com o
cliente e da redução de dependências a partir de arquiteturas fracamente acopladas;
 Colaboração: comunicação eficiente de toda a equipe, todos devem ter acesso às
mesmas informações dentro do escopo das tarefas a serem realizadas. Práticas como
formar equipes plurais (cross functional), utilizar quadros visuais, transparecer as
métricas, planejar e re-priorizar frequentemente e por fim, buscar o feedback do
cliente constantemente;
 Consistência: etapas sistemáticas e repetitivas a partir de automações.

21
CAPÍTULO 2
ENTREGA CONTÍNUA
Na comunidade de desenvolvimento de software, é dito que o código enquanto não entregue
ao cliente não possui valor de negócio, mesmo utilizando as melhores técnicas, sendo
codificado do modo mais virtuoso ou implementando funcionalidades mais perfomáticas.
Neste sentido, uma nova funcionalidade que existe somente no repositório de código-fonte e
não foi atualizada ou utilizada em nenhum ambiente, quer seja homologação ou produção, não
agrega valor ao negócio.
A cultura da Entrega Contínua existe para que as funcionalidades sejam liberadas
continuamente e de forma segura para o cliente. Os ambientes são sincronizados
periodicamente e de modo automático, assim a equipe centraliza seus esforços na criação do
melhor software possível com o mínimo de tarefas manuais possível. Do ponto de vista da
equipe de qualidade, o ambiente de teste será atualizado constantemente, agilizando a etapa de
validação do sistema e acelerando o processo de entrega efetivamente para o cliente.
1. Pipeline de Implantação
Em essência, o pipeline de implantação constitui na implementação automatizada das etapas
de construção, implantação, teste e liberação do software. Cada organização pode ter uma
implementação diferenciada do pipeline, dependendo de seu processo interno de liberação de
software, porém os princípios que o governa não varia. Um exemplo de pipeline pode ser
visto na Figura 1, em que cada mudança realizada na aplicação, podendo ser de ambiente, de
configuração, de dados ou de codificação, corresponde a um gatilho para a criação de um
novo pipeline. A primeira etapa do processo corresponde à criação de binários e instaladores,
as demais são responsáveis pela qualidade do produto. Se a nova funcionalidade obter sucesso
em todas as etapas de testes, será liberada em uma nova versão do produto (HUMBLE e
FARLEY, 2010).
O pipeline visa ampliar o compartilhamento das novas funcionalidades entre todas as equipes
envolvidas, não somente ao time de desenvolvimento, além de melhorar o feedback,
permitindo a identificação e a solução de problemas de forma antecipada, e finalmente
providenciando liberação do software em qualquer versão para qualquer ambiente de forma
automatizada.

22
Figura 1 – Pipeline de Implantação
A fim de entregar um software com qualidade e confiável em ciclos mais curtos, é necessário
que sejam realizadas liberações automatizadas e frequentes. A automação é importante para
que o processo torne-se repetível e previsível. E a frequência é essencial pois diminui as
diferenças entre as versões do software, além de prover feedbacks constantemente.
Também é fundamental o uso de uma ferramenta de controle de versão a fim de possibilitar
qualquer novo membro de equipe ter acesso à versão desejada do projeto, bastando realizar
um comando simples. Além de simplificar o controle de versão de cada ambiente
respectivamente e possibilitar retornar facilmante a uma versão específica.
2. Controle de Versão
Ferramentas de controle de versão tem por objetivo manter múltiplas versões dos arquivos de
um projeto, quando ocorre qualquer alteração, ainda é possível acessar versões anteriores sem
quaisquer problema. Além de possibilitar a ramificação de projeto, isto é, é possível dividir o
projeto em várias linhas de desenvolvimento que podem ser trabalhadas paralelamente, sem
que uma interfira na outra (HUMBLE e FARLEY, 2010).
O primeiro sistema de controle de versão foi a ferramenta desenvolvida pela equipe UNIX
chamada Sistema de Controle de Código Fonte (SCCF) na década de 70. Logo em seguida,
em 1982, foi lançado no mercado o Sistema de Controle de Revisão (SCR), por Walter F.
Tichy. O SCR somente tem suporte a controle de arquivos individuais, não permitindo a
administração de um projeto inteiro, além de que sua sintaxe não é simples. Posteriormente,
em 1986, foi lançada a primeira versão do CVS (do ingês Concurrent Versions System) por
Dick Grune, que se inspirou no SCR, porém com uma sintaxe mais simplificada além de
suportar o gerenciamento de múltiplos arquivos. O código do projeto evoluiu para a versão

23
atual do CVS por Brian Berliner em 1989 e atualmente é mantida por um grupo de
voluntários. Em 2000, muitos adeptos ao CVS estavam infelizes com algumas falhas de
projeto dessa ferramenta, foi então que um grupo se reuniu (liderados pela empresa
CollabNet) e começou a desenvolver o SVN (do inglês SubVersioN). Foi em Agosto de 2001
que a nova ferramenta estreiou no mercado e houve bastante aderência por parte dos
desenvolvedores. Em 2009, o SVN foi integrado ao Apache Software Foundation, um dos
grupos de projetos de código aberto mais conhecidos do mundo. Em 2005, foi removido o
acesso gratuito ao sistema proprietário de controle de versão BitKeeper, acusando os
desenvolvedores do kernel do Linux a usarem engenharia reversa em seu projeto. Esse
ocorrido incentivou os desenvolvedores do Linux a desenvolveram sua própria ferramenta de
controle de versão, o Git, sistema distribuído de gerenciamento de código fonte.
2.1. Sistemas de Controle de Versão Centralizados
O CVS e o SVN utilizam uma arquitetura cliente-servidor, em que um servidor é responsável
por armazenar as versões atuais do projeto além de todo seu histórico, o cliente se conecta ao
servidor para obter uma cópia completa do projeto (checkout), realizar as alterações desejadas
e por fim publicar os arquivos modificados (commit). Essa arquitetura está demonstrada na
Figura 3 (CHACON e STRAUB, 2014). Geralmente, cliente e servidor devem estar
conectados por uma rede local de computadores ou através da Internet, porém é possível que
ambos estejam na mesma máquina.
Figura 3 – Arquitetura Cliente-Servidor de Controle de Versão
É possível que diversos clientes editem cópias do mesmo projeto de modo concorrente. Assim
que confirmarem suas alterações o servidor tenta fazer uma fusão entre elas. Em caso do

24
servidor não conseguir realizar essa ação, é informado ao cliente e este se torna responsável
por realizar as combinações. Se o servidor validar corretamente, o número da versão de cada
cliente é incrementado, e uma linha de observação contendo a data e o autor da alteração é
escrita nos arquivos de log.
A ferramenta utilizada pelo desenvolvedor para atuar como cliente funciona através de linhas
de comandos e pode ter ainda uma interface gráfica que permita a integração com o
explorador de sistema de arquivos do sistema operacional utilizado. Caso seja utilizado no
projeto um ambiente de desenvolvimento integrado (do inglês, IDE), é possível ainda a
integração entre o cliente e a ferramenta, seja através de plugins ou suporte nativo da
ferramenta.
O sistema cliente-servidor para versionamento possui diversas vantagens, onde qualquer
cliente pode ter um conhecimento razoável sobre como outros desenvolvedores estão atuando
no projeto. Porém, também possui algumas desvantagens, como por exemplo, o servido
central é um ponto único de falha, se este ficar fora do ar, ninguém pode trabalhar em
conjunto ou salvar novas versões durante esse período. Se o disco do servidor de banco de
dados for corrompido e não existir um backup, todo o histórico se perde.
2.2. Sistemas Distribuídos de Controle de Versão
O Git utiliza uma arquitetura distribuída para o controle de versão, isto é, os clientes não
apenas fazem cópias das últimas versões dos arquivos, eles realizam cópias completas do
repositório. Assim, se um servidor falha, qualquer um dos repositórios dos clientes pode ser
copiado de volta para o servidor para restaurá-lo. Cada checkout é na prática um backup
completo de todos os dados. Essa arquitetura está representada na Figura 4 (CHACON e
STRAUB, 2014).

25
Figura 4 – Arquitetura de um Sistema distribuído de Controle de Versão
Essa arquitetura suporta vários repositórios remotos com os quais podem colaborar,
permitindo que se trabalhe com diferentes grupos de pessoas, de diversas maneiras,
simultaneamente no mesmo projeto. Isso permite que se estabeleça diferentes tipos de fluxos
de trabalho que não são possíveis em sistemas centralizados, como por exemplo o uso de
modelos hierárquicos.
Conceitualmente, os sistemas centralizados armazenam informações como uma lista de
mudanças por arquivo, isto é, cada informação armazenada constitui de um conjunto de
arquivos e as mudanças feitas a cada arquivo ao longo do tempo. Os sistemas distribuídos, por
sua vez, consideram que os dados são como um conjunto de snapshots (captura de algo em
um determinado instante, como em uma foto) de um mini-sistema de arquivos. Cada vez que
é salvo o estado do projeto, é como se o sistema tirasse uma foto de todos os seus arquivos
naquele momento e armazenasse uma referência para essa captura. Para ser eficiente, se
nenhum arquivo foi alterado, a informação não é armazenada novamente, apenas um link para
o arquivo idêntico anterior que já foi armazenado.
3. Integração Contínua
“Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time
integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente –
podendo haver múltiplas integrações por dia. Cada integração é verificada por um build automatizado
(incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa

26
abordagem leva a uma significante redução nos problemas de integração e permite que um time
desenvolva software coeso mais rapidamente.” - Martin Fowler
Integração Contínua tornou-se muito importante na comunidade de desenvolvimento de
software e isso provavelmente ocorreu devido ao grande impacto causado pelas metodologias
ágeis. Em equipes que adotaram tais metodologias (eXtreme Programming, Scrum, entre
outras), integração contínua é um dos pilares da agilidade, garantindo que todo o sistema
funcione a cada build de forma coesa, mesmo que sua equipe seja grande e diversas partes do
código estejam sendo alteradas ao mesmo tempo (FOWLER, 2006).
A integração contínua representa uma mudança de paradigma, em que os testes de integração,
ao invés de serem realizados ao fim de todo o desenvolvimento, este é efetuado a cada
mudança realizada, isto é, assim que um desenvolvedor pratica um commit toda a aplicação é
gerada novamente e um grupo de testes automatizados são então executados. E se algum
problema ocorrer durante os testes, a equipe interrompe suas atividades e destina-se a resolver
os incidentes. A arquitetura de um sistema de integração contínua pode ser observado na
Figura 5.
Figura 5 – Arquitetura de um sistema de Integração Contínua
Estudos verificam que as equipes que utilizam efetivamente a integração contínua são
capazes de entregar software muito mais rápido e com menos erros, do que as equipes que não
o fazem. Os erros são verificados mais cedo no processo de entrega, quando os impactos
ainda não são muito grandes, proporcionando significativa redução de custo e tempo.
Por que não executar os testes localmente e somente então fazer o commit? Para um
desenvolvedor é difícil refletir sobre o real impacto de uma atualização realizada em todas as

27
funcionalidades da aplicação. A integração contínua pode dar ao desenvolvedor a visão mais
geral sobre a aplicação, uma vez que os testes da aplicação são feitos em um ambiente clone
de produção. Além de que, diversas vezes o projeto em que se está trabalhando pode ser tão
grande, que os testes, principalmente os de aceitação, demoram um tempo considerável para
serem executados e o desenvolvedor pode não querer esperar todo o tempo a cada commit pra
poder continuar a trabalhar. Nesse caso, o recomendado é executar apenas os testes que
envolvem aquelas alterações realizadas e depois fazer o commit, deixando para o servidor de
integração contínua o trabalho de realizar todos os testes do sistema e garantir que toda a
aplicação esteja funcionando.
3.1. Pré-requisitos para a Integração Contínua
A fim de implementar a integração contínua, primeiramente é importante que seja incluída no
projeto uma ferramenta de controle de versão, pois é necessário que cada mudança no código
fonte seja um gatilho para o sistema de integração contínua atuar.
Outro requisito essencial é a adoção de um mecanismo de build automatizado. Independente
da técnica, deve ser possível tanto para uma pessoa quanto para uma máquina executar um
build, um teste ou até mesmo a implantação do software a partir da linha de comando. Deste
modo, é factível auditar problemas, além de tornar mais fácil o processo, facilitando a
colaboração da equipe de operações. Os scripts de automação devem ser constantemente
revisados, testados e eventualmente refatorados para melhor entendimento e performance
(FOWLER, 2006).
3.2. Características de um servidor de Integração Contínua
Um servidor de integração contínua deve:
 Realizar a compilação do código-fonte;
 Executar o build da aplicação;
 Implantar a aplicação na máquina de testes;
 Executar um conjunto de testes automatizados;
 Notificar o resultado, por exemplo através de e-mail;
 Gerar um relatório de estatísticas;
 Permitir integração com outras ferramentas.

28
3.3. Ferramentas de Integração Contínua
A aplicação CruiseControl é open source e gratuita e atualmente é a referência para
integração contínua. O CruiseControl foi desenvolvido originalmente em 2001 pela
ThoughtWorks, empresa de Martin Fowler. Hoje é mantida e desenvolvida por voluntários
dispostos a melhorar e disponibilizar novas funcionalidades. A aplicação permite que builds
sejam executados a partir de diferentes ferramentas (Java, Dot Net e Ruby), a integração com
diferentes controles de versão como SVN, CVS e Git, além de realizar notificações de
diferentes formas (e-mail, Jabber IM, RSS, Logging). Sua instalação é simplificada, porém a
configuração é complexa e não possui controle de acesso (KOFMAN, 2009).
Outra ferramenta muito conhecida no mercado, é a Hudson, liberada inicialmente em 2006.
Assim como a ferramenta anterior, permite builds através de Java, Dot Net, Ruby e Python,
possui integração com SVN, CVS e Git, e também realiza notificações de diversas formas.
Dentre as ferramentas mais conhecidas, esta possui instalação mais simplificada, configuração
e uso intuitivos, além de suportar controle de acesso. Em 2011, houve uma negociação com a
Oracle e uma separação de equipes, criou-se então o projeto Jenkins que passou a ser
desenvolvido em paralelo com a ferramenta Hudson.

29
CAPÍTULO 3
AS FERRAMENTAS DE TRABALHO DO DEVOPS
1. Infraestrutura ágil
Os desenvolvedores e os administradores de sistema sempre tiveram um conflito: equanto os
primeiros querem colocar suas aplicações em produção o mais rápido possível, o time de
operações, por outro lado, querem ter certeza que a aplicação está estável o suficiente para
entrar em produção sem gerar incidentes (CARVALHO, 2013).
Nos últimos anos esse conflito foi latente no mundo de TI, algumas empresas tinham regras
tão rígidas que só permitiam deploy uma vez por semana - em casos mais rígidos apenas uma
vez por mês, com o objetivo de proteger o negócio.
Com a equipe de desenvolvimento aplicando metodologias ágeis em seu processo, é
incompatível com um método que restrinja o número de deploys. Com isso a equipe de
infraestrutura teve que evoluir erroneamente, apenas aumentando a frequência com que
realizava os deploys, sem mudar o método com que assim o fazia. Gerando, assim, um
gargalo no processo, pois não era possível atender às demandas.
Além da questão do aumento de demandas, o fato de que o ambiente que os desenvolvedores
utilizam não é o mesmo que o ambiente da equipe de operações, gerando incidentes
constantes por conta dessa diferença, causando uma enorme perda de valor no negócio, pois o
cliente se depara com o mesmo problema diversas vezes.
Visto isso, torna-se necessário que a equipe de infraestrutura evolua, passando a trabalhar de
forma automatizada e dinâmica, aumentando assim a velocidade em que os ambientes sejam
postos em produção. Os desenvolvedores, por outro lado, precisam ter um maior controle
sobre todas as fases do deploy, interagindo com a equipe de operações constantemente.
Foi a busca de soluções para estas necessidades apresentadas que motivou importantes
discussões no ramo da TI. Começou a ser discutido o termo Infraestrutura ágil no ano de
2008.

30
A discussão acerca de infraestrutura ágil ganhou força com o crescimento de duas tendências,
são elas virtualization e cloud computing. Desde 2003 empresas começaram a conviver com
ambientes virtualizados, logo poucas máquinas físicas poderiam se tornar dezenas máquinas
virtuais. Somando-se a isso, temos o recente advento da computação em nuvem, dezenas de
máquinas virtuais podem se tornar centenas ou milhares de instâncias a serem administradas
na nuvem.
Não havia mais espaço para a infraestrutrua da forma tradicional, foi necessário evoluir e
pensar em infraestrutura como código. Um fator que impulsionou essa necessidade foi o
crescimento das startups, empresas pequenas com produtos de enorme alcance, produtos que
são executados em centenas de instâncias na nuvem, atendendo a milhões de usuários, e em
que todos os sistemas são administrados por equipes mínimas.
O objetivo da infraestrutura ágil é fazer deploy não só de aplicações, mas de toda a
infraestrutura de forma rápida e controlada. Essa cultura estimula o uso de diversas
ferramentas para automatizar o maior número de atividades. Essas ferramentas podem ser de
três tipos:
 Orquestradores: permitem a execução de comandos e o controle de todas as instâncias
de servidores de uma organização em tempo real. Alguns exemplos dessas ferramentas
são: Fabric, Capistano, Func e Mcollective.
 Ferramentas para gerenciamento de configurações: controlam os estados do sistema,
centralizando todas as suas configurações, facilitando a administração e a criação de
novos ambientes. As ferramentas Puppet, Chef, Cfegine e Salt se enquadram nessa
categoria.
 Ferramentas para bootstrapping e provisionamento: auxiliam na instalação de um
sistema operacional, seja em uma máquina física, seja em uma máquina virtual ou até
mesmo uma instância na nuvem. Alguns provedores de nuvem, como AWS e
Rackspace já oferecem essa utilidade nativamente. No entanto, existem algumas
ferramentas como a Kickstart e a Cobbler que atuam nesse segmento.
A equipe que representa essa metodologia, segue diversas práticas do SCRUM e do Kanban.
Trabalham com o versionamento do código e utilizam arquivos de configuração; organizam
suas atividades em quadros visuais; podem atuar em pares; dividem suas atividades em
sprints; realizam reuniões diárias e também as periódicas de retrospectiva e de planejamento.

31
2. Containers
Diversas ferramentas configuráveis automatizam o processo de criação e uso do ambiente em
que a aplicação é desenvolvida, testada e executada. Essas feramentas geram containers, que
encapsulam todas as informações necessárias para que a aplicação seja executada
corretamente.
Em fevereiro de 2004, Dennis Clarke publicou o primeiro documento sobre Solaris Zones e
Containers. Nesse documento, explicou que um Container Solaris era constituído por
controles de recursos do sistema e por Zones. Cada uma dessas Zones agiam como servidores
virtuais isolados, oferecendo um abiente completo a fim de possibilitar a execução de
aplicações no sistema. A ideia central de Clarke era de reduzir custos das equipes de
operações e ao mesmo tempo prover seguraça às aplicações a partir da consolidação de
diversos conjuntos de serviços de aplicações em um único sistema e colocando cada um em
recipientes de servidores virtuais isoladas.
Mais tarde, em 2008, nasceu o projeto LXC (Linux Container), novamente utilizando o
conceito de um container. O objetivo desse projeto era de criar um novo método de
virtualização de sistema operacional sem a necessidade de emular um sistema físico. Cada
container continha seu próprio processo, alem de ser isolado na rede, simulando uma cópia
completa do sistema operacional Linux. A sua vantagem sobre a virtualização comum, é de
que não era mais necessária a execução de um hypervisor de segundo nível, como o
VirtualBox por exemplo.
Em 2013, a companhia Docker, Inc. desenvolveu um projeto open source, a fim de entregar
diversas ferramentas para auxiliar os desenvolvedores a construir aplicações e para ajudar
administradores a gerenciar melhor essas aplicações. O foco desse projeto é de automatizar a
implantação de aplicativos dentro de containers, fornecendo uma camada adicional de
abstração e automação de virtualização de sistema de nível operacional em Linux, Mac OS e
Windows (NOYES, 2013).
3. Ferramentas de Gerenciamento de Configuração

32
Todo projeto de software possui suas dependências - serviços sendo executados em segundo
plano, linguagens de programação, servidores web, entre outros. Diversas vezes, as etapas
necessárias para a aplicação ser executada não são documentadas e geralmente são
trabalhosas. Segundo Martin Fowler, um ambiente configurado manualmente é chamado de
snowflake. Este geralmente não possui backup, e se houver alguma falha de disco, muito
trabalho será exigido a fim de executar novamente a aplicação em um ambiente estável.
O processo de provisionamento é um conjunto de etapas executáveis, normalmente em
scripts, que podem ser aplicadas em uma imagem inicial de sistema a fim de se obter um
ambiente configurado corretamente. Esse processo traz como benefício a repetibilidade em
ambiente de produção e uma documentação executável dos procedimentos para configuração.
Hoje, existem diversas ferramentas de Gerenciamento de Configuração para provisionar o
ambiente de hospedagem da aplicação, cada uma com seus benefícios e peculiaridades. As
mais utilizadas são Puppet, Chef e Ansible (HUMBLE, 2014).
3.1. Puppet
Ferramenta criada pela empresa Puppet Labs, fundada em 2005 (PUPPET), é capaz de
orquestrar servidores em nuvens públicas e servidores virtuais e físicos. Muitas organizações,
incluindo Google, Twitter, Oracle e Rackspace, utilizam o Puppet para gerenciar sua
infraestrutura. Ela é compatível com diversos sistemas operacionais, incluindo Linux e
Windows.
A configuração inicial é relativamente simples, necessita da instalação de um servidor
chamado Puppet Master e de agentes chamados de Puppet Agent que devem ser instalados em
cada um dos servidores que serão gerenciados.
O Puppet possui duas versões: uma comercial chamada Puppet Enterprise e uma open source
chamada Puppet OpenSource. A versão comercial possui alguns recursos nativos adicionais e
uma interface gráfica poderosa para o Puppet Master, a versão open source não fica muito
atrás, pois embora muitos dos recursos não sejam nativos, podem ser encontradas versões
alternativas que podem ser configuradas.
Os scripts Puppet, chamados de Manifests, são escritos utilizando uma linguagem de
programação própria declarativa e muito simples, mas também pode ser utilizada a linguagem
Ruby para realizar ações mais complexas e avançadas.

33
O Puppet usa o conceito de servidor principal que centraliza a configuração entre os nós e
agrupa esses nós conforme seu tipo (PUPPET DOCS). Cada agente Puppet é executado como
um daemon, permitindo implementar mudanças de infraestrutura em vários nós
simultaneamente. Seu funcionamento é semelhante a um gerenciador de implementação,
porém em vez de implementar aplicativos, implementa mudanças de infraestrutura.
O Puppet inclui uma ferramenta chamada facter. O facter contém metadados sobre o sistema
e pode ser usado para filtragem entre servidores.
3.2. Chef
A ferramenta Chef (CHEF), criada pela Opscode encontra-se disponível no mercado desde
2009, oferece suporte para várias plataformas, incluindo Ubuntu, Debian, RHEL/CentOS,
Fedora, Mac OS X, Windows 7 e Windows Server. Em comparação com o Puppet, é
considerado mais fácil de se utilizar especialmente por desenvolvedores, pois todas as
instruções do Chef são escritas na linguagem Ruby e segue um modelo com o qual os
desenvolvedores estão acostumados a trabalhar. Assim como o Puppet, possui duas versões,
uma open source e outra Comercial.
Os componentes do Chef (CHEF DOCS) fazem analogia aos componentes de uma cozinha:
os scripts são chamados de receitas (recipes), o conjunto dessas receitas é denominado Livro
de Receitas (cookbooks), atributos (attributes) são as definições necessários para a instalação
de um componente, e o componente denominado faca (knife) é a ferramenta em linha de
comando utilizada para o gerenciamento dos recursos do servidor. Diferente do Puppet, o
Chef não possui uma linguagem própria e as receitas são escritas utilizando Ruby .
No Chef, três componentes centrais interagem entre si: o servidor Chef (Chef Server), os nós
e a estação de trabalho Chef (Chef Workstation). O Chef executa os cookbooks, que
consistem em receitas que realizam ações automatizadas em nós, como por exemplo instalar e
configurar software ou adicionar arquivos. O servidor contém dados de configuração para
gerenciar diversos nós. Os arquivos e recursos de configuração armazenados no servidor Chef
são capturados pelos nós quando solicitados.
Os usuários interagem com o servidor Chef usando a interface de linha de comando do Chef.
Os nós podem ter uma ou mais funções (roles). Cada função define as configurações
específicas do nó em conjunto com as receitas para aquele nó. As receitas em um nó,

34
chamadas de lista de execução, são executadas na ordem em que estão listadas. Uma estação
de trabalho Chef é uma instância com um repositório Chef local e a ferramenta de linha de
comando instalados (47LINE, 2014).
Na Figura 6, o administrador solicita uma nova instância de servidor na nuvem, nesse caso no
AWS. Quando a nova instância começa a ser executada, ele faz contato com o servidor Chef e
transfere o cliente chef. Neste ponto, um handshake seguro ocorre e o servidor Chef gera um
certificado de segurança que irá autenticar as solicitações futuras da nova instância. A nova
instância executa as receitas de configuração que o servidor envia a ele, dependendo do seu
papel na aplicação geral. Como um efeito colateral, o estado do servidor Chef é modificado.
Por exemplo, sua lista de servidores web é atualizada com o nome da nova instância. Isto
permite que todos os outros nós se ajustem com a presença do novo servidor. Por exemplo,
balanceadores de carga seria atualizados com o endereço IP do novo servidor.
Figura 6 – Arquitetura da ferramenta Chef
3.3.Ansible
Nos últimos anos, o Chef e o Puppet ganharam notoriedade no mundo de gerenciamento de
configuração, no entanto ambos apresentam alta complexidade para sua operacionalização. O
Ansible (ANSIBLE) é um projeto open source, versionado pelo Git, focado em ambientes
complexos e em nuvem em que há necessidade de gerenciamento de grupos de nós. O Ansible
é independente de linguagem de programação, utiliza o SSH como camada de comunicação,

35
possui fácil instalação e é capaz de se integrar com qualquer linguagem com suporte a JSON
(DEHAAN, 2013).
No Ansible, os nós gerenciados (máquinas remotas) não necessitam de instalações de
software, ou seja, não há necessidade de instalar o Ansible em si, nem quaisquer de suas
dependências. Um arquivo de inventário, chamado "hosts", é responsável por determinar
quais nós se deseja gerenciar. Trata-se de um arquivo texto simples que lista os nós
individuais ou grupos de nós (por exemplo, servidores de DNS e servidores web), ou um
programa executável que gera um inventário de "hosts" e variáveis. A arquitetura do Ansible
pode ser vista na Figura 7.
Os Playbooks são os arquivos de gerenciamento de configuração, onde são descritos os perfis
dos servidores, e as tarefas que devem ser executadas. Segue o padrão YAML, formato de
codificação de dados com sintaxe próxima a linguagem humana, inspirado em XML e JSON
(HOCHSTEIN, 2014).
Figura 7 – Arquitetura do Ansible
Ansible implementa um modelo de idempotência, onde o administrador apenas descreve o
estado desejado do sistema ou do serviço, não as tarefas necessárias para chegar àquele
estado. Assim, não importa em qual estado o sistema esteja, o Ansible sabe como aplicar as
mudanças até chegar ao estado desejado, permitindo, assim, configurações confiáveis e
repetíveis, evitando problemas de scripts que executam ações irreversíveis (COSTA, 2013).
Ele é baseado no sistema de gerenciamento remoto OpenSSH. Está disponível em diversas
plataformas, é muito leve e problemas de segurança são rapidamente resolvidos.

36
O Ansible não precisa de agentes remotos, seu funcionamento é baseado no envio de módulos
e na execução das tarefas necessárias para chegar às configurações desejadas. Esses módulos
são executados com credenciais fornecidas pelo usuário, não sendo necessário o acesso root,
chaves SSH ou usuários dedicados, além disso respeita o modelo de segurança do sistema em
que está hospedado.
3.4.Comparativo entre Puppet, Ansible e Chef
Em 2013, a revista InfoWorld fez um estudo de escalabilidade, disponibilidade, desempenho,
valor aquisitivo, gestão e interoperabilidade da versão comercial das ferramentas a fim de
traçar um comparativo entre elas. A partir de sua análise, pontuou cada um dos fatores com
notas entre zero e dez. Na Figura 8 estão demonstrados os resultados desse comparativo
(INFOWORLD, 2013).
Figura 8 – Resultados comparativos entre Puppet, Chef e Ansible.
De acordo com essa análise, inferiram que as feramentas Puppet e Chef são mais voltadas
para os desenvolvedores, já o Ansible é mais sintonizado com as necessidades dos
administradores de sistemas. Com relação ao custo, até 10 máquinas o suporte é gratuito,
acima disso pode custar de 100 a 250 dólares por máquina por ano.
O Puppet é o mais maduro e mais acessível entre eles, porém um alto conhecimento de Ruby
se faz necessário. Este não é tão flexível quanto o Ansible e sua configuração pode ser

37
complexa. Para ambientes heterogêneos é preferível em relação aos outros dois. Com relação
ao custo, a versão para empresas custa aproximadamente 100 dólares por máquina a cada ano.
O Chef possui um layout estável e bem projetado. Com relação a recursos, possui menos
suporte do que o Puppet. Além disso, pode representar uma curva de aprendizado mais alta
para os administradores de sistema que não possuem experiência com desenvolvimento. Com
relação ao custo, até 5 máquinas o suporte é gratuito, até 20 máquinas representa 120 dólares
por mês, até 50 máquinas 300 dólares e até 100 máquinas pode representar um custo de 600
dólares por mês.
4. Ferramentas de virtualização por containers
Os containers extendem o princípio de “escreva uma vez e implante em qualquer lugar” pois
fornecem um conjunto de blocos comuns de implementação que podem ser reutilizados em
qualquer estágio a fim de replicar o ambiente de desenvolvimento, de teste ou de produção
quando necessário (GOMES, 2015). Promovendo unidades reutilizáveis que podem executar
qualquer segmento de um pipeline de entrega. Além disso, é possível injetar serviços nesses
containers permitindo aos desenvolvedores codificar com maior produtividade, gerando assim
maior valor ao negócio. A ferramenta mais conhecida pela comunidade de tecnologia é a
Docker.
O objetivo da virtualização por Máquinas Virtuais é de compartilhar os recursos físicos entre
vários ambientes isolados, sendo que cada um deles tem sob sua tutela uma simulação de
máquina completa (sistema operacional, memória, disco, processador, rede etc.) todos
entregues via abstração de virtualização. Isto é, dentro de uma máquina física são hospedadas
máquinas menores e independentes entre sí. Cada máquina tem seu próprio sistema
operacional completo, que por sua vez interage com todos os hardwares virtuais que lhe foi
entregue pelo modelo de virtualização a nível de máquina. Vale ressaltar que o sistema
operacional instalado dentro de uma máquina virtual fará interação com os hardwares virtuais
e não com o hardware real.
O modelo de virtualização por containers está no nível de sistema operacional, ou seja, ao
contrário da máquina virtual um container não tem a visão de uma máquina completa, ele é
apenas um processo em execução em um kernel compartilhado entre todos os outros
containers. Os containers utilizam o namespace (atributo do Linux que permite criar

38
contextos diferentes em um mesmo sistema operacional) para prover o devido isolamento de
memória RAM, processamento, disco e acesso a rede, ou seja, mesmo compartilhando o
mesmo kernel, esse processo em execução tem a visão de estar operando um sistema
operacional dedicado.
Na Figura 4 podem ser observadas as diferenças entre a virtualização por Máquinas Virtuais e
por Containers no nível arquitetural.
Figura 9 – Diferença Arquitetural entre Máquinas Virtuais e Containers
4.1. Docker
O Docker foi lançado como um projeto open-source pela empresa dotCloud (DOCKER),
voltada para o desenvolvimento de Plataforma como Serviço (do inglês Platform as a
Service), em 2013.
Assim que foi disponibilizado no mercado, a empresa lançou um tutorial interativo em que
mais de dez mil desenvolvedores participaram. Após um ano, empresas como Red Hat e
Amazon passaram a apoiar comercialmente o projeto e em Junho de 2014, em sua versâo 1.0,
seu número de downloads quase alcançava três milhões. Hoje esse número já está em mais de
cem milhões e tende a ascender visto o crescimento da computação em nuvem e da
implantação do DevOps pelas empresas,
É um projeto que automatiza o desenvolvimento de aplicações em containers, provendo uma
camada adicional de abstração no nível de virtualização de sistema operacional com kernel

39
Linux, permitindo que diversos containers consigam ser executados utilizando uma mesma
instância de Linux, sem tanta sobrecarga.
Docker implementa uma aplicação de alto nível a fim de gerar containers leves que executam
processos de forma isolada. Diferentemente de uma Máquina Virtual, cada container utiliza
uma funcionalidade do kernel, que permite separar uma parte dos recursos de hardware
disponíveis de forma isolada para cada container (DOCKER DOCS).
As funcionalidades do Docker se resumem a:
 Portabilidade de implantação: define um formato para empacotar a aplicação e suas
dependências em um único objeto que pode ser transferido para qualquer máquina
compatível com Docker e será garantida sua execução já que o ambiente é o mesmo.
 Centrado na aplicação: é otimizado para a implantação de aplicações, como visto em
sua API, interface de usuário, filosofia e documentação.
 Build automático: inclui uma ferramenta para os desenvolvedores que
automaticamente constrói um container a partir do seu código fonte, fornecendo
controle total sobre suas dependências, ferramentas e configurações.
 Versionamento: inclui ferramenta similar ao Git para controle de versão do container.
 Reutilização de componentes: qualquer container pode ser utilizado como uma
imagem-base para criar componentes mais especializados.
 Compartilhamento: possui um registro público onde milhares de usuários podem
compartilhar seus containers. Além disso, possui uma biblioteca padrão com diversos
containers úteis mantidos pela própria equipe Docker.
5. Ferramentas de virtualização por Máquinas Virtuais
O Vagrant é uma ferramenta configurável para criar e distribuir ambientes de
desenvolvimento (VAGRANT). Ela isola as dependências necessárias para criar um ambiente
de desenvolvimento, agilizando assim configuraçõs posteriores. Auxilia no teste de
aplicações, permitindo uma simulação mais próxima da realidade, já que o ambiente será
semelhante ao de produção. Além disso, facilita o compartilhamento do ambiente para todos
os integrantes da equipe. Utiliza uma máquina virtual que isola um hardware virtual a partir
da máquina física real, permitindo o uso de sistema operacional e softwares próprios.

40
A plataforma de máquina virtual mais utilizada pelo Vagrant é o Virtualbox (VIRTUAL
BOX), ferramenta de virtualização da Oracle, que é multi-plataforma e pode executar uma
extensa quantidade de sistemas operacionais, além de permitir limitar a quantidade de
memória RAM, CPU e disco. A partir de alguns comandos do Vagrant, a máquina virtual é
iniciada, provisionada e configurada.
Na Figura 10 pode verificar-se uma arquitetura utilizando Vagrant, Virtual Box e algum
provisionador de configuração como Puppet, Chef ou Ansible.
Figura 10 – Arquitetura Vagrant, Virtual Box e Provisionador

41
Conclusão
As organizações responsáveis por entregar software tendem a forcar seus esforçoes a fim de
acelerar as entregas. Esse vem sendo o principal fator incentivador das inovações realizadas
ao longo dos últimos cinco anos. Os clientes, por um lado, visando a mobilidade e as redes
sociais, a indústria,por outro, focando no mercado de big data e em análises avançadas,
colaborando para o crescimento da Economia Digital.
Para avaliar a eficiência da aplicação do DevOps, foi realizado em 2015 pela IBM (CRAIG,
2015), uma pesquisa de mercado envolvendo as principais referências de entrega de software.
A entrevista continha 65 questões e mais de 200 itens com relacionados aos dados e foi
respondida por mais de 400 profissionais de TI. Dentre esses profissionais, 38%
corresponderam a cargos executivos, 34% a gerência e o restante dos 28% foram respondidas
por especialistas. Com relação ao tamanho da organização, empresas pequenas com menos de
250 funcionários foram excluídas da pesquisa, 14% dos entrevistados representavam
empresas com menos de 1000 funcionários, 50% eram de empresas com 1000 a 9999
funcionários e o restante dos 36% de empresas com mais de 10000 funcionários.
Como as aplicações se tornaram mais complexas ao longo dos anos, o trabalho de entregar
software necessita cada vez mais de equipes multidiciplinares e altamente flexíveis. Esse
crescimento pôde ser observado inicialmente com o advento da Arquitetura Orientada a
Serviços, do inglês Service Oriented Architecture (SOA). Tais serviços começaram a ser
amplamente utilizados por diversos departamentos, levantando muitos questionamentos com
relação à segurança e à performance. O mercado foi, então, induzido a buscar ou desenvolver
recursos adicionais para melhorar a infra-estrutura dos projetos. Visto essa necessidade, o
DevOps emergiu como produto de complexidade e de recursos compartilhados.

42
Nessa pesquisa de mercado, a IBM constatou que 97% das empresas já possuem equipes de
DevOps. Em 60% dos casos, têm equipes constituídas de profissionais DevOps dedicados. No
entanto, apenas em 25% desses casos, essas equipes são nomeadas de equipes de DevOps.
A Figura 11 representa o nível de envolvimento das equipes de DevOps em cada etapa de um
projeto de desenvolvimento de software de acordo com essa pesquisa.
Figura 11 – Equipes de DevOps envolvidas por etapa do ciclo de vida de um projeto de software
Além disso, com essa pesquisa, verificou-se que grande parte das empresas considera o
processo de Entrega Contínua de suma importância para o crescimento do negócio e para a
satisfação dos clientes. Porém, de acordo com essa análise, esse processo pode gerar uma
redução na qualidade das entregas além de possibilitar um aumento de custos a fim de
administrar o ambiente de produção com maior cautela, já que o mesmo é utilizado com uma
frequência mais elevada. Com relação a frequência de entregas, constatou-se que, com relação
às empresas que praticam Entrega Contínua, aproximadamente 65% realizam entregas ao
menos uma vez por semana. A Figura 2 demonstra as frequências mais comuns dentre essas
empresas.

43
Figura 12 – Frequência de entrega para produção
Traçando uma comparação entre a frequência de entrega e o crescimento da receita, inferiu-se
que as empresas que tiveram um aumento na continuidade de entrega em 10% ou mais,
tiveram 2,5 vezes mais chance de obter um aumento da receita em pelo menos 10%, se
comparado com as empresas que ampliaram as entregas em menos de dois dígitos. Verificou-
se, ainda, que o avanço da receita está diretamente interligado com a qualidade da
comunicação entre o time de desenvolvimento e o time de operações. As organizações que
responderam que as interações entre os dois times eram excelentes ou acima da média eram
11,5 vezes mais favoráveis a ter um crescimento de dois dígitos do que as que responderam
que a comunicação era na média ou muito fraca (CRAIG, 2015).
A prática de DevOps tem se tornado um dos pilares da indústria, apesar de que apenas 25%
dos entrevistados tinham a mesma visão do ciclo de vida do DevOps do que o EMA
(Enterprise Management Associates). Assim como a Entrega Contínua também está ganhando
força no mercado, porém de modo mais lento pois requer aceleração ao longo de toda o ciclo
de vida de um projeto de software.
Verificou-se que a Entrega Contínua tem acelerado a taxa de mudança no ambiente de
produção. As análises dessa entrevista também confirmou, assim como muitas organização de
TI acreditavam, que o processo de acelerar as entregas geralmente gera um crescimento nos
problemas em produção.

44
A automação de tarefas, tais como manipulação dos dados de teste, configuração do ambiente
de teste, execução de testes, deploy da aplicação e resolução de erros em produção, sempre foi
uma das melhores práticas a fim de garantir qualidade da aplicação, pois minimiza a
possibilidade de erros humanos inerentes em processos de múltiplas fases. O mercado está
caminhando para um ponto em que a falta de automação pode significar no fim do negócio. A
demanda por automação é crescente, e constantemente são desenvolvidas novas ferramentas
com essa finalidade.

45
REFERÊNCIAS BIBLIOGRÁFICAS
MUELLER, Ernest (2010). What is Devops? Disponível em:https://theagileadmin.com/what-
is-devops/. Acesso em: 17 de Julho de 2015.
PAUL, Fredric (2014). The Incredible True Story of How DevOps Got Its Name. Disponível
em: https://blog.newrelic.com/2014/05/16/devops-name/. Acesso em: 5 de Julho de 2015.
LIRA, Arllen (2015). DevOps versus metodologias tradicionais. Como conduzir a transição?
Disponível em: http://computerworld.com.br/devops-versus-metodologias-tradicionais-como-
conduzir-transicao. Acesso em: 3 de Novembro de 2015.
GARTNER (2016). Apply Three Economic Principles to Help Win Approval of Major I&O
Business Cases.
CUNNINGHAM, Ward (2001). Manifesto para Desenvolvimento Ágil de Software.
Disponível em: http://www.agilemanifesto.org/. Acesso em: 5 de novembro de 2015.
SHARMA, Sanjeev; COYNE, Bernie (2015). DevOps for Dummies. Estados Unidos: John
Wiley & Sons, 2015.
RIGHTSCALE (2016). State of the Cloud Report.
NETFLIX (2011). NetFlix Simian Army. Disponível em:
http://techblog.netflix.com/2011/07/netflix-simian-army.html. Acesso em: 10 de maio de
2016.
HOWARD, Chris (2014). The Nexus of Forces Is Creating the Digital Business.
RILEY, Chris (2014). How to Keep CALMS and Release More! Disponível em:
https://blog.logentries.com/2014/10/how-to-keep-calms-and-release-more/. Acesso em: 12 de
Janeiro de 2016.
PUPPET LABS (2015). State of DevOps Report.
REID, Lee (2015). The Simple Math of DevOps. Disponível em:
http://devops.com/2015/06/22/the-simple-math-of-devops/. Acesso em: 22 de Julho de 2015.

46
HUMBLE, Jez; FARLEY, David (2010). Continuous Delivery. Indiana: Pearson Education,
2011.
CHACON, Scott; STRAUB Ben (2014). Pro Git - Everything you need to know about Git.
Mountain View: Apress, Second Ed., 2014.
FOWLER, Martin (2006).Continuous Integration. Disponível em:
http://martinfowler.com/articles/continuousIntegration.html. Acesso em: 20 de Janeiro de
2016.
KOFMAN, Vlad (2009). The Best Continuous Integration Tools. Disponível em:
http://www.developer.com/open/article.php/3803646/The-Best-Continuous-Integration-
Tools.htm. Acesso em: 12 de Fevereiro de 2016.
CARVALHO, Guto (2013). O que é DevOps afinal? Disponível
em:http://gutocarvalho.net/octopress/2013/03/16/o-que-e-um-devops-afinal/. Acesso em: 18
de Dezembro de 2015.
NOYES, Katherine (2013). Docker: A 'Shipping Container' for Linux Code. Disponível em:
https://www.linux.com/news/docker-shipping-container-linux-code. Acesso em: 15 de Março
de 2016.
HUMBLE, Jez (2014). The State of DevOps, 6 de Junho de 2014. Disponível em:
https://www.thoughtworks.com/. Acesso em: 25 de Maio de 2016.
PUPPET. Disponível em: https://puppet.com/. Acesso em: 25 de Novembro de 2015.
PUPPET DOCS. Disponível em: https://docs.puppet.com/. Acesso em: 25 de Novembro de
2015.
CHEF. Disponível em: https://www.chef.io/chef/. Acesso em: 28 de Novembro de 2015.
CHEF DOCS. Disponível em: https://docs.chef.io/. Acesso em: 29 de Novembro de 2015.
47LINE Technologies (2014). Configuration Management – Introducing Chef. Disponível
em: http://cloudacademy.com/blog/configuration-management-introducing-chef/. Acesso em:
29 de Novembro de 2015
ANSIBLE. Disponível em: https://www.ansible.com/ .Acesso em: 15 de Dezembro de 2015.

47
DEHAAN, Michael (2013). Ansible's Architecture: Beyond Configuration Management.
HOCHSTEIN, Lorin (2014). Ansible: Up and Running.
COSTA, Marcelo (2013). Ansible: uma nova opção para gerenciamento de configuração.
Disponível em: https://www.infoq.com/br/news/2013/04/ansible1.1. Acesso em: 15 de Maio
de 2016
INFOWORLD (2013). Review: Puppet vs. Chef vs. Ansible vs. Salt. Disponível em:
http://www.infoworld.com/article/2609482/data-center/data-center-review-puppet-vs-chef-vs-
ansible-vs-salt.html. Acesso em: 8 de Maio de 2016.
DOCKER. Disponível em: https://www.docker.com/. Acesso em: 4 de Abril de 2016.
DOCKER DOCS. Disponível em: https://docs.docker.com/. Acesso em: 4 de Abril de 2016.
GOMES, Rafael (2015). POR QUE CONTAINERS? Disponível em:
http://techfree.com.br/2015/10/por-que-containers/. Acesso em: 15 de Fevereiro de 2016.
VAGRANT. Disponível em: https://www.vagrantup.com/. Acesso em: 15 de Abril de 2016.
VIRTUAL BOX. Disponível em: https://www.virtualbox.org/. Acesso em: 15 de Abril de
2016.
CRAIG, Julie (2015). Automating for Digital Transformation.

Monografia-Devops

Mais conteúdo relacionado

Mais procurados

Destaque

Semelhante a Monografia-Devops

Monografia-Devops