devops em sistemas de informação - run.unl.pt · i devops em sistemas de informação francisco...
TRANSCRIPT
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
20
17
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 escolhido assenta 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 destas novas 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ência generalizada 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 das
alteraçõ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 oportunidade de 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 diferentes entidades, 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
MobilityMobilidade
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
Sist
emas
Op
erac
ion
ais
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
4.3.1. Capgemini
(in https://www.ibm.com/ibm/devops/us/en/casestudies/)
A Capgemini, conhecida consultora tecnológica e prestadora de serviços outsourcing, ajuda os seus
clientes a encontrar metodologias e software necessários para o desenho, desenvolvimento e
implementação de inovadoras soluções tecnológicas.
Para conseguirem acompanhar as necessidades crescentes e complexas dos seus clientes, a empresa
pretendia estabelecer um método de desenvolvimento agile que passaria pela criação de uma
plataforma que visava aumentar a colaboração, rastreabilidade e transparência por todos os ciclos de
desenvolvimento de um certo projeto (fig. 4) tornando-o mais previsível e passível de ser replicado em
outros moldes, pelo que teriam de adaptar os seus processos e tecnologias atuais a esta vicissitude
dos seus clientes. A solução incluía processos minuciosamente delineados que incorporavam as
diretrizes, templates, checklists e práticas preferenciais.
Para colmatar as características anteriormente referidas a Capgemini trabalhou em parceria com a
IBM Software Services para implementar um conjunto de ferramentas derivadas da suite “IBM
Software Services for Rational” que possibilitaram a criação de modelos, frameworks de
implementação eficientes, gestão de configurações, controlo de versionamento e estandardização de
templates para projetos de desenvolvimento agile. Para além disto, a suite incluía ainda software de
suporte a arquiteturas complexas de TI, gerindo a qualidade/riscos e aumentando a flexibilidade da
solução e do sistema.
A nova plataforma fornece capacidades que asseguraram os seguintes pontos:
Utilização de templates e normas pré-definidas de forma a acelerar os kickoffs (termo para
definição inicial e começo oficial de um projeto) e das práticas adequadas para melhorar
processos existentes como resultado da mensura constante de métricas e indicadores;
Redução da complexidade e mitigação de riscos através do provisionamento da infraestrutura
e plataforma;
Alinhamento da tecnologia utilizada para cada projeto com as necessidades e requisitos do
cliente, possibilitando a colaboração de equipas do cliente e empresa prestadora de serviços;
Aumento da produtividade e redução de custos através da gestão do ambiente do projeto,
permitindo, assim, que o foco seja direcionado aos entregáveis;
34
Melhorar transparência e previsibilidade por intermédio de estimativas estandardizadas,
monitorização e reporting contínuo.
Como resultado, a Capgemini ganhou uma solução colaborativa de gestão de processos que aumenta
a sua capacidade de sustentar as mudanças de requisitos constantes, assegurando a consistência dos
entregáveis (seja software, aplicações ou produto) e partilhando mais facilmente informação relevante
entre integrantes de equipas.
4.3.2. Yahoo Answers
(in https://itrevolution.com/devops-resource-case-studies/)
A Yahoo Answers foi criada em 2006 como um sítio de partilha de conhecimento na internet, com um
modelo de negócio bastante simples: os utilizadores competem para responder a perguntas de
visitantes, e as respostas às perguntas mais aprovadas pela comunidade favorecem os níveis dos
utilizadores. Em 2009 o seu crescimento estagnou em cerca de 140 milhões de visitas mensais.
Adicionalmente, a empresa estava a assistir ao declínio das taxas de compromisso dos utilizadores, à
estagnação dos lucros e a uma equipa de empregados contenciosos. A empresa utilizava
desenvolvimento em cascata (waterfall) em ciclos de quatro a seis semanas porque assistiam com
frequência a problemas no controlo de qualidade, que estava a obstruir o seu processo de releases, e
tinham um processo de entregas e integração contínua numa fase muito prematura.
Catorze (14) meses depois, a Yahoo Answers estava a ter 240 milhões de visitas mensais, mais de 20
milhões de utilizadores e o website globalmente disponível em 20 línguas diferentes – que
correspondia a grande parte do tráfego total do Yahoo. A empresa foi capaz de aumentar o seu tráfego
em 72%, triplicar o contacto do utilizador e transformar a equipa de empregados em gestores de
produto.
Esta transição deveu-se essencialmente a um planeamento rigoroso sobre quatro vetores: Engenharia,
Produto, Design e Operações, onde se determinou os seguintes objetivos:
Centralização da equipa em Londres
o A equipa estava tripartida por França, Londres e Estados Unidos da América;
o Verificavam frequentes falhas de comunicação pelas discrepâncias na zona horária e
localização;
o Existia escassa tecnologia que facilitasse a criação de equipas remotas;
Reavaliação das necessidades dos clientes
o Descartaram dashboards com métricas consideradas irrelevantes;
35
o Realizaram inquéritos de onde surgiram novas métricas:
Tempo até à primeira resposta
Tempo até à melhor resposta
Votos positivos por resposta
Perguntas por visitante / semana
Tempos de pesquisa
o Lucros não eram agora métricas, mas sim as visualizações;
Redesenho da arquitetura do sistema
o Em 2008, o site foi implementado sobre uma base de dados ORACLE RAC (versão
subdivida em clusters de uma B.D. ORACLE) e código legacy com 5 anos;
o Construção de um sistema MySQL paralelo com uma camada primária de acesso aos
dados, de forma a criar um espelho dos dados na B.D. física uma página de cada vez;
o Verificou-se uma transição de uma aplicação monolítica para uma arquitetura
orientada a serviços (SOA) sustentada por processos agile
Aliado a estes objetivos, a Yahoo subdividiu em pequenas unidades o trabalho – agora focado numa
métrica singular. Com o modelo em cascata, as Operações viam o agile como um sobre carregamento
do seu trabalho e estavam relutantes em aceitar, e para dificultar a situação, esta equipa estava aliada
a outra organização, significando isto que a Yahoo não teria poder sobre eles. A solução encontrada
foi transformar o processo em sprints semanais, entregas de software diárias, revisão diária de
métricas e um planeamento iterativo semanal. Este planeamento possibilitou uma revisão mensal do
negócio em que seriam reavaliadas as cinco métricas (em cima) previamente estabelecidas e os lucros
associados a estas.
Outro grande passo na transformação da Yahoo Answers foi a possibilidade de experimentação livre
sem receio das consequências, ou seja, eram encorajados os processos de tentativa-erro sendo sempre
assegurado um plano de recuperação de incidências. Em 2010 foram implementadas alterações no
sistema que possibilitou que os processos de rollback fossem mais rápidos e seguros, tendo sido
registados 90% das vezes rollbacks evolutivos, isto é, falhas repentinas no sistema que eram
prontamente corrigidas de forma evolutiva, e não revertidas como seria expectável. Tal facto deveu-
se à criação de vários ambientes para testes e numa nova política da empresa: a recompensação a
empregados que tomassem riscos, o que encorajou novas experiências no sistema da Yahoo Answers.
36
4.3.3. Cliente do Sector Industrial
(in https://itrevolution.com/devops-resource-case-studies/)
Para este caso de estudo não é providenciado o nome da empresa em que foram implementadas as
soluções tecnológicas, é sim descrita a organização como tendo cerca de oito mil empregados no
departamento de TI, suportando duas mil aplicações para vinte áreas de negócio diferentes. O modelo
de entrega de software era um modelo em cascata (waterfall), com metodologias de integração
contínua e uma abordagem de desenvolvimento test-driven (TDD) em áreas avançadas. Existia, no
entanto, uma elevada diversidade de opiniões sobre como o desenvolvimento era encetado pela
empresa, resultando em inconsistências e desafios na entrega. Como resultado, a direção avançou
com a implementação de um modelo agile durante um ano, considerado experimental, para
demonstrar que esta metodologia traria resultados positivos para a organização e, futuramente,
equacionarem a possibilidade de a escalar a nível empresarial.
O processo começou pelo estabelecimento de práticas de gestão agile, que foram aplicadas por todas
as tecnologias envolvidas: reuniões stand-up, gestão da interface do sistema, planeamento de
iterações e outras. Práticas de engenharia foram adaptadas conforme a tecnologia envolvida: controlo
de versionamento, integração contínua para Java e .Net, TDD e testes de aceitação automatizados. Foi
fomentada a aprendizagem e partilha de conhecimento entre colegas e os processos de melhoria
foram postos em marcha de forma a direcionar a sustentabilidade e escalonamento por toda a
empresa.
Após o ano experimental, a empresa atingiu resultados significativos em qualidade (redução em 80%
de defects críticos), produtividade (82% das equipas agile foram avaliadas e integradas no quarto mais
produtivo da empresa), disponibilidade (aumento de 70%) e entrega on-time (60% para 90%). Como
resultado disto a percentagem de trabalho desenvolvido pelas equipas agile aumentou para mais de
70% do total do departamento de TI (crescendo de três equipa agile para mais de duzentas) num
período de 5 anos.
O resultado da implementação agile foi que as tarefas eram agora movidas mais rápida e eficazmente
pelo ciclo de desenvolvimento, mas existiam períodos de espera no início e no fim dos ciclos, criando
uma espécie de modelo SCRUM em cascata. Esta espera devia-se à falta de backlog para as equipas
agile, e os períodos de espera transitavam para as camadas dependentes destas equipas. Quando o
trabalho passava a ultima iteração, existia uma elevada burocracia e práticas manuais, que levavam ao
aumento do tempo de entrega – aumento este que se devia a releases e práticas de entrega
descontroladas, tecnologias e dependências (releases grandes).
37
A este ponto, o foco passou a ser a redução da variação nos processos tal como receção de trabalho,
release, entrega e mudanças pelo pipeline, aplicando práticas lean para identificar áreas de melhoria,
com o intuito de reduzir os tempos end-to-end. Como resultado, criou-se um pipeline estrutural de
entregas contínuas integrado de forma a providenciar visibilidade e acelerar a capacidade de entrega.
Outras iniciativas para reduzir tempos de espera incluíam automatização de testes e infraestrutura,
incluindo a virtualização de serviços e gestão de dados de teste.
Por si só, a criação da estrutura de entregas contínuas com infraestrutura automatizada não iria
necessariamente reduzir os tempos de desenvolvimento e acelerar as entregas sem reduzir as
dependências, o que levou aos estados de espera que as equipas agile encontravam. Como tal, o
próximo passo era reduzir o âmbito das entregas e implementar práticas de arquiteturas web
modernas (APIs, microserviços), ou seja, foi colocado mais enfase na criação de infraestrutura como
código.
Para aumentar os tempos de entrega, era necessário medir o tempo total end-to-end. Tendo um
pipeline integrado, era agora possível a implementação de métricas para delinear tempos médios,
identificar bottlenecks ou atrasos e mensurar possíveis melhorias, o que também realçou onde
existiriam os tempos de espera dentro da cadeia de valor do ciclo.
Tal como a entrega acelera, torna-se também mais crítico adotar processos de feedback e
monitorização real time, para tanto a performance operacional como para o feedback do cliente, para
efetivamente determinar se as escolhas e novas práticas do negócio estão de facto a gerar mais valor
para os clientes.
38
4.4. ANÁLISE COMPARATIVA
Para encerrar o capítulo da exposição de resultados, passo a elaborar uma análise dos quatro casos de
estudo expostos anteriormente.
1. SCoT - Ministério da Administração Interna
O primeiro, e principal caso de estudo, era relativo ao desenvolvimento de uma solução de Business
Intelligence para o Ministério da Administração Interna, que culmina numa reorganização da
arquitetura do sistema de informação implementado. Apesar de estar indiretamente ligado ao tema
da dissertação, são claros os princípios de automatização e provisionamento automático com
utilização de frameworks (que representa a capacidade de um certo sistema de utilizar procedimentos
pré-definidos sem recurso a intervenção humana) inerentes ao DevOps. A solução por si só implica um
processo mecanizado com integração contínua dos dados e sincronização constante dos vários
ambientes, tanto para a mobilidade como para o back office. Os próprios benefícios, descritos no
último subcapítulo desse segmento, vão de encontro as que tipicamente se registam no DevOps, como
por exemplo a melhoria na acessibilidade do serviço nas diferentes plataformas e a redução do tempo
alocado a tarefas de manutenção, que daqui em diante será residual. Estes benefícios resultam ainda
em resultados financeiros positivos e na satisfação do utilizador final, que era o pretendido
inicialmente e que corrobora a hipótese definida sobre a utilidade do DevOps.
2. Capgemini
O caso da consultora Capgemini assenta no estabelecimento de uma metodologia agile através de
uma plataforma que facilitasse a colaboração, rastreabilidade e transparência por todos os ciclos de
desenvolvimento de um projeto e recorreram a ferramentas da IBM que possibilitaram a criação de
modelos, frameworks de implementação eficientes, gestão de configurações, controlo de
versionamento e estandardização de templates para projetos de desenvolvimento agile. Os resultados
obtidos inserem-se nos princípios colaborativos, automatizados e holísticos do DevOps, com especial
enfase no provisionamento do sistema, portais de configuração e a análise de impactos através da
monitorização das dependências e estandardização de métricas de performance. Como resultado, a
Capgemini ganhou uma solução colaborativa de gestão de processos que aumentou a sua capacidade
de sustentar as mudanças de requisitos constantes, possibilitou um aumento da produtividade e
redução de custos através da gestão do ambiente do projeto, permitindo, assim, que o foco seja
direcionado aos entregáveis e partilhando mais facilmente informação relevante entre integrantes de
equipas.
39
3. Yahoo Answers
Para a Yahoo Answers, pertencente à empresa Yahoo!, o problema era o declínio das taxas de
compromisso dos utilizadores, a estagnação dos lucros e uma equipa de empregados contenciosos, e,
como tal, era necessário uma restruturação da cadeia de valor do website de forma a aumentar as
visitas mensais e a assegurar o compromisso dos utilizadores – culminando em resultados financeiros
mais positivos. 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, atingindo
os princípios colaborativos e iterativos da metodologia. Pouco mais de um ano depois, a Yahoo
Answers estava a ter 240 milhões de visitas mensais, mais de 20 milhões de utilizadores e o website
globalmente disponível em 20 línguas diferentes – que correspondia a grande parte do tráfego total
do Yahoo. A empresa foi capaz de aumentar o seu tráfego em 72%, triplicar o contacto do utilizador e
transformar a equipa de empregados em gestores de produto.
4. Indústria
O último estudo de caso era relativo a uma organização industrial que tinha um modelo de entrega de
software em cascata (waterfall), com metodologias de integração contínua e uma abordagem de
desenvolvimento test-driven (TDD) em áreas avançadas. Existia, no entanto, uma elevada diversidade
de opiniões sobre como o desenvolvimento era encetado pela empresa, resultando em inconsistências
e desafios na entrega. Como resultado, a direção avançou com a implementação de um modelo agile
durante um ano, considerado experimental, para demonstrar que esta metodologia traria resultados
positivos para a organização e, futuramente, equacionarem a possibilidade de a escalar a nível
empresarial. Através de práticas agile (planeamento de iterações, reuniões stand-up, entre outras) e
de DevOps, como por exemplo, um controlo de versionamento, integração contínua e testes de
aceitação automatizados – aliada à construção de uma estrutura de entregas contínuas, foi possível
uma melhoria dos resultados da empresa sobre quatro vetores: qualidade (redução em 80% de defects
críticos), produtividade (82% das equipas agile foram avaliadas e integradas no quarto mais produtivo
da empresa), disponibilidade (aumento de 70%) e entrega on-time (60% para 90%).
40
Após o enquadramento dado anteriormente, observemos a integração de cada um dos casos de
estudo com tanto os princípios / práticas como com os benefícios do DevOps:
Organização Princípios / Práticas do DevOps Benefícios do DevOps
SCoT – MAI
Automatização e Provisionamento da Infraestrutura
Monitorização Contínua do Sistema
Rastreabilidade através de Métricas de Performance
Colaboração entre Departamentos
Otimização do Pipeline end-to-end
Ênfase no Utilizador Final
Aumento da Qualidade de Serviço
Aumento da Performance do Sistema
Redução dos Tempos de Manutenção
Melhoria da Acessibilidade do Sistema
Melhoria da Comunicação entre Departamentos
Aumento dos Lucros Operacionais
Aumento da Satisfação dos Utilizadores
Melhor Apoio à Tomada de Decisão
Capgemini
Colaboração entre Departamentos
Controlo de Versionamento
Automatização e Provisionamento da Infraestrutura
Monitorização Contínua do Sistema
Rastreabilidade através de Estimativas Estandardizadas
Mitigação de Riscos
Aumento da Performance do Sistema
Redução da Complexidade
Melhoria da Transparência do Sistema
Melhoria da Comunicação entre Equipas
Yahoo! Answers
Monitorização Contínua do Sistema
Automatização da Entrega de Soluções
Colaboração entre Departamentos
Releases mais frequentes
Ênfase no Utilizador Final
Aumento da Satisfação dos Utilizadores
Melhor Apoio à Tomada de Decisão
Redução do Número de Defects
Aumento dos Lucros Operacionais
Aumento da Qualidade de Serviço
Indústria
Entregas Contínuas
Releases Automatizadas
Controlo de Versionamento
Integração Contínua
Planeamento de Entregas
Testes de Aceitação Automatizados
Colaboração entre Departamentos
Provisionamento da Infraestrutura
Monitorização Contínua do sistema
Rastreabilidade através de Métricas de Performance
Aumento dos loops de feedback
Aumento da Qualidade do Serviço
Redução do Número de Defects
Aumento da Produtividade
Melhoria da Acessibilidade do Sistema
Redução do Tempo entre Entregas
Aceleração dos Ciclos de Desenvolvimento
Melhoria da Disponibilidade do Sistema
Aumento das entregas on-time
Redução significativa do backlog
Tabela 3 – Analise Comparativa dos Casos de Estudo
(Fonte: Autoria Própria)
41
5. CONCLUSÕES
Neste capítulo são apresentadas as conclusões da tese, onde as interrogações de pesquisa iniciais são
revistas e discutidas contra o investigado e exposto em capítulos anteriores, providenciando um
resumo das informações inferidas anteriores. Após a investigação sobre a relevância do tema em
análise e a clarificação dos objetivos do estudo, deu-se início a uma detalhada revisão da literatura,
uma pesquisa que envolveu a exposição do termo principal da dissertação e dos seus contornos,
juntamente com a elucidação de termos associados ao DevOps e um paralelismo com a metodologia
agile, utilizada frequentemente como termo de comparação. Para completar a realização do estudo,
procedeu-se à apresentação da metodologia de investigação e resultados obtidos. Resultados estes
que continham vários casos de estudo sobre o tema, onde foram analisados os contornos de diferentes
projetos/clientes onde foi implementada a metodologia DevOps ou os princípios inerentes à mesma,
atingidos com recurso a observação empírica, analise e recolha de factos e entrevistas não
estruturadas. Em suma, o propósito principal deste estudo foi uma apresentação e análise detalhada
sobre o DevOps, quais as suas vantagens e benefícios, verificados sobre diversos e díspares cenários,
considerados fulcrais para guiar esta pesquisa.
I. Apresentação e definição do conceito
Para atingir este objetivo, foi necessária uma extensa pesquisa através de diversas fontes, cruzando a
informação entre artigos de âmbito científico e académico como forma de chegar a uma definição
concisa e cientificamente legitimada. O DevOps pode, então, ser definido como uma disciplina de
engenharia que otimiza o Desenvolvimento (responsáveis pela componente evolutiva de um sistema
de informação) e Operações (responsáveis pelos ambientes e infraestrutura de um sistema de
informação) de tecnologias de informação, 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, possibilitando uma automatização do processo de entrega de software e mudanças nas
infraestruturas. O DevOps visa também juntar developers, operações de TI, controlo de qualidade e
outros num grupo altamente colaborativo, eliminando 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.
42
O DevOps possibilita a concretização de três pontos fulcrais para o sucesso de um projeto:
Entrega de software mais rápida
As novas funcionalidades requeridas por clientes são introduzidas em dias ou horas, em vez de meses,
e são entregues on-demand, independentes de outros ciclos, com feedback guiado através de métricas
para aumentar produtividade e fornecer a orientação necessária para continuamente afinar os
processos e serviços de negócio.
Entrega com menor risco
Os testes são executados em ambientes representativos, automaticamente validando o software
aquando da sua passagem entre estados. Através disto obtém-se uma eliminação dos riscos
regressivos ainda no início do ciclo de desenvolvimento (fig. 4), sendo também possível identificar e
processar vulnerabilidades de segurança nestas fases iniciais do processo.
Experimentar sem arrependimentos
As alterações são introduzidas em tempo real e simples de reverter. O roll-out de novas
funcionalidades é facilitado, usando frequentemente testes A/B (método de teste de desenho técnico
através do qual se comparam dois elementos com o objetivo de determinar qual tem melhor
performance) para identificar o impacto expectável de certo produto. Adicionalmente, as métricas de
performance são centradas no negócio, possibilitando uma gestão do serviço em real -time.
II. Análise dos benefícios da implementação da metodologia DevOps
Para o cumprimento deste objetivo, foi necessário o recurso a uma investigação específica sobre as
vantagens da metodologia, e os resultados obtidos desta pesquisa corroborados nos casos de estudo
apresentados anteriormente. Para a obtenção de uma plena vantagem competitiva, o DevOps garante
três tipos de vantagens: técnicas, culturais e de negócio. Começando pelas vantagens técnicas, verifica-
se, por norma, um aumento generalizado da qualidade e transparência do serviço, uma redução dos
tempos de manutenção e complexidade, uma melhoria da performance, acessibilidade e
disponibilidade do sistema e um forte ênfase na mitigação de riscos. Relativamente aos benefícios
culturais, o DevOps proporciona um melhor apoio à tomada de decisões, aumento da produtividade,
melhoria da comunicação entre equipas e/ou departamentos, uma aceleração dos ciclos de
desenvolvimento – culminando num aumento dos lucros operacionais – e um maior envolvimento dos
colaboradores nos objetivos globais da equipa.
43
Por fim, existem também proveitos em termos de negócio, tais como um aumento das entregas on-
time, aumento da satisfação dos utilizadores, redução do número de defeitos ( defects) e do tempo
entre entregas e uma redução significativa do backlog – aliado a um ambiente operativo mais estável.
III. Exposição dos impactos e riscos do DevOps em Operações de TI
O DevOps está longe de ser uma solução unanime para os profissionais de TI., e encontramos vários
artigos de opinião online com pontos contra esta metodologia. O que muitas vezes acontece é que não
é transmitido a diversidade de cenários e opções de implementação do conceito, dependendo do
cliente final da solução. A típica caracterização do DevOps considera dois silos, sendo dois a quantidade
ótima, apesar de em sistemas empresariais serem múltiplos, e muitas vezes de fornecedores de
serviços diferentes. Como limitação principal destaco as arquiteturas de sistemas e processos, que
seguem tipicamente os seguintes modelos:
Modelo Tradicional
O cenário típico é a coexistência das duas equipas, sem
contacto informal – são definidos dois departamentos com
os respetivos ativos, responsabilidades e âmbitos. Na
ilustração à direita, um sistema distribuído em diversos
sectores (base de dados, website, gestão de clientes,…)
onde as equipas não partilham conhecimento, e estão
plenamente repartidas – Desenvolvimento é responsável pelo
evolução do sistema e Operações pela sua manutenção.
Diversas equipas
Pela falta de definição de sistemas e processos,
podemos encontrar o caso em que todos os sectores do
sistema têm o seu departamento e realizam as suas
atividades diárias em pleno isolamento das restantes áreas.
No Ops
Um cenário atípico, muitas vezes descrito como uma ilusão, em que as funções
de ambas as equipas se misturam acabando por se criar um grande silo
totalmente centralizado, possibilitando a criação de sub-silos agrupados por
responsabilidades ou âmbitos de tarefas.
Equipa de Desenvolvimento
CMS Site IB
Tools PIM DB
Equipa de Operações
CMS Site IB
Tools PIM DB
Plataforma
ERP
Sis tema Legacy
Interface Utilizador
CRM
CMS
Operações Tradicionais
Operações
SaaS
Equipa de Operações e
Desenvolvimento
Plataforma
CMS Site IB Tools PIM DB
44
Equipas Orientadas ao Produto
Em grandes projetos existe uma tendência para se adotar toda a plataforma end-to-end e distribui-se
as aplicações que a compõe por equipas de projeto, usualmente regendo-se pelas normas dos
fornecedores de PaaS.
Posto isto, o que devemos reter é a ideia de que a cadeia de valor ideal, da ideia ao componente
alterado e entregue por release, deverá ultrapassar o mínimo de barreiras intra-equipa possível, e é
atingível pela organização end-to-end dos componentes, querendo isto denotar que nem sempre uma
boa aplicação (ex.: IaaS) significa uma má distribuição de silos. Para além das arquiteturas de sistemas,
temos de ter em conta o ponto de vista comportamental do planeamento de projetos. São diversos os
exemplos de processos complicados de change management, um conceito que se pode definir como
a abordagem à preparação e suporte a indivíduos, equipas ou organizações num processo de mudança
organizacional, processo este em que indivíduos muitas vezes resistem à mudança por preferirem a
estabilidade a que estão acostumados. Todo o processo de transição para um modelo adequado ao
DevOps implica uma partilha de conhecimento e certas responsabilidades, o que muitas vezes gera
confusão de tarefas e partilhas de acessos que comprometem a segurança e acessibilidade do sistema,
dificultando a monitorização do sistema e respetivos recursos envolvidos.
Outra das grandes limitações encontradas prende-se com o facto de existir uma elevada proporção de
incidentes aplicacionais fruto do resultado de erros humanos na entrega do software. Tipicamente a
entrega de software introduz uma percentagem significativa de defeitos e incidentes, aumentando,
em proporção direta, o risco relativamente ao volume da entrega em questão. Finalmente, e tal como
foi introduzido na representação esquemática do capítulo 2.3, o desenvolvimento e operações nas TI
têm diferentes valores e práticas de trabalho que frequentemente não se alinham, e face à
necessidade de cooperação, ambas as equipas desenvolvem uma adaptação rápida às características
e ambições do “silo” inverso.
O paradigma das empresas de TI é a alocação excessiva de tempo a testes, na implantação e na entrega
de software, ao invés do investimento no período de desenho técnico e desenvolvimento. A primeira
limitação que podemos inferir desta metodologia é a necessidade de automatização, estandardização
e/ou aceleração da fase de testes de certo produto, correspondente, a uma fase de mitigação de riscos.
A falta de comunicação afeta projetos tanto em termos cronológicos (calendarização) como
financeiros e, no caso de uma gestão não eficiente, o impacto será tremendo, podendo representar
um total falhanço de um determinado projeto.
45
Concluindo a dissertação, a pesquisa realizada providenciou um panorama geral do tema, DevOps em
Sistemas de Informação, sobre diversos vetores: vantagens, riscos, relevância financeira, entre outros.
Conforme foi percetível durante a explicação do conceito, a implementação do DevOps em operações
de TI pode revelar diversas fragilidades ao nível do negócio e nas operações diárias de equipas de
projeto, desafios estes que serão colmatados com as alterações e princípios inerentes ao DevOps –
representando um marco importante nas organizações na rotação processual e do negócio para
práticas tecnológicas modernas. Estas debilidades, embora inicialmente intimidantes, serão encaradas
com recurso aos termos apresentados durante a revisão da literatura e os resultados operacionais
comprovados à semelhança dos demonstrados nos resultados e discussão, presentes adicionalmente
na relevância do tema. Conforme exemplificado por esses casos de estudo, a adoção e aceleração das
práticas do DevOps podem ocorrer com sucesso sobre diversas indústrias e com desfechos diferentes.
Adicionalmente, o valor da implementação do DevOps pode ser significativo no que diz respeito à
produtividade e time to market, porém, a implementação do DevOps não reside simplesmente no
desenvolvimento de uma nova metodologia – deve ser tratada como uma alteração cultural ao nível
da empresa, que incorpore considerações sobre governança e processos existentes, tal como novos
processos tecnológicos.
Em relação a Portugal, não se conhece bibliografia sobre implementações de DevOps, sendo o forte
ênfase a implementação dos seus princípios, já intrínsecas a outras metodologias agile ou mesmo de
âmbito estratégico, como business intelligence. Da análise efetuada ao panorama nacional, o autor
não nega a sua existência, mas os clientes e seus resultados serão possivelmente documentação
interna de certas empresas e não do espectro público. Concluiu-se que as principais áreas de incidência
do DevOps são a entrega, integração, automatização e colaboração. Desdobrado pelos seus contornos
culturais, frameworks processuais e redefinição dos fluxos existentes com forte ênfase na
automatização e feedback, o DevOps possibilita uma abordagem inovadora para organizações a nível
tecnológico, porém não existe uma descrição geral de como o implementar, e os resultados podem
diferir bastante de organização para organização. É, também, bastante provável que existam
dificuldades na mudança cultural das empresas e seus colaboradores, contudo, no fim da linha, são
geralmente reconhecidas melhorias na colaboração entre indivíduos, equipas e sua afinidade
organizacional e, em termos de ferramentas, foram abordadas várias formas de implementar novos
processos, e sobre como estes conceitos irão possibilitar mudanças e adaptações pela empresa,
visando um aumento na qualidade do serviço e eficácia e produtividade dos seus empregados,
possibilitando indiretamente uma melhoria do seu bem-estar, que é a verdadeira vantagem da
tecnologia desde o momento da sua criação.
46
6. LIMITAÇÕES E RECOMENDAÇÕES PARA TRABALHOS FUTUROS
A investigação foi delineada para apresentar uma perspetiva genérica sobre o DevOps, tanto a nível
nacional como global, contudo a evolução tecnológica em Portugal é notoriamente inferior à global e,
por este mesmo facto, não é possível avaliar o panorama nacional da mesma forma que se avalia
outros casos a nível ecuménico. As empresas em Portugal, em termos gerais, focam-se bastante na
estabilização constante dos seus sistemas de informação empresariais, e a modernização é bastante
limitada em termos financeiros e temporais. A perspetiva cronológica aliada à modernização de
sistemas de informação (esforços que podem custar meses ou anos às empresas) limita as opiniões
sobre grandes transições e alterações tecnológicas.
A principal limitação é, então, a impossibilidade de realizar um paralelismo perfeito com instituições
portuguesas pela incapacidade na descoberta de artigos relevantes para auxiliar a sustentação da tese
geral da dissertação. Mesmo em termos gerais, a pesquisa não foi abrangente suficiente devido às
limitações temporais e à falta de informação nos principais motores de busca e artigos científicos
investigados – o padrão geral dos artigos eram informações descritivas sobre o DevOps, mas
geralmente não incluíam resultados financeiros, a sua utilidade ou formas de implementação. Sendo
um tema relativamente recente, e com um âmbito bastante específico, não foi possível uma pesquisa
devidamente completa, visto se tratar de um tema passível de estar a ser investigado ao corrente.
Em termos de recomendações, sendo o DevOps um tema relativamente recente, revela-se bastante
promissor para pesquisas futuras e construções de novos frameworks e arquiteturas de sistema com
recurso aos seus princípios, tanto de automatização e colaboração, como de controlo de
versionamento e provisionamento do sistema. Ainda não foram estabelecidos padrões na sua
implementação, pelo que seria prudente a realização de um estudo futuro sobre modelos ou
metodologias relativo à adoção do DevOps, juntamente com questionários a gestores de grandes
consultoras e médias empresas sobre as formas e ferramentas mais eficientes para possibilitar um
suporte a novas implementações desta metodologia, ou aliá-la aos processos atuais de uma
determinada organização, tendo em conta a maturidade do sistema.
Estudos futuros sobre o DevOps deverão ser uma extensão deste documento, que deverá servir como
base para investigações futuras sobre o tema, tal como um auxílio a processos de tomada de decisão
sobre a possibilidade de uma implementação do DevOps ou de novos processos de automatização,
conferindo, desta forma, uma utilidade estratégica à dissertação.
47
7. BIBLIOGRAFIA
Ambler, S. W. (2014). We need more Agile IT Now! The World of Software Development. San Francisco:
UBM Tech.
Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business.
Ashutosh A. (n.d.). The Definitive Question: Should Your Organization Adopt DevOps?
Retirado, no dia 14 de Maio de 2017, de
https://www.actifio.com/company/blog/post/definitive-question-organization-adopt-
devops/#sthash.wN3A0xvT.dpbs
Bass, L., Weber, I. & Zhu, L. (2015). DevOps: A Software Architect's Perspective. Addison-Wesley
Professional.
Beck K., Beedle M., van Bennekum A., et al. (2001). The Agile Manifesto
Bitterer, A. (2011). Hype Cycle for Business Intelligence. Gartner, Inc., Stamford, CT.
Bossert O., Ip C. & Starikova I. (2015). “Beyond agile: Reorganizing IT for faster software delivery”
Retirado, no dia 14 de Setembro de 2017, de https://www.mckinsey.com/business-
functions/digital-mckinsey/our-insights/beyond-agile-reorganizing-it-for-faster-software-
delivery
Braga, F. A. M. (2015). Um panorama sobre o uso de práticas DevOps nas indústrias de software.
Cawley, O., Wang, X., Richardson, I., et al. (2010). Lean/Agile Software Development Methodologies in
Regulated Environments – State of the Art. Lean Enterprise Software and Systems. Springer
Berlin Heidelberg. 65. 31–36.
Chaudhuri, S., Dayal, U. & Narasayya. (2011). An Overview of Business Intelligence Technology.
Communications of the ACM. 54(8). 88-98.
Chen, L. (2015). Continuous Delivery: Huge Benefits, but Challenges Too. IEEE Software. 32 (2): 50–54.
Chiang, R. H. L., Goes, P. & Stohr, E. A. (2012). Business Intelligence and Analytics Education and
Program Development: A Unique Opportunity for the Information Systems Discipline. ACM
Transactions on Management Information Systems. 3(3).
Collier, K. W. (2011). Agile Analytics: A Value-Driven Approach to Business Intelligence and Data
Warehousing. Pearson Education. 110 – 121.
48
Daugherty, P. (2016). Liquid Applications: A Fundamentally New Way to Build Software.
Davenport, T. H. (2006). Competing on Analytics. Harvard Business Review. 84(1). 98-107.
Debois, P. (2008). Agile Infrastructure And Operations: How Infra-Gile Are You? Agile 2008 Conference.
202-207.
Debois, P. (2011). DevOps: A Software Revolution in the Making. Journal of Information Technology
Management, 24(8), 3-39.
Dedić, N. & Stanier C. (2016). "An Evaluation of the Challenges of Multilingualism in Data Warehouse
Development" in 18th International Conference on Enterprise Information Systems - ICEIS 2016.
196.
“DevOps helps US-based technology major reduce operations cost by 20%”. (n.d.)
Retirado, no dia 22 de Maio de 2017, de https://www.infosys.com/agile-
devops/Pages/technology-conglomerate.aspx
Duvall, P. M., Matyas, S., & Glover, A. (2007). Continuous integration: Improving Software Quality and
Reducing Risk. Pearson Education.
Erich, F., Amrit, C. & Daneva, M. (2014). Report: DevOps Literature Review. University of Twente, Tech.
Rep.
Fitzgerald, B. & Stol, K. (2014). Continuous software engineering and beyond: trends and challenges.
Proceedings of the 1st International Workshop on Rapid Continuous Software Engineering.
Floris, E., Chintan, A. & Maya, D. (2014). A Mapping Study on Cooperation between Information System
Development and Operations.
Forsgren, N., Kim, G., Kersten, N. & Humble, J. (2015). 2015 State of DevOps Report. PuppetLabs. 37.
Fowler, M. (2006). Continuous Integration.
Fox, E. & Guestrin, C. (2015). The future of intelligent applications.
“Global bank improves service quality and saves US $2 million with Agile & DevOps”. (n.d.).
Retirado, no dia 30 de Maio de 2017, de https://www.infosys.com/agile-devops/Pages/global-
bank-service-quality.aspx
Han, J., Kamber, M., & Pei, J. (2011). Data Mining: Concepts and Techniques. San Francisco: Morgan
Kaufmann Publishers. 3.
49
Hevner, A., March, S. T., Park, J. & Ram, S. (2004). Design Science Research in Information Systems.
MIS Quarterly 28(1), 75-105.
Httermann, M. (2012). DevOps for Developers. Apress.
Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test,
and Deployment Automation. Pearson Education.
Kim, G., Humble, J., Debois P. & Willis J. (2015). The DevOps Handbook: How to Create World-Class
Agility, Reliability, and Security in Technology Organizations
Lehman, M. M. & Belady, L. A. (1985). Program Evolution: Processes of Software Change. London
Academic Press Inc.
Loukides, Mike. (2012). What is DevOps?
Liu, Y., Li, C., & Liu, W. (2014). Integrated Solution For Timely Delivery of Customer Change Requests:
A Case Study Of Using DevOps Approach. International Journal of U-and E-Service Science and
Technology, 7(2), 41-50.
March, S. T. & Storey, V. C. (2008). Design Science in the Information Systems Discipline. MIS Quarterly.
32(4). 725-730.
Mathaisel, B. (2013). A CIO's Devops Approach to Resolving the Agility-Stability Paradox
Retirado, no dia 3 de Março de 2017, de http://usblogs.pwc.com/emerging-technology/a-cios-
devops-approach-to-resolving-the-agility-stability-paradox/
Moore, G. (2011). Systems of Engagement and The Future of Enterprise IT A Sea Change in Enterprise
IT. Aiim. 14.
Patterson, D. A. (2008). Technical Perspective: The Data Center is the Computer. Communications of
the ACM, 51(1). 97-110.
Pittet, S. (n.d.). Continuous Integration vs. Continuous Delivery vs. Continuous Deployment
Retirado, no dia 5 de Setembro de 2017, de https://www.atlassian.com/continuous-delivery/ci-
vs-ci-vs-cd
Rogers, E. (2003). Diffusion of Innovations. Simon and Schuster, 5, 11.
Russom, P. (2011). Big Data Analytics. TDWI Best Practices Report (Fourth Quarter).
Samovskiy, D. (2010). The Rise of DevOps. Fubaredness Is Contagious.
50
Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum (Vol. 1). Upper Saddle
River: Prentice Hall.
Sicular, S. (2013). Magic Realism of Big Data.
Retirado, no dia 7 de Abril de 2017, de https://blogs.gartner.com/svetlana-sicular/magic-
realism-of-big-data/
Sobejana, M. & Wilson, N. (2016). ”Hype Cycle for Application Development, 2016”
Retirado, no dia 8 de Julho de 2017, de https://www.gartner.com/doc/3371917/hype-cycle-
application-development
Turban, E., Sharda, R., Aronson, J. E. & King, D. (2008). Business Intelligence: A Managerial Approach.
Boston: Pearson Prentice Hall.
Watson, H. J., & Wixom, B. H. (2007). The Current State of Business Intelligence. IEEE Computer. 40(9).
96-99.
Whitten, J. L., Lonnie D. B. & Kevin C. D. (2003). Systems Analysis and Design Methods. 6.
Womack, J. P. & Jones, D. T. (2010). Lean Thinking: Banish Waste and Create Wealth in Your
Corporation. Simon and Schuster.
Yin, R. K. (2013). Case study research: Design and methods. Sage publications.
Zhu, L., Bass, L., & Champlin-Scharff, G. (2016). DevOps and Its Practices. 33(3), 32-34.