DevOps em Sistemas de Informação

Prévia do material em texto

i 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
DevOps em Sistemas de Informação 
 
Francisco de Oliveira Rato 
Implementação em Operações de Tecnologias de 
Informação 
Dissertação apresentada como requisito parcial para 
obtenção do grau de Mestre em Gestão de Informação 
 
 
 
i 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
MEGI 
2
0
1
7
 
Título: DevOps em Sistemas de Informação 
Subtítulo: Implementação em Operações de Tecnologias de Informação 
Francisco de Oliveira Rato MGI 
i 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ii 
 
NOVA Information Management School 
Instituto Superior de Estatística e Gestão de Informação 
Universidade Nova de Lisboa 
 
 
DEVOPS EM SISTEMAS DE INFORMAÇÃO 
por 
Francisco de Oliveira Rato 
 
 
 
 
 
 
Dissertação apresentada como requisito parcial para a obtenção do grau de Mestre em Gestão de 
Informação, especialização em Gestão de Sistemas e Tecnologias de Informação. 
 
 
 
Orientador: Prof. Doutor Rui Gonçalves 
 
 
 Novembro de 2017 
iii 
 
DEDICATÓRIA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
À minha família e amigos, 
Que atinjam sempre os seus objetivos e sejam felizes à sua maneira 
 
 
iv 
 
AGRADECIMENTOS 
Aos meus pais, Paulo e Célia, por toda a ajuda e confiança depositada ao longo dos anos, sem eles 
nenhum dos meus graus académicos seria atingível – que todo o seu esforço e sacrifício empregue em 
prol do meu desenvolvimento enquanto pessoa tenha todos os frutos por eles idealizados; 
Ao meu irmão Guilherme, um sincero agradecimento pela companhia ao longo destes anos e que os 
ensinamentos e exemplos que lhe transmiti enquanto irmão lhe sejam sempre úteis. 
Aos meus avós, Martinho e Clementina, pelo carinho e apoio que me deram desde que nasci e por 
terem formado a sua filha de forma exemplar o que me ajudou a ultrapassar muitas dificuldades ao 
longo da vida. Que vivam estes e muitos outros momentos de felicidade por longos anos. 
Ao meu falecido avô Júlio, que sempre foi um forte sustento para o meu pai e um exemplo para mim 
– que a sua memória perdure por muitos anos. À sua mulher Lurdes, por todo o carinho demonstrado 
em diversos momentos da minha vida e à minha avó Filipa pelo apoio à formação pessoal do meu pai. 
Aos meus tios, Marta, Rui e Isabel, e ao meu primo Daniel, por todo o afeto transmitido durante o meu 
crescimento e apoio à formação do meu pai e irmão e ao resto da minha família, tios e primos de 
outros graus e afastados, pelos bons momentos vividos e amizade genuína. 
Aos meus amigos, e em especial, ao António Fernandes e Filipe Passinhas, que me ajudaram a 
ultrapassar muitos desafios ao longo da vida e foram cruciais para o meu crescimento – todo o seu 
apoio ao longo destes anos é devidamente reconhecido e será para sempre estimado. 
Ao meu colega e amigo, Bernardo Martins, por todo o seu apoio e companheirismo durante a 
elaboração desta dissertação, que me ajudou a prosperar e auxiliar à finalização do mestrado. Ao meu 
orientador Prof. Dr. Rui Gonçalves, pela disponibilidade revelada, assim como pelas críticas, correções 
e sugestões feitas. 
Aos meus colegas e amigos da Accenture, que me ajudaram no desenvolvimento enquanto profissional 
e me proporcionaram bons momentos a nível pessoal , a todos um sentido agradecimento. 
Por fim, a uma das pessoas mais importantes na minha vida, Carlota Lousada, que apesar de só ter 
conhecido no último ano do curso, se revelou essencial para atingir os meus objetivos e me apoiou 
incessantemente ao longo dos últimos três anos. Um agradecimento também à sua família por todo o 
afeto e amizade durante estes anos. 
v 
 
RESUMO 
Nas últimas décadas verificaram-se grandes alterações aos paradigmas de desenvolvimento de 
software. Desde o final dos anos 80, o foco era essencialmente a análise de requisitos, evoluindo, nos 
anos 90, para a programação orientada a objetos, que abriu caminho para a implementação de 
metodologias como o Rational Unified Process (RUP), introduzido o desenvolvimento por iterações, 
que transfere o ênfase do planeamento para o desenvolvimento, até aos anos 2000, onde foram 
introduzidas as metodologias Agile, um conjunto de princípios em que os requisitos e soluções 
evoluem através da colaboração e auto-organização de equipas especializadas. Com esta evolução 
natural do Agile, surge o conceito de DevOps. Apesar de semelhantes, ambos os conceitos possuem 
diferenças intrínsecas: o primeiro representa uma mudança de abordagem (pensamento), enquanto o 
que o segundo implementa uma mudança cultural nas organizações. 
A seguinte dissertação contem o desenvolvimento do tema proposto, DevOps em Sistemas de 
Informação, uma metodologia de desenvolvimento que se baseia na interdependência entre o 
desenvolvimento de software e operações de tecnologias de informação, sustentado por um 
framework teórico, relevância e importância do estudo, metodologia e devidos resultados, onde serão 
apresentados alguns casos de estudo sobre o tema e suas particularidades, e, por fim, as conclusões 
da pesquisa. 
 
 
PALAVRAS-CHAVE 
DevOps, Agile, Tecnologias de Informação, Entregas Contínuas, Metodologias de Desenvolvimento 
 
vi 
 
ABSTRACT 
Over the last few decades, we have witnessed major changes to the software development paradigms. 
Since the end of the 80s, the prominence was essentially on requirements’ analysis, evolving, later in 
the 90s, to object oriented programming, which opened the way for development methodologies such 
as the Rational Unified Process (RUP), that introduced iterative and incremental development, 
transferring the emphasis from planning to development, until the turn of the century, where agile 
methodologies were introduced as a set of principles in which results and solutions evolve through 
collaboration and self-organization of specialized teams. With this natural evolution of agile, arises the 
concept of DevOps. Although similar, both concepts possess underlying dissimilarities: the f irst stands 
for a behavioral change, while the second drives a cultural change inside organizations. 
The following thesis contains the embodiment of the proposed subject, DevOps in Information 
Systems, a development methodology based on the interdependence between software development 
and information technology operations, sustained by a theoretical framework, importance and 
relevance of the study, research methodology and its achieved results, where the author will present 
a few case studies on the main topic and its characteristics and, at last, the conclusions of the study. 
 
 
 
KEYWORDS 
DevOps, Agile, Information Technology, Continuous Delivery, Development Methodologies 
 
 
vii 
 
ÍNDICE 
1. Introdução .................................................................................................................... 1 
1.1. Relevância e Importância do Estudo ..................................................................... 4 
1.2. Objetivos................................................................................................................ 8 
2. Revisão da Literatura .................................................................................................... 9 
2.1. Contextualização do Tema ....................................................................................9 
2.2. Contexto Cronológico .......................................................................................... 11 
2.3. Introdução ao DevOps ......................................................................................... 12 
2.4. Conceitos Associados ao DevOps ........................................................................ 16 
2.4.1. Integração Contínua (Continuous Integration) ............................................ 16 
2.4.2. Entregas Contínuas (Continuous Delivery) ................................................... 18 
2.4.3. Implementação Contínua (Continuous Deployment)................................... 20 
2.4.4. Integração dos Conceitos ............................................................................. 21 
2.5. Paralelismo com Agile ......................................................................................... 23 
3. Metodologia ............................................................................................................... 26 
3.1. Processo de Investigação .................................................................................... 27 
4. Resultados e Discussão............................................................................................... 29 
4.1. Introdução ........................................................................................................... 29 
4.2. Caso de Estudo: “SCoT” – Ministério da Administração Interna ........................ 29 
4.2.1. Problema ...................................................................................................... 29 
4.2.2. Solução ......................................................................................................... 30 
4.2.3. Arquitetura ................................................................................................... 31 
4.2.4. Benefícios ..................................................................................................... 32 
4.3. Outros Casos de Estudo....................................................................................... 33 
4.3.1. Capgemini..................................................................................................... 33 
4.3.2. Yahoo Answers ............................................................................................. 34 
4.3.3. Cliente do Sector Industrial .......................................................................... 36 
4.4. Análise Comparativa............................................................................................ 38 
5. Conclusões .................................................................................................................. 41 
6. Limitações e Recomendações para Trabalhos Futuros .............................................. 46 
7. Bibliografia.................................................................................................................. 47 
 
viii 
 
 
ÍNDICE DE FIGURAS 
Figura 1 - Adoção Geográfica do DevOps e por Indústria .......................................................... 2 
Figura 2 - Comparação da alocação de tempo a tarefas de TI................................................... 3 
Figura 3 – Valor relativo à adoção do DevOps ........................................................................... 7 
Figura 4 - Ciclo de Desenvolvimento de Software ................................................................... 14 
Figura 5 - Representação Esquemática do conceito Integração Contínua .............................. 17 
Figura 6 – Representação Esquemática do conceito Entregas Contínuas ............................... 18 
Figura 7 - Representação Esquemática do conceito Implementação Contínua ...................... 20 
Figura 8 – Interfaces Funcionais do SCoT................................................................................. 30 
Figura 9 – Arquitetura do SCoT ................................................................................................ 31 
 
ÍNDICE DE GRÁFICOS 
Gráfico 1 – Gartner Hype Cycle .................................................................................................. 4 
Gráfico 2 – Gartner Hype Cycle de desenvolvimento aplicacional (2015) ................................. 5 
 
ÍNDICE DE TABELAS 
Tabela 1 – Análise comparativa dos três conceitos associados ao DevOps ............................ 22 
Tabela 2 – Comparação entre DevOps e Agile ......................................................................... 24 
Tabela 3 – Analise Comparativa dos Casos de Estudo ............................................................. 40 
 
 
ix 
 
LISTA DE SIGLAS E ABREVIATURAS 
TCO Total Cost of Ownership - Estimativa financeira que determina os custos diretos e indiretos 
de um produto ou sistema; 
ROI Return on Investment - Benefício para um investidor resultante de certo investimento 
efetuado em algum recurso; 
TTM Time to Market - Tempo gasto no desenvolvimento de um certo produto, desde a sua 
conceção ao produto final; 
SCM Software Configuration Management – Conjunto de tarefas responsáveis pelo controlo e 
rastreamento de alterações em determinado software; 
TDD Test Driven Development – Desenvolvimento orientado para ciclos curtos baseado em 
casos de testes diretamente associados aos requisitos inicialmente estabelecidos; 
OLAP Online Analytical Processing – Capacidade para manipular e analisar um grande volume 
de dados sob múltiplas perspetivas. 
DAD Disciplined Agile Delivery – orientação agile na entrega e conceção de soluções de TI 
RAC Oracle Real Application Clusters 
SOA Service-Oriented Architecture – arquitetura de software cujo princípio é as 
funcionalidades implementadas pelas aplicações serem disponibilizadas na forma de 
serviços 
 
 
1 
 
1. INTRODUÇÃO 
Relatórios recentes confirmam que a performance das Tecnologias de Informação (TI) fornece valor 
para o tipo de negócio em que estão inseridos. Empresas de TI de alta performance têm um forte e 
positivo impacto no desempenho geral das organizações que servem e, tais resultados, devem-se 
maioritariamente à organização geral dos serviços, onde a estratégia tem de ser corretamente definida 
desde o início de determinada tarefa (Bitterer, 2011). 
O “2015 State of DevOps Report” refere que estas empresas entregam e implementam soluções de 
software 30 (trinta) vezes mais rápido que as suas análogas e conseguem reduzir até 200 (duzentas) 
vezes os prazos de entrega inicialmente idealizados. Outros números refletem ainda que tais empresas 
experienciam 60 (sessenta) vezes menos falhas e, caso existam, conseguem recuperar das mesmas 168 
(cento e sessenta e oito) vezes mais depressa (Forsgren, Kim, Kersten & Humble, 2015). 
Com estes resultados, é percetível que existe um pensamento lean na gestão de projetos atual, o qual 
pode ser definido como uma filosofia de gestão centrada na melhoria da produtividade, reduzindo ou 
eliminando custos e tempos, visando promover atividades que realmente acrescentam valor para o 
cliente (Loukides, 2012; Womack & Jones, 2010). O pensamento lean consiste também num conjunto 
de princípios que visam simplificar o modo como uma organização produz e entrega valor aos seus 
clientes enquanto os “desperdícios” são eliminados. O ponto de partida é reconhecer que apenas uma 
pequena fração do tempo e esforço de uma organização é convertida em valor (Womack & Jones, 
2010). Após definido o valor de um produto ou serviço na perspetiva do cliente, todas as atividades 
que não acrescentam valor devem ser eliminadas (Bass, Weber & Zhu, 2015). 
O DevOps é essencial no contexto tecnológico moderno, sendo um atributo chave para atingir 
vantagens competitivas. O contexto do tema escolhidoassenta essencialmente na otimização de 
processos e operações, sendo as abordagens idealizadas para o tema relativas a metodologias de 
desenvolvimento, gestão de equipas e gestão operacional. A importância do estudo poderá resumir-
se à necessidade imediata de mudança de paradigmas de desenvolvimento em Portugal e, como é o 
caso dos engenheiros de software, a necessidade de uma melhor compreensão dos contextos de 
negócio e dos objetivos para os quais os sistemas são desenhados e construídos. Compreender o 
conceito de DevOps implica, também, um entendimento dos contextos empresariais e de negócio, tal 
como o contexto técnico e operacional, de maneira a possibilitar um melhor entendimento de 
fenómenos a todos os intervenientes no processo produtivo (Bass, Weber & Zhu, 2015). 
 
2 
 
Na década de 80, a manufatura foi revolucionada pela aplicação de princípios lean. Hoje em dia, são 
as TI que os têm de adquirir. Quando se aplica práticas lean na tecnologia – limitando os processos de 
trabalho, monitorizando a qualidade e produtividade e usando estes dados para melhorar os 
procedimentos de tomada de decisão – obtém-se resultados (Cawley, Wang, Richardson, et al., 2010). 
Por mais que as organizações considerem que já adotam práticas que ficaram conhecidas como 
DevOps, o seu uso não é ainda prescritivo, existindo uma variedade de diferentes manifestações de 
uso em termos de definição e padrão entre as organizações (Braga, 2015), o que eventualmente 
poderá levar à mudança de cultura das empresas, tornando-as orientadas para a performance, subindo 
os níveis de produtividade e aumentando a satisfação dos empregados no local de trabalho (Bass, 
Weber & Zhu, 2015). Por fim, e sendo possível prever e medir a performance das organizações, iremos 
ter melhorias nas mesmas áreas que as possibilitaram, incluindo ainda o aumento na performance 
financeira da empresa em geral (Watson & Wixom, 2007). 
Conforme é possível observar no esquema em baixo, a adoção desta metodologia tem crescido 
bastante no mercado e os percussores da mesma pertencem, na sua maioria, aos Estados Unidos da 
América. Na Europa é um fenómeno mais recente e com menor impacto, mas de acordo com as 
“Indústrias” (à direita) conseguimos inferir que uma das principais áreas de impacto são as tecnologias, 
e que é apenas uma de diversas áreas onde estes procedimentos podem ter consequências. 
 
 
Figura 1 - Adoção Geográfica do DevOps e por Indústria 
(Fonte: Forsgren, Kim, Kersten & Humble, 2015) 
3 
 
A temática oferece também inúmeras vantagens que não se registam com outras metodologias, ágeis 
ou não. Desde serviços digitais orientados ao cliente a complexos sistemas de informação empresariais 
de larga escala, é facilitada a gestão dos ambientes de TI e de negócio juntamente com resultados 
tangíveis, tais como a redução em 20% dos custos de entrega, um aumento até 50% do time to market 
(TTM) e a capacidade de gerar atributos adicionais em dias – ao invés de semanas, ou até meses. 
O esquema seguinte ilustra uma análise comprativa entre alguns indicadores de performance, medidos 
em horas por trabalhador, entre projetos orientados ao DevOps e projetos com arquiteturas 
tradicionais de Tecnologias de Informação. 
Corroborando a informação exposta nos parágrafos anteriores, as estatísticas apresentadas 
demonstram que as equipas perdem ligeiramente mais tempo a automatizar tarefas, gastam menos 
tempos em atividades administrativas, resolvem “incêndios” (termo utilizado para classificar erros 
inesperados) menos frequentemente e que, em geral, não necessitam de fazer tantas horas-extra com 
as equipas de TI tradicionais. 
Figura 2 - Comparação da alocação de tempo a tarefas de TI 
(Fonte: Mathaisel, 2013) 
4 
 
Neste contexto será explorada a organização geral do conceito de DevOps, os princípios e benefícios, 
e ainda a análise de alguns casos de estudo, inferindo a cadeia de valor que este tema verdadeiramente 
representa. No final, o autor conta obter uma reflexão elaborada sobre o tema, com a devida 
sustentação fortalecida ao longo do corpo desta tese, encontrando-se dotado, aquando do seu 
desenvolvimento e conclusão, de conhecimentos que lhe serão úteis futuramente e a quem cons ultar 
este documento. 
1.1. RELEVÂNCIA E IMPORTÂNCIA DO ESTUDO 
Tendo em conta os argumentos anteriores, resta-nos uma interrogação lógica: qual a utilidade do 
DevOps para o contexto empresarial que vivemos? 
Para explicar o estado da aceitação e reconhecimento do termo, recorri ao gráfico 1 da Gartner, 
conhecida empresa de investigação tecnológica, denominado “Hype Cycle”. Este gráfico serve 
precisamente para manter um acompanhamento das novas tendências a nível tecnológico, que está 
diretamente interligado à teoria da difusão de inovações elaborada por Everett Rogers, em que uma 
difusão é descrita como “(…) o processo sobre o qual certa inovação é comunicada através de certos 
canais ao longo de um determinado período de tempo.”. Esta teoria enfatiza ainda que existem quatro 
elementos associados a esta teoria, que são “(…) a inovação, canais de comunicação, tempo e o 
sistema social” – e que são identificados em cada estudo de uma difusão (Rogers, 2003). 
 
Gráfico 1 – Gartner Hype Cycle 
(Fonte: Sicular, 2013) 
5 
 
Ora, de acordo com a teoria de difusão de inovações, o DevOps está plenamente dependente da 
população de praticantes que estaremos a analisar. Ainda assim, podemos identificar duas grandes 
maiorias de praticantes, a maioria antecipada e tardia de adotantes. A maioria antecipada foram os 
que seguiram os princípios do DevOps numa fase temporal mais antiga, ou seja, adotaram-no mais 
cedo que os da maioria tardia. Em relação ao Hype Cycle descrito em cima, um estudo de 2015 da 
Gartner, coloca a maioria antecipada no slope of enlightment, que poderemos traduzir para a “encosta 
da iluminação”, que significa a interiorização do tema e aplicação para as tarefas rotineiras do dia-a-
dia – particularmente, corresponde ao aperfeiçoamento da metodologia e boas práticas associadas no 
gráfico. A maioria tardia estava localizada no peak of inflated expectations (pico das expectativas 
inflacionadas), ou seja, já estavam a adotar o termo fora da tendência geral e ainda não tinham bem 
definidas as suas prioridades e objetivos. 
 
 
Gráfico 2 – Gartner Hype Cycle de desenvolvimento aplicacional (2015) 
(Fonte: Ashutosh, n.d.) 
6 
 
De acordo com a Gartner, num estudo relativo a 2015 de Sobejana & Wilson, o DevOps era colocado 
no pico das expectativas inflacionadas, mas com uma previsão de 5 a 10 anos (legenda) até chegar à 
plena produtividade. Neste estudo é também destacado que “muitas iniciativas transformacionais não 
são suficientemente focadas na redução de riscos, no entanto, através uso iterativo de DevOps e a sua 
adoção a nível arquitetónico, é possível acrescentar valor enquanto se reduz riscos e custos 
operacionais”, e é precisamente aqui que encontramos o verdadeiro valor do DevOps: é uma 
abordagem estratégica e processual que cria valor automatizado e otimizado para o negócio (Sobejana 
& Wilson, 2016). 
Transitando para a relevância financeira do tema, são inúmeros os casos e empresas que 
testemunharam vantagens com esta abordagem. De acordo com um artigo da consultora McKinsey & 
Company sobre a reorganização das TI para uma entrega de software mais rápida, as três maiores 
fontes de valor da adoção do DevOps são: Melhorias no TTM, redução da periodicidade de ciclos e 
aumento da produtividade (fig. 3). Tal é explicado pela eliminação de tarefas de validação de novas 
alterações, sendo tal facto alcançado através da gestão de versionamento e automatização da 
implementação e testes destasnovas alterações. A McKinsey, por Bossert, Ip & Starikova, destaca 
ainda o caso da Netflix, que criou uma arquitetura centrada na cloud que possibilita centenas de 
alterações de software por dia – e tudo devido a uma equipa DevOps que não necessita de requisitar 
recursos da equipa de Operações, pois todas as alterações efetuadas são integradas automaticamente 
na infraestrutura da Netflix, utilizando uma plataforma web-based onde todos os testes são efetuados 
para um nicho limitado de utilizadores. Quando as alterações forem validadas, o tráfego é 
redirecionado para as versões mais recentes, e constantemente acompanhadas por um processo 
automatizado de monitorização que assegura um plano de contingência caso algo não corra como 
planeado: o trafego é redirecionado para a versão antiga até se consumar o aperfeiçoamento. Por este 
mesmo motivo, a Netflix consegue implementar novas alterações dentro de horas, enquanto outras 
empresas concorrentes necessitariam de meses (Bossert, Ip & Starikova, 2015). 
7 
 
 
 
 
 
 
 
 
 
 
 
 
Ainda sobre o tema da relevância, a Infosys apresenta-nos alguns casos de sucesso da implementação 
da metodologia, como por exemplo, no artigo “Global bank improves service quality and saves US $2 
million with Agile & DevOps” (n.d.), um banco que aumentou a qualidade do seu serviço com recurso 
a práticas de Agile e DevOps. A consultora optou por uma solução que transformou pessoas (sessões 
de formação sobre as práticas destas metodologias, coaching para várias linhas do negócio e 
fomentação da colaboração entre departamentos), processos (avaliação da maturidade do sistema, 
implementação de SCRUM e Kanban – culminando num framework DAD e gestão de releases 
utilizando práticas lean) e tecnologias (automatização de testes, integração contínua, entregas 
automatizadas, entre outras). A solução acabou por acelerar tempo entre ciclos de 12 para 3-4 
semanas, otimizou custos e aumentou a qualidade e segurança do serviço em 25% e poupou 2 milhões 
de dólares graças aos princípios de Agile e DevOps. 
 
Figura 3 – Valor relativo à adoção do DevOps 
(Fonte: Bossert, Ip & Starikova, 2015) 
 
8 
 
Para finalizar, realço também o caso “DevOps helps US-based technology major reduce operations cost 
by 20%” (n.d.), descrito pela Infosys, de uma empresa de tecnologia sediada nos Estados Unidos da 
América que possibilitou uma redução nos custos operativos em 20%. Com o objetivo de aumentar a 
frequência de releases e reduzir TTM, a empresa pretendia aumentar o valor do negócio e melhorar a 
experiência dos seus clientes sem afetar a qualidade e disponibilidade do sistema. Como solução, a 
Infosys desenhou um programa transformacional de DevOps que possibilitou a entrega mais rápida de 
novos atributos, juntamente com um aumento da eficiência e redução dos custos de operação. 
Simultaneamente provou-se o aumento da qualidade de serviço através da diminuição significativa de 
incidentes de prioridade 1 e 2, sendo os novos lucros aproveitados para financiar outros programas 
transformacionais internos. 
1.2. OBJETIVOS 
A organização geral do trabalho seguirá uma estrutura de desenvolvimento desde a introdução do 
conceito de DevOps até à sua comparação com outras metodologias semelhantes, passando pela 
análise dos impactos da sua implementação e utilização. A revisão da literatura dará início à 
investigação, sendo importante entender diversos conceitos teóricos, e suas aplicações, para que se 
torne mais fácil de alcançar os resultados inicialmente idealizados. 
O objetivo geral da dissertação é providenciar ao leitor um melhor entendimento das práticas 
arquiteturais e técnicas modernas e, acima de tudo, os padrões relativos à adoção da metodologia 
DevOps. Estas praticas, quando corretamente implementadas, levam a um conjunto de benefícios, que 
serão conjugados com uma análise de impactos da implementação da metodologia nas tecnologias de 
informação. Partindo deste objetivo procurar-se-á identificar necessidades, obstáculos e finalidades 
da aplicação do DevOps, obtendo, numa visão mais detalhada, um entendimento da importância deste 
conceito, percebendo todos os envolvimentos e contornos associados à correta e eficaz gestão 
operacional de sistemas de informação. Em adição a isto, serão apresentados casos de estudo que 
pavimentam o caminho desde a adoção destas práticas aos resultados operacionais positivos. 
Este estudo tem como finalidade atingir as seguintes metas: 
I. Apresentação e definição do conceito 
II. Análise dos benefícios da implementação da metodologia DevOps 
III. Exposição dos impactos e riscos do DevOps em Operações de TI 
9 
 
2. REVISÃO DA LITERATURA 
2.1. CONTEXTUALIZAÇÃO DO TEMA 
As metodologias de desenvolvimento, para além dos princípios em que se centram, consistem numa 
divisão da etapa de desenvolvimento em várias fases com o intuito de aumentar a produtividade, o 
planeamento e a gestão (Whitten, Lonnie & Kevin, 2003). A metodologia escolhida pode incluir uma 
definição prévia das entregas e dos impactos, que são criados e concluídos por uma equipa de projeto 
para desenvolver ou manter uma aplicação. As metodologias de desenvolvimento mais comuns 
incluem o modelo em cascata, prototipagem, desenvolvimento iterativo e incremental, espiral, Rapid 
Application Development (RAD) e vários tipos de metodologias ágeis (Agile). 
Para auxiliar ao paralelismo e comparações entre temas presentes ao longo do documento, será dado 
um especial ênfase a estas últimas metodologias, chamadas ágeis, que correspondem a um conjunto 
de princípios definidos no Manifesto Agile (2001) dentro dos quais os requisitos e soluções evoluem 
através da colaboração entre equipas autogeridas e organizadas. Os quatro fundamentais princípios 
deste manifesto compreendem indivíduos e interações sobre processos e ferramentas, software 
funcional sobre documentação, colaboração com clientes sobre negociação de contratos e repostas a 
mudança sobre planeamento. Promovem planeamento adaptativo, desenvolvimento evolutivo, 
entregas antecipadas e melhorias contínuas, encorajando uma resposta rápida e flexível a qualquer 
género de transformações e/ou alterações no processo produtivo (Shafer & Debois, 2008). A 
classificação agile deve-se ao facto de a metodologia não ter métodos específicos para concretizar os 
princípios enumerados anteriormente, contudo, vários outros processos surgiram como resultado da 
implementação destes princípios, como por exemplo, o Agile Unified Process (AUP), métodos Crystal 
Clear, eXtreme Programming (XP), Kanban ou SCRUM. 
As disrupções tecnológicas associadas aos segmentos de negócio colocam, constantemente, pressão 
sobre os tradicionais modelos empresariais. As quebras de negócio, entre as quais podemos realçar os 
modelos operativos variáveis, o foco inexorável em custos e mais-valias, sucessivas preocupações com 
segurança e conformidade com normas, novas relações entre empresas e a procura incessante por 
informação cada vez melhor e mais acessível, exigem que todas as tarefas sejam efetuadas com a 
máxima prontidão. Em termos tecnológicos, começam a surgir nos últimos anos novas evoluções 
tecnológicas, tais como os serviços cloud, analytics, In Memory, Internet of Things e plataformas de 
computação híbrida, que dão lugar a novas preocupações, nomeadamente com interfaces para os 
utilizadores, segurança e acessibilidade de dados, middleware e APIs, mas também a novas 
oportunidades que não eram possíveis encetar no passado. 
10 
 
Contudo, estas novas preocupações pressionam os sistemas de informação empresariais a executar 
com fidúcia e rapidez, e surgem também novos desafios, como o alto Total Cost of Ownership (TCO),rigidez (incapacidade de adaptação às necessidades crescentes do negócio), aumento da 
complexidade, extensão do período de retorno (ROI), taxas de execução mais lentas e a proliferação 
de “silos”, que se podem definir como sistemas de informação sem contacto com outros sistemas. 
Nitidamente, os modelos mais recentes de operações de TI não se adaptam aos ambientes velozes de 
negócio, e o DevOps aponta à resolução destes conflitos, juntamente com o aumento do Time to 
Market (TTM) e segurança dos sistemas empresariais. 
11 
 
2.2. CONTEXTO CRONOLÓGICO 
De forma a providenciar um contexto cronológico sobre a evolução do conceito, é apresentado em 
seguida uma timeline de eventos importantes que culminaram com a origem e implementação do 
DevOps no mundo tecnológico: 
Taiichi Ohno e Eiji Toyoda desenvolvem o Toyota Production System (TPS), o precursor do 
pensamento lean na Indústria; 
Publicação da obra “The Goal: A Process of Ongoing Improvement” por Eliyahu Goldratt, que 
introduz a “Teoria das Restrições”, focada na identificação e resolução de bottlenecks; 
Integração Contínua surge como prática em equipas, e como prática core na metodologia ágil 
Extreme Programming (XP). Reunião de 17 adotantes de metodologias de desenvolvimento 
“leves” que culmina no “Manifesto Agile”, em que a prioridade estabelecida é “(…) desde as 
primeiras etapas do projeto, satisfazer o cliente através da entrega rápida e contínua de software 
com valor.” (Beck, Beedle, van Bennekum, et al., 2001); 
Primeira conferencia DevOpsDays em Gent (Bélgica), organizada por Patrick Debois, onde se 
definiu o acrónimo DevOps para o conjunto de práticas que visavam o aumento da corelação entre 
equipas de desenvolvimento e operações; 
Primeiro livro sobre Entregas Contínuas e primeira edição da newsletter “DevOps Weekly”; 
Grandes fornecedores de software começam a utilizar extensivamente o termo e a desenvolver 
soluções com base nos seus princípios; 
Publicação da obra “The Phoenix Project” por Gene Kim (e outros) com uma nova visão e métodos 
de otimização de processos de negócio das organizações de TI inspirada nos princípios do DevOps; 
Começam a surgir relatórios de empresas como a Amazon e Etsy com resultados bastante 
positivos relativos à taxa de entrega, possibilitados pela adoção do DevOps no processo produtivo; 
II Conferência Empresarial de DevOps em San Francisco juntando os representantes de grandes 
organizações a nível global de áreas como governo, serviços financeiros, retalho, média, entre 
outros, enfatizando o estatuto do DevOps como conceito global e adaptável a qualquer indústria. 
 
1948-1975 
1984 
2009 
2001 
2010 
2011 
2013 
2014 
2015 
12 
 
2.3. INTRODUÇÃO AO DEVOPS 
Para competir num ambiente com mudanças tão aceleradas e repentinas, as organizações têm de 
adaptar novas metodologias de operações de Tecnologias de Informação. As novas propostas de 
estratégias resumem-se a aplicações líquidas, inteligentes ou conectadas. Para concorrer com 
agilidade e rapidez, as empresas modernas não conseguem financiar a construção e implementação 
de novos sistemas de informação massivos, sendo necessária uma nova maneira de construir e gerir 
as soluções de software – onde desponta uma nova policitação de subdivisão de aplicações conforme 
o seu âmbito e características. 
As aplicações líquidas são uma proposta de subdivisão do sistema em componentes me nores, que 
podem rapidamente ser construídos usando novos métodos de desenvolvimento, por forma a 
entregar software de forma contínua, suportando as necessidades dinâmicas do negócio (Daugherty, 
2016). Aplicações inteligentes resumem-se à utilização de inteligência de software nas aplicações e 
processos para responder aos aumentos de volume, velocidade e complexidade dos sistemas, dotando 
estas diligências com a capacidade de automatização, métodos analíticos e auto governança. Como 
consequências, não só assistimos a uma melhoria nas aplicações, como também na sua construção, 
ajudando a transformar complexidades em resultados de alta performance (Fox & Guestrin, 2015). Por 
fim, as aplicações conectadas surgem devido à necessidade das empresas defenderem a sua posição 
no mercado e assegurar rentabilidade, e como solução desenharam-se novos ecossistemas de 
conectividade para aplicações, não só em tablets e smartphones, mas também em pipelines de 
manufatura, equipamentos industriais e na indústria automóvel, tornando as empresas negócios sem 
fronteiras. Para estas aplicações, é necessário novas estratégias de ecossistemas através do 
planeamento da integração de tecnologias operacionais. 
Neste seguimento, surge o conceito de DevOps, que se pode definir como uma disciplina de engenharia 
que otimiza o Desenvolvimento e Operações, de maneira a capacitar a concretização dos objetivos do 
negócio através de rápido feedback, estabilidade e aumento da capacidade de resposta do serviço de 
TI, enquanto automatizam o processo de entrega de software e mudanças nas infraestruturas. 
Traduzindo para uma forma menos exaustiva, suponha-se que algum interveniente num determinado 
processo produtivo introduz uma inovação – é do cargo da camada operacional do processo produtivo 
empreender e implementar esta inovação o quanto antes, para que os resultados desta inovação 
possam ser demonstrados o mais rapidamente possível, sendo a rapidez no feedback uma das mais 
altas prioridades. O DevOps possibilita entregas contínuas, e, como tal, a definição e execução de 
estratégias associadas a aplicações líquidas (Croker & Rendell, 2009). 
 
13 
 
Este conceito é uma abordagem à entrega de software que visa juntar developers, operações de TI, 
controlo de qualidade e outros num grupo altamente colaborativo, possibilitando, logicamente, um 
aumento da colaboração entre diferentes segmentos do processo produtivo através da eliminação de 
entraves na comunicação, e, para além disto, assegurando a concretização dos objetivos e requisitos 
de negócio previamente estabelecidos graças a rápido feedback e uma infraestrutura estável, 
responsiva e flexível. Equipas de desenvolvimento são usualmente conduzidas pela procura incessante 
de soluções inovadoras e, assim sendo, têm tendência a ser proponentes naturais de mudança, 
enquanto as equipas de Operações são responsáveis pela estabilidade dos sistemas e vêem qualquer 
ameaça à estabilidade do sistema como um risco. O DevOps procura ultrapassar este paradoxo através 
da construção de uma relação de confiança e qualidade por todo o ciclo de desenvolvimento. 
Um dos seus grandes objetivos é o estabelecimento de uma cultura e ambiente onde a construção, 
teste e entrega de software possa acontecer de forma mais confiante, rápida e frequente, procurando 
mitigar os receios de mudança, deployments de risco, falta de confiança e unidades de trabalho 
desarticuladas. Os resultados podem rapidamente ser demonstrados aos stakeholders pois a rapidez 
no feedback é das suas maiores prioridades (Floris, Chintan & Maya, 2014; Samovskiy, 2010). 
Graficamente, podemos resumir o intuito do conceito da seguinte forma: 
 
 
 
 
 
 
 
 
 
 
 
14 
 
A interpretação usual associada ao DevOps é que as empresas têm os seus departamentos de TI 
divididos em dois silos: Desenvolvimento e Operações. Conforme podemos observar no esquema 
acima, ambos têm objetivos opostos e elevadas obrigações para com o outro. O DevOps procura 
combinar estes silos numa unidade colaborativa e empática, balanceando os seus objetivos e 
obrigações. 
Existem cinco práticas que resumem sucintamente a otimização da entrega de soluções de TI pelo 
DevOps: A automatização dos processos de entrega de software, referido anteriormente,que se centra 
na estandardização e aceleração na construção e deploy de processos, na gestão de recursos 
aplicacionais e gestão das configurações de software (SCM); integração contínua de sistemas, que 
conjuga conceitos avançados de SCM, testes unitários automatizados, análise frequente de código e, 
novamente, possibilitada pela automatização da construção e deploy de processos; pipelines de 
integração, que não é mais do que a orquestração e automação do processos do ciclo de 
desenvolvimento (ver fig. 4); Operações automatizadas, isto é, a possibilidade de recuperação 
imediata de dados e a monitorização e deteção de anomalias; Estruturação da infraestrutura e 
integração de novos serviços, como por exemplo Big Data e serviços Cloud, de maneira a gerar um 
ambiente estável, com escalonamento dinâmico e deteção e remediação de falhas. 
 
 
 
Figura 4 - Ciclo de Desenvolvimento de Software 
(Fonte: Autoria Própria) 
 
15 
 
Com as exigências impostas aos developers de software e com os serviços de Tecnologias de 
Informação constantemente pressionados pelo negócio (onde estão inseridos), clientes e 
stakeholders, existe a necessidade de desenvolver e entregar soluções como nunca antes. Encontrar a 
maneira mais produtiva de trabalhar e aumentar a qualidade do serviço torna-se essencial, e o DevOps 
assenta na consagração e industrialização destes termos. É também um conceito inerente às 
metodologias Agile, graças à sua habilidade de mover rápida e eficazmente o ciclo de desenvolvimento 
(fig. 4). 
O DevOps analisa rigorosamente cada fase do processo de desenvolvimento de software, por forma a 
definir processos mais rigorosos, ágeis e eficientes e, consequentemente, um produto final de 
qualidade. Porém, este conceito não é novo, o que mudou ao longo dos anos foram as expectativas 
dos clientes. A metodologia era aplicada recorrentemente no processo de desenvolvimento iterativo, 
querendo o cliente apenas uma solução eficaz e de baixo custo. Hoje em dia, os clientes pretendem o 
uso constante de ferramentas e conceitos agile para otimizar o processo acima referido, ambicionando 
uma perspetiva transparente sob que soluções são concebidas e como é que são 
desenhadas/idealizadas. 
Para atingir o seu propósito, é necessário orientar corretamente as prioridades (anteriormente 
referidas) do DevOps, sendo exigidos tipicamente os seguintes parâmetros: 
 Automatização de Software e Infraestrutura 
o A velocidade de execução de processos acelerou demasiado para se realizaram tarefas 
mundanas “manualmente”, reduzindo substancialmente o risco de falha destas 
tarefas. 
 Gestão Eficaz de Ambientes: 
o Os ambientes de desenvolvimento devem ser previsíveis, constantemente disponíveis 
e não intrusivos. 
 Gestão do Ciclo de Vida das Aplicações e de Configurações: 
o É necessário um planeamento correto e eficiente, assegurando a rastreabilidade das 
todas as aplicações envolvidas, de forma a garantir o pleno controlo de todas as 
funcionalidades. 
 
16 
 
 Ferramentas: 
o Certificar que, em todos as etapas, a correta tecnologia está a ser empregue, sendo 
imprescindível uma administração coerente de serviços inócuos (ex.: software 
irrelevante ou inútil para o processo produtivo). 
 Colaboração: 
o Garantir a comunicação e cooperação entre equipas, departamentos ou segmentos, 
evitando o isolamento de silos, pois o âmbito é demasiado abrangente. 
2.4. CONCEITOS ASSOCIADOS AO DEVOPS 
Atualmente, para competir num mundo empresarial de alto ritmo as empresas têm de ser flexíveis e 
de rápida adaptação. Software está no cerne de praticamente qualquer negócio, e a capacidade de 
emparelhar continuamente todas as exigências de determinada atividade e segmento empresarial 
está-se a tornar a diferença entre as empresas de sucesso e as que estagnam. Para ir ao encontro 
destes requisitos da melhor forma, surge o conceito de entregas contínuas, atingidas através de 
complacentes serviços de DevOps de índole estratégica, transformacional e administrativa. As 
entregas contínuas pavimentam também o processo de alterações culturais na empresa através de um 
novo modelo de governança, introduzindo automação nos processos produtivos. 
No seguimento da investigação sobre DevOps há três termos que frequentemente aparecem 
associados a esta metodologia: Entregas Contínuas (Continuous Delivery), Integração Contínua 
(Continuous Integration) e Implementação Contínua (Continuous Deployment). Estes três termos, 
apesar de aparentarem serem redundantes, têm definições diferentes, e muitas vezes confusas para 
o público, que serão explicadas em seguida. 
2.4.1. Integração Contínua (Continuous Integration) 
Na mesma linha de pensamento do que foi referido anteriormente sobre entregas contínuas, surge o 
termo de integração contínua, que se resume à prática de integração e testes de código desenvolvido 
continuamente, muitas vezes com o intuito de concretizar o processo de entrega contínua. O processo 
em si passa por fundir (merge) cópias trabalháveis várias vezes por dia para um repositório partilhado 
onde, mais tarde, poderá será revisto e aprovado por colegas dentro de uma determinada equipa 
(Duvall, Matyas & Glover, 2007). 
17 
 
 
O objetivo desta abordagem é evitar problemas de integração, ou seja, através de uma combinação 
de testes automatizados e, em alguns casos, desenvolvimento guiado por testes (TDD), é possibilitada 
a deteção rápida e prematura de problemas. Dado que a integração é feita com tanta frequência, existe 
menos back-tracking para descobrir onde é que algo falhou e é possível investir mais tempo na 
construção de novas características. 
Para o DevOps a integração contínua é vista como uma pedra basilar. Através do merge contínuo 
referido anteriormente impede-se a criação de demasiados projetos / soluções de desenvolvimento 
paralelos, evitando casos de conflito de código. Na prática, esta abordagem envolve um servidor 
centralizado que ininterruptamente importa alterações ao repositório central e, caso existam falhas 
na compilação, é esperado que a equipa se reorganize para as resolver, com uma perspetiva evolutiva 
do tema, ou seja, que sejam cada vez menores as ocorrências de falhas na compilação automatizada 
– que é um dos princípios do DevOps. Neste caso, a integração contínua oferece uma janela real-time 
sobre o estado atual do sistema e métricas de certificação de qualidade, permitindo também a 
envolvência constante de todos os elementos da equipa responsável, sem exceção das Operações. Em 
suma, a grande vantagem que o conceito traz é a criação de uma forma transparente em que todos os 
stakeholders podem monitorizar, agir e contribuir positivamente para a evolução de determinado 
projeto sem a disrupção associada a reuniões de status ou redrobramento de esforços (Fitzgerald & 
Stol, 2014). 
 
Controlo de 
Qualidade
• Integração no 
Sistema
• Testes de Interface
• Segurança
Servidor de 
Integração
• Compilamento
• Testes Unitários
• Análise de Código
Repositório 
de Controlo 
de Fontes
• Versionamento
Developer
• Alterações
• Novas 
funcionalidades
Notificações de Sucesso / Insucesso 
Figura 5 - Representação Esquemática do conceito Integração Contínua 
(Fonte: Autoria Própria) 
 
18 
 
2.4.2. Entregas Contínuas (Continuous Delivery) 
Avançando para o termo de entregas contínuas, é um conceito referente à produção de software em 
curtas iterações com recurso à automatização de processos, permitindo às equipas entregas mais 
frequentes que o normal. O ênfase recente em integração contínua, testes integrados, monitorização 
constante e feedback derivado de processos analíticos apontam para uma tendênciageneralizada na 
indústria de desenvolvimento de software: aumentar a capacidade de resposta. As consequências 
derivadas desta abordagem são a redução de custos, tempo e riscos associadas ao processo de 
entrega, possibilitando atualizações (updates) incrementais com vista à melhoria e otimização 
constante do produto (Chen, 2015). 
 
 
Tomando como exemplo um caso em que os testes aplicacionais são validados de forma constante ao 
longo do processo de desenvolvimento, e com certificação de qualidade, então torna-se possível 
entregar software em qualquer ponto do tempo. Entregas Contínuas não significam entregas literais, 
mas sim a filosofia e empenho em assegurar que o código / software desenvolvido está sempre 
release-ready, ou seja, pronto a entregar, estando sempre pendente uma autorização final de go-live 
manual, conforme indicado na figura 6. 
 
Figura 6 – Representação Esquemática do conceito Entregas Contínuas 
(Fonte: Autoria Própria) 
 
Entregas 
Contínuas
Desenvolvimento
Integração
Testes
Entrega
Monitorização
Release
19 
 
DevOps e Entregas Contínuas partilham o background de métodos agile e pensamento lean: pequenas 
e rápidas mudanças de maneira a trazer valor para os utilizadores finais, reduzindo falhas e o risco das 
operações (Floris, Chintan & Maya, 2014). A proposta de valor apresentada pelo conceito desdobra-se 
nos seguintes tópicos: 
 Time To Market: Concede uma redução do Time to Market até 50% através da entrega 
racionalizada de software 
 Taxa de Entrega e Qualidade: Aumentar produtividade da equipa e conceber novas 
funcionalidades mais rapidamente 
 Risco: Deteção e identificação antecipada de preocupações de qualidade e redução, até 30%, 
de defeitos durante o ciclo de desenvolvimento (ver Fig. 4). 
 Segurança: Fase operacional mais estável e segura e as mudanças são sistematicamente 
auditáveis. 
No entanto, não devemos confundir Entregas Contínuas com DevOps. DevOps possui um âmbito mais 
abrangente, e centra-se na mudança de paradigmas culturais, especificamente sobre colaboração 
entre equipas envolvidas na entrega de software (developers, ativos operacionais, gestores de 
qualidade, gestores administrativos, etc.) e como automatizar os processos de entregas e releases 
(termo utilizado como referência ao lançamento de uma nova versão de um produto de software) 
(Humble & Farley, 2010). Por outro lado, as entregas contínuas são uma abordagem à automatização 
anteriormente referida, com um foco particular na rápida execução e frequênci a das mesmas. Ambos 
têm objetivos finais comuns, e, por norma, são utilizados em conjunto para os atingir. Em suma, 
entregas contínuas não significa que cada alteração desenvolvida é imediatamente implementada, 
significa sim que cada alteração está sempre pronta a ser implementada. 
 
20 
 
2.4.3. Implementação Contínua (Continuous Deployment) 
O último conceito interligado ao DevOps é implementação contínua. Este termo é muitas vezes 
descrito como a progressão natural de entregas contínuas: todas as alterações que sejam validadas 
nos testes automatizados são automaticamente implementadas no sistema, sendo que muitos autores 
associam esta abordagem a empresas sem constrangimentos regulatórios ou relativos a requisitos dos 
utilizadores finais (Humble & Farley, 2010). 
Existem casos em que, dependendo da indústria, é expectável a existência de um período de espera 
antes de um go-live de uma nova alteração. Por exemplo, na indústria de telecomunicações, faz 
sentido que exista um período de alinhamento de todos os sistemas de informação existentes antes 
de uma determinada alteração no sistema, caso contrário poderemos testemunhar métricas mal 
geradas que podem culminar em prejuízo para o negócio. O objetivo passa também por perceber onde 
é que poderemos utilizar este método, ou até que ponto é que será vantajoso, pois o sucesso das 
implementações contínuas passa por uma analise de viabilidade rigorosa. 
Em seguida apresento uma representação esquemática do conceito para facilitar a compreensão do 
mesmo. Em suma, a grande diferença das entregas para a implementação contínua é a questão da 
automatização do processo de release, logo que estejam reunidas todas as condições – validação dos 
testes – resultando na formalização de várias alterações por dia, isto é, aumentando a frequência de 
releases. 
 
 
Figura 7 - Representação Esquemática do conceito Implementação Contínua 
(Fonte: Autoria Própria) 
 
Entregas 
Contínuas
Desenvolvimento
Integração
Testes
Entrega
Monitorização
Release
21 
 
2.4.4. Integração dos Conceitos 
Para finalizar esta sequência explicativa sobre o âmbito de cada um dos três conceitos referidos, é 
necessária uma comparação direta dos conceitos. Integração contínua, como vimos, é um termo direto 
que tem como objetivo facilitar o processo de releases. Mas Entregas Contínuas (Continuous Delivery) 
e Implementação Contínua (Continuous Deployment), apesar de partilharem o acrónimo C.D. (em 
inglês), têm diferenças significativas que se revelam críticas para o negócio. 
Resumindo o que foi descrito nos capítulos anteriores, Integração Contínua (Continuous Integration) 
reside na ação de fundir (merge) o código desenvolvido num repositório partilhado por uma 
determinada equipa tantas vezes quanto possíveis. As alterações são validadas através de um 
programa de testes automáticos e, ao fazê-lo, evitam-se futuros problemas de integração que podem 
advir de uma nova entrega de software. Esta abordagem coloca um grande ênfase em testes 
automatizados para garantir que, em qualquer momento, a aplicação/sistema está disponível (Duvall, 
Matyas & Glover, 2007). Entregas Contínuas (Continuous Delivery) acaba por ser uma extensão da 
Integração Contínua (Continuous Integration) com a garantia que se podem implementar novas 
alterações de forma sustentável, ou seja, para além da automatização de testes, existe também uma 
automatização do processo de release que a torna possível através de um processo manual. Em teoria, 
entregas contínuas permite decidir quando se enceta a entrega de software – diária, semanal, mensal 
– alinhada com os requisitos do negócio. Por fim, com recurso à Implementação Contínua (Continuous 
Deployment), todas as mudanças que passam pelo pipeline de alterações são automaticamente 
integradas nas versões live do sistema. Não existe intervenção humana, e só um teste falhado impede 
que as alterações sejam implementadas (Chen, 2015). Em suma, Implementação Contínua é 
considerada uma excelente forma de acelerar o ciclo de feedback dos clientes e de tirar pressão das 
equipas pois passam a não existir dias dedicados a releases, alterando o foco principal das equipas de 
desenvolvimento exclusivamente para conceber e implementar novas funcionalidades (Humble & 
Farley, 2010). 
Numa única frase, integração contínua é parte integrante da Implementação e Entregas Contínuas, e 
Entregas Contínuas é bastante similar a Implementação Contínua, com a variante de, na segunda, a 
componente de entrega de software ser automática. 
 
22 
 
Em baixo é apresentada uma tabela resumo dos custos e benefícios de cada prática referida 
anteriormente: 
Prática Custos Benefícios 
Integração 
Contínua 
(Continuous 
Integration) 
 Criação de testes automatizados para todas 
as novas funcionalidades 
 É necessário um servidor de integração que 
responsável pela monitorização e gestão do 
repositório e execução dos testes 
automatizados 
 A equipa de Desenvolvimento deve fundir 
(merge) novas alterações de software o mais 
frequentemente possível 
 Menos defeitos registados após o go-live dasalterações 
 Releases mais facilitadas, pois os problemas 
de integração já foram endereçados 
 Menos alterações de contexto no 
desenvolvimento 
 Redução dos custos de testes devido ao 
servidor de integração automatizada 
 Alteração do foco de controlo de qualidade 
para qualidade do serviço 
Entregas 
Contínuas 
(Continuous 
Delivery) 
 Necessários alicerces de integração contínua 
e abrangência quase total do servidor de 
integração 
 Entregas têm de ser automatizadas, apesar 
de o desencadeamento ser manual 
 As alterações têm de ser previamente 
acordadas com o cliente, pois existirão 
características incompletas durante todo o 
processo de entrega de software 
 Eliminação da complexidade na entrega de 
software 
 Eliminação de tempo alocado à preparação 
de releases 
 Aceleração do ciclo de feedback 
 Menos pressão sobre decisões mundanas 
(encoraja-se rápidas iterações) 
Implementação 
Contínua 
(Continuous 
Deployment) 
 Cultura de testes aperfeiçoada – a qualidade 
das releases irá depender da qualidade dos 
testes 
 A documentação tem de acompanhar as 
entregas de software 
 As alterações têm de estar perfeitamente 
alinhas com o cliente e coordenadas com os 
outros departamentos da organização 
 Os desenvolvimentos são acelerados pois 
não existem pausas para planeamento de 
releases 
 Pipelines de desenvolvimento são integrados 
automaticamente após cada alteração 
 Redução de riscos das releases e, em caso de 
problemas, mais facilmente corrigidas 
 Clientes observam melhorias incrementais, e 
a qualidade aumenta todos os dias (em vez de 
todos os trimestres, meses ou anos) 
 
Tabela 1 – Análise comparativa dos três conceitos associados ao DevOps 
(Fonte: Pittet, n.d.) 
23 
 
2.5. PARALELISMO COM AGILE 
Apesar de o Agile ser um termo vago, é certamente mais comum as pessoas ficarem confusas com o 
leque de definições associadas ao DevOps, sendo que a falta de definição do termo culmina, 
frequentemente, em interpretações erradas do tema. A confusão mais comum é confundir Agile com 
SCRUM e DevOps com entregas contínuas. Dado que tanto os princípios de DevOps como os de Agile 
englobam filosofias lean, como por exemplo colaboração e comunicação, os seus significados muitas 
vezes coincidem, sendo, no entanto, conceitos diferentes. Vários estudos comprovam uma forte 
correlação entre a satisfação do cliente e o desempenho do negócio, espelhado através das respostas 
imediatas e a entrega oportuna de soluções ao cliente, e de onde se conclui que as organizações que 
adotaram desenvolvimentos agile testemunharam um aumento no número de entregas e, com isto, 
nasceram os conceitos de entregas contínuas e DevOps (Liu, Y, Li, & Liu, W, 2014; Humble & Farley, 
2011). 
Um dos principais objetivos desta última metodologia é definir um ambiente onde possam ocorrer 
entregas de aplicações mais fiáveis e com menos falhas e, como já foi referido, assenta na comunicação 
entre os dois grupos operacionais de TI – Desenvolvimento e Operações (Samovskiy, 2010). Os 
utilizadores de DevOps começam a utilizar cada vez mais recursos, como por exemplo processos de 
automatização de entregas, que possibilitam a conclusão dos seus objetivos e métricas e a adoção de 
boas práticas de desenvolvimento, nomeadamente princípios agile (Collier, 2011; Httermann, 2012). 
A chave do DevOps é a entrega de soluções num tempo ótimo, assegurando mínimas disrupções e 
interrupções. 
 
24 
 
Estando os dois termos definidos, alinhemos as ideias relativamente ao âmbito dos dois conceitos: 
Âmbito Agile DevOps 
Metodologia vs. 
Entrega 
Desenvolvimento agile não passa de uma 
metodologia de desenvolvimento, uma vez 
que o software seja entregue, a equipa 
assignada descompromete-se do mesmo, 
avançando para o próximo sprint em mãos 
Assenta na entrega mais controlada 
possível e não depende em nada da 
metodologia de desenvolvimento 
(iterativa, incremental,…) associada 
Interdisciplinaridade 
vs. Silos 
Todos os membros de uma equipa são vistos 
como tendo capacidades de exercer qualquer 
função em ordem do progresso 
Assume que existem equipas de 
desenvolvimento e equipas de 
operações, e que estarão separadas em 
termos de funções 
Comunicação 
O SCRUM é o método mais comum de 
comunicação: reuniões diárias onde se revê a 
performance, progresso e planeamento de 
cada membro – sem documentação extensiva 
Envolve documentação relativa a design 
e especificação técnica para que toda a 
equipa e até end users do software 
percebam os impactos da release 
Dimensão da Equipa Tipicamente equipas pequenas 
Múltiplas equipas a trabalhar de formas 
diferentes 
Agendamento 
Planeamento feito para um futuro próximo 
(semanas ou meses) – promove rapidez na 
entrega 
Calendarização para minimizar 
disrupções no sistema – prioritiza 
disrupções mínimas 
 
Tabela 2 – Comparação entre DevOps e Agile 
(Fonte: Autoria Própria) 
 
Existe, no entanto, uma conexão histórica entre DevOps e Agile desde a Conferência Agile de 2008 
quando Patrick Debois (consultor de TI que introduziu o tema de colmatar as diferenças entre projetos 
e operações através do uso de técnicas Agile em desenvolvimento, gestão de projetos e administração 
de sistemas) e Andrew Clay Shafer (consultor de TI, cofundador da Puppet Labs, que dedicou a carreira 
a formar pessoas capazes de melhorar tecnologias e processos de forma a otimizar serviços de 
software através de práticas e ferramentas de DevOps) se conheceram num seminário sobre 
“Infraestruturas Agile” (Kim, Humble, et al., 2015). Desenvolvimentos agile podem ser implementados 
de diversas formas, incluindo SCRUM, Kanban, Extreme Programming, entre outros, e, por natureza, 
é uma mudança dos dogmas de desenvolvimento, e pode ser, muitas vezes, uma mudança tão 
profunda, que se estende a toda a organização, nomeadamente aos departamentos de marketing e 
recursos humanos. 
25 
 
Começando pelo SCRUM, podemos seguramente assumir que é um conhecido framework associado à 
gestão de desenvolvimento de software composto por sprints – ciclos de trabalho intensivo de uma a 
quatro semanas – que é frequentemente conjugado com curtas reuniões diárias de progresso 
(Schwaber & Beedle, 2002). Para a comunidade DevOps, o SCRUM é útil para monitorizar trabalho 
planeado e, para a componente de Operações, apenas uma percentagem do trabalho é planeada – 
releases com mudanças no sistema, alterações de fontes de dados, upgrades de sistema – contudo 
existe uma proporção elevada que não é planeada (ou até prevista), como por exemplo, análises de 
performance, falhas inesperadas do sistema ou até falhas de segurança. 
Estes eventos exigem resposta imediata, e apesar da utilidade do SCRUM para gestão de backlog, não 
existe tempo para planear ou prioritizar temas. Por esta razão, muitas equipas que abraçaram o 
DevOps passaram a olhar para além do SCRUM para, por exemplo, o Kanban, um método de 
visualização do fluxo de trabalho de forma a balancear as exigências de clientes com os recursos 
disponíveis, facilitando a identificação de bottlenecks (Anderson, 2010). Desta forma, as equipas 
conseguem controlar os dois tipos de trabalho, ajudando-os a entender e monitorizar as relações entre 
eles (nova release gera erro no sistema, por exemplo). Tal como todos os métodos agile, o SCRUM 
acaba por despoletar um mecanismo de otimização de processos, frequentemente apelidado de 
“retrospetiva”, portanto é sensato acreditar que algumas equipas de SCRUM vejam o DevOps como 
uma fonte de inspiração e utilizem a retrospetiva do SCRUM como oportunidadede se direcionar e 
ajustar para o DevOps. 
 
 
26 
 
3. METODOLOGIA 
Este capítulo irá introduzir o processo de investigação e sustentação do tema, concretamente os 
métodos utilizado para demonstrar os resultados positivos do DevOps enquanto metodologia de 
desenvolvimento ou o uso dos princípios associados ao mesmo, respondendo aos objetivos 
inicialmente definidos. Através da revisão da literatura, conseguimos inferir que esta secção será 
baseada numa investigação empírica dos riscos, processos de negócio e vantagens do DevOps, visto se 
tratar de um tema descritivo com pouca margem para questionários ou modelos preditivos. 
Relativamente às questões de investigação, foram delineadas as seguintes interrogações: 
1. O que é o DevOps? 
2. Que conceitos surgem associados ao DevOps? 
3. Quais as diferenças para a metodologia Agile? 
4. Quais os seus benefícios financeiros e operacionais? 
Através de um procedimento racional e sistemático, que tem como objetivo proporcionar uma 
resposta às temáticas definidas inicialmente, será encetado um processo que envolve a adequada 
formulação de um problema até à satisfatória apresentação dos resultados e, como tal, a análise e 
interpretação de casos de estudo relevantes é a metodologia mais adequada para este estudo e para 
atingir os objetivos deste projeto. 
Da análise feita anteriormente, e transferindo o ênfase para o capítulo de resultados, é claro que a 
jornada de implementação do DevOps encetada por cada empresa difere. Quando uma organização 
se apercebe da necessidade de fazer mudanças significativas nas suas práticas tecnológicas, o processo 
de planeamento pode revelar-se difícil e os envolvidos podem sentir que estão a trabalhar contra o 
que ajudaram a construir durante anos – esta mesma ideia gera ansiedade e rejeição, pois as pessoas 
reagem, naturalmente, de forma negativa à mudança. Mas tal como foi descrito nas secções anteriores 
deste documento, e agora materializado em resultados, a mudança não só é possível, como pode 
trazer resultados interessantes e inovadores para as organizações. Os próximos casos de estudo 
revelam como foram implementadas práticas tecnológicas modernas e oferecem uma história 
detalhada sobre a adoção interna dentro de cada uma destas organizações. 
 
27 
 
3.1. PROCESSO DE INVESTIGAÇÃO 
Robert Yin (2013), na sua obra Case Study Research: Design and Methods, defende que, apesar de a 
apresentação de casos de estudo não possibilitar a delineação do formato, intervenientes e audiência 
de certa investigação, cada investigador deve apresentar notas introdutórias antes de cada análise 
para providenciar contexto antes da exposição da temática. Para a investigação empírica de um tema 
descritivo, e sendo o DevOps uma temática pouco viral, não seria possível recolher estatísticas ou 
mesmo questionários sobre o seu uso, até porque a sua implementação é normalmente encetada por 
empresas que mantêm os seus dados e estatísticas (internas) confidenciais. 
Neste seguimento, o método científico mais adequado para a sustentação do tema é a análise de um 
caso de estudo em Portugal numa empresa onde o autor esteve empregado, diretamente ou 
indiretamente interligado com o DevOps, e o devido suporte do tema com outros três casos que 
ajudem a possibilitar um melhor entendimento de fenómenos e termos de comparação direta. A 
escolha desta abordagem reside na necessidade de querer interpretar um determinado fenómeno no 
seu ambiente natural, sendo os resultados deste estudo diretamente obtidos a partir da observação e 
análise de factos. 
Yin (2013) distingue ainda vários formatos relativos à apresentação de resultados, casos singulares ou 
múltiplos, estruturados ou não estruturados, organizados cronologicamente, entre outros – e para o 
tema em mãos o escolhido são múltiplos casos de estudo, com o intuito principal de expor um tema 
principal – caso de estudo aplicado em Portugal – e três casos que irão suster o tema e possibilitar um 
segmento final: uma análise comparativa entre estes criando uma junção de pareceres sobre DevOps 
e sobre a sua viabilidade, em termos estruturais e processuais. 
Para as três primeiras interrogações, a investigação efetuada enquadrou-se no segmento da revisão 
da literatura e relevância do tema, onde foi efetuada toda a investigação sobre as origens e contornos 
do tema, juntamente com um contexto cronológico sobre o DevOps. Para a última interrogação, foi 
efetuada a pesquisa apresentada, posteriormente, na discussão de resultados, que nos levou às 
conclusões que são apresentadas no final do documento. 
 
28 
 
Relativamente aos casos escolhidos, o principal caso de estudo foi considerado e indagado de forma a 
ter um ênfase especial no espaço geográfico onde estamos inseridos, Portugal, e, com base nesses 
resultados, tirar conclusões sobre o estado de utilização e benefícios da metodologia em Portugal. Este 
mesmo caso é apresentado nesta dissertação como sendo o foco principal da investigação, onde é 
apresentada uma arquitetura da solução de TI descrita ao longo da apresentação do mesmo, com o 
objetivo de revelar um estudo de caso concreto sobre os princípios do DevOps numa realidade que, 
tanto o leitor como o escritor, estão inseridos e entendem. 
Os restantes estudos escolhidos foram idealizados como tendo uma util idade explicativa sobre o 
panorama internacional do tema: o primeiro caso é relativo a uma grande consultora, a Capgemini, e 
aos resultados positivos inerentes da aplicação dos princípios do DevOps na sua cadeia de valor, onde 
se concebeu uma solução colaborativa de gestão de processos que aumentou a sua capacidade de 
sustentar mudanças de requisitos, assegurando, em paralelo, a consistência dos entregáveis (de 
qualquer tipo) e partilhando mais facilmente informação relevante entre os seus colaboradores; o 
segundo é referente à organização americana Yahoo!, concretamente sobre a Yahoo Answers, um site 
criado pela Yahoo! de perguntas e respostas. Através da centralização da equipa, uma reavaliação das 
necessidades dos clientes e o redesenho da arquitetura do sistema, a empresa foi capaz de reduzir 
uma série de tempos médios, aumentar a qualidade do serviço e assegurar a qualidade que os seus 
clientes procuravam; o terceiro caso prende-se com um cliente do segmento industrial, infelizmente 
não revelado pelos autores do estudo de caso, e como possibilitaram a aceleração na entrega de 
soluções – maioritariamente devido a um novo modelo agile com princípios de DevOps – em que 
refizeram a cadeia de valor do seu pipeline de entregas, acrescentando novos processos (como 
entregas contínuas) aliados aos já praticados pela empresa, como por exemplo a integração contínua, 
e como tal verificaram uma melhoria generalizada do serviço e das suas métricas de qualidade, 
produtividade, disponibilidade e entrega. 
Juntamente com uma análise detalhada de cada um deles, foi possível gerar um capítulo de análise 
comparativa onde se integra cada um deles com os princípios do DevOps e se registam, em jeito de 
conclusão, os benefícios verificados para cada caso e como foram possibilitados – desvendando a certo 
ponto o caminho para as conclusões da dissertação. 
 
 
 
 
 
29 
 
4. RESULTADOS E DISCUSSÃO 
4.1. INTRODUÇÃO 
No seguimento do exposto no capítulo anterior, inicia-se a apresentação dos resultados obtidos sob a 
forma de exposição e analise de diferentes casos de estudo sobre o tema da dissertação. Os casos 
expostos em seguida foram devidamente examinados para possibilitarem uma resposta à quarta 
interrogação da investigação: quais os benefícios financeiros e operacionais do DevOps. Foram 
selecionados estudos de caso relativos a diferentesentidades, uma nacional e três internacionais, de 
forma a possibilitar um melhor entendimento de fenómenos, sendo os estudos internacionais um 
suporte ao caso de estudo principal. Para além disso, estes casos irão auxiliar na exposição dos 
impactos positivos do DevOps e suas características, culminando numa análise comparativa entre 
estes, realçando, em forma de tabela, tudo o que foi exposto no corpo do capítulo de resultados. 
4.2. CASO DE ESTUDO: “SCOT” – MINISTÉRIO DA ADMINISTRAÇÃO INTERNA 
O Ministério da Administração Interna (doravante designado de MAI) – criado em 1736 e, entre 1910 
e 1974, designado por Ministério do Interior – pertence à área de Governo da Administração Interna 
e tem por missão formular, conduzir, executar e avaliar as políticas de segurança interna, do controlo 
de fronteiras, de proteção e socorro, de segurança rodoviária e de administração eleitoral (in 
www.portugal.gov.pt). Conforme referido no capítulo anterior, o MAI foi alvo de um projeto interno 
de reorganização da arquitetura do sistema de informação implementado e, através de investigação e 
observação empírica e entrevistas não estruturadas, foi possibilitada a análise de alguns documentos 
de projeto daqui em diante tratados como um único caso de estudo indiretamente ligado ao DevOps. 
4.2.1. Problema 
Outrora as autoridades portuguesas encaravam problemas sérios de ineficiência relativamente ao 
processo generalizado de registo e entrega de multas de trânsito – o processo não era automatizado 
ou estandardizado, e envolvia uma elevada percentagem de recursos em tarefas administrativas de 
back office, aliada a processos de gestão de informação limitados. Todos estes factos estavam a 
acarretar elevados custos internos e elevadas taxas de multas expiradas, culminando, eventualmente, 
na perca da oportunidade de reforçar o sector da segurança rodoviária e de assegurar por completo 
os lucros associados às multas registadas. 
 
30 
 
4.2.2. Solução 
Dentro deste contexto, uma reconhecida consultora colaborou com o MAI, em primeiro lugar, com a 
tarefa de redesenhar o processo de gestão de coimas (multas) e ainda, alinhado com as conclusões da 
primeira tarefa, desenvolver um sistema de informação integrado para o sustentar, criando o Sistema 
de Contraordenações de Trânsito (SCoT), com as seguintes diretrizes: 
 Estandardizar e automatizar o processo de tratamento de multas de trânsito tendo em conta 
os recursos existentes; 
 Utilização de dados de outras instituições estatais e organizações para extrair informações 
relevantes provenientes da integração dos sistemas; 
 Providenciar oportunamente toda a informação necessária à correta eficiência dos recursos; 
 Automatizar a produção de estatísticas e informações de gestão, otimizando a sua 
acessibilidade; 
 Minimizar a necessidade de desenvolvimento, manutenção e custos operacionais do sistema 
após o fim da sua implementação. 
 
 
 
 
 
 
 
 
O SCoT tem dois grandes componentes (Fig. 8): uma solução de mobilidade (extensível a aparelhos 
móveis como tablets e PDA’s) que possibilita a agentes o registo de multas de trânsito e aceder aos 
registos sobre o veículo e proprietário mais facilmente; e uma componente de Back Office, que suporta 
as tarefas administrativas relacionadas com o processamento de coimas (notificação de infratores, 
interrogatório de testemunhas, etc.), o registo de forma informatizada (existindo uma fase de 
estabilização onde se irá transitar do formato físico – papel – para o formato informático) e a 
introdução de estatísticas e informações de gestão automatizadas. A totalidade do sistema assenta em 
informação proveniente de outras bases de dados. 
Figura 8 – Interfaces Funcionais do SCoT 
(Fonte: Autoria Própria) 
 
Back-Office
Mobility
Back-Office
Mobility
Mobilidade 
31 
 
4.2.3. Arquitetura 
Relativamente à arquitetura do sistema, o mesmo foi construído com vista a seguir um modelo de 
Business Intelligence (B.I.) Microsoft suportado por uma base de dados SQL Server Express Edition, 
utilizando Eclipse e Microsoft Visual Studio como principais ferramentas de desenvolvimento. Em 
particular, o SCoT inclui uma série de relatórios de gestão de informação pré-definidos que promovem 
a análise de dados relacionados com multas de tráfego e a indicadores de eficácia do processo e, em 
paralelo, existe a funcionalidade de construir queries ad-hoc (locução latina que significa "para isso") 
e gerar novos relatórios. 
 
Infrações 
de Trânsito 
Cartas de 
Condução 
Cadastro 
de Veículos 
Cadastro de 
Proprietários 
de Veículos 
Dados de 
Inspeções 
Sistema 
Estratégico de 
Informação 
(PSP) 
Sistema 
Integrado de 
Informações 
Operacionais 
Policiais 
(GNR) 
Mobilidade (Online e Offline) 
• Pesquisas e Solicitações 
• Registo Direto de Multas 
• Ações Complementares 
• Fecho de Turnos 
• Pesquisas e Solicitações 
• Registo Indireto de Multas 
Tablet PC (Viaturas Policiais) PDA (Agentes Isolados) 
Back Office (Unidades Policiais) 
• Pesquisas e Solicitações 
• Multas e Ações Complementares de Registo 
• Controlo de Recursos (Turnos, Documentos,…) 
• Atualização da Informação de Infratores 
• Gestão de Documentos Apreendidos 
• Gestão de Pagamentos 
• Emissão Automática de Formulários 
• Estatísticas e Gestão de Informação (B.I.) 
Desktop PC 
Si
st
em
as
 O
p
er
ac
io
n
ai
s 
Sincronização de Dados 
Figura 9 – Arquitetura do SCoT 
(Fonte: Autoria Própria) 
 
32 
 
Na figura 9 é apresentada a arquitetura previamente descrita para possibilitar um melhor 
entendimento da organização geral do sistema. Para sustentar estas características, o SCoT incluí um 
data warehouse, um repositório central de dados estruturados e integrados de uma ou mais fontes 
distintas (Dedić & Stanier, 2016), implementado em SQL Server, que é refrescado diariamente via 
processos ETL (Extract, Transform and Load) implementados através de tecnologia Microsoft SQL 
Server Integration Services (SSIS). Estes processos alimentam um data warehouse com as informações 
de coimas recebidas das principais bases de dados operacionais. Os usuais problemas de performance 
são resolvidos com recurso a cubos OLAP (termo que se refere tipicamente a dados materializados 
sobre várias dimensões) construídos também em tecnologia Microsoft (SSAS) e, por fim, os relatórios 
desenvolvidos em Microsoft SQL Server Reporting Services. 
4.2.4. Benefícios 
Conforme podemos inferir do âmbito do caso de estudo descrito nos tópicos anteriores, o MAI 
testemunhou bastantes melhorias, transformando atividades passíveis de serem automatizadas em 
complexos processos tecnológicos internos. A relação com o DevOps centra-se na automatização das 
tarefas e da colaboração entre departamentos e, apesar de não existir o modelo tradicional de equipas 
de Desenvolvimento e Operações, as vantagens adquiridas vão de encontro aos resultados 
operacionais expectáveis da implementação do DevOps: aumento da qualidade e performance do 
sistema, redução do tempo alocado a manutenção do sistema, aumento da colaboração entre 
departamentos e acessibilidade do software / serviço através de várias plataformas. 
Tais benefícios acabam por resultar num aumento dos lucros operacionais (através da redução do 
tempo e recursos alocados a tarefas administrativas), satisfação do utilizador final do sistema e, por 
fim, um melhor apoio à tomada de decisão (por existirem agora estatísticas e relatórios com diversos 
indicadores de performance) – tudo possível pela implementação do SCoT, uma arquitetura de 
Business Intelligence e os princípios do DevOps. 
 
33 
 
4.3. OUTROS CASOS DE ESTUDO