MetodologiadeDesenvolvimentodeSoftwareDevOps

MateusSaquettiPereiradeCarvalhoTirone1,EveraldodeAvilaGomesJunior1
CentrodeCinciasComputacionaisUniversidadeFederaldoRioGrande(FURG)
CaixaPostal47496201900RioGrandeRSBrazil

{mateussaquetti,everaldo.junior}@furg.br

Abstract.Thismetapaperdescribesthestyletobeusedinarticlesandshort
papersforSBCconferences.ForpapersinEnglish,youshouldaddjustan
abstractandfor thepapers inPortuguese,wealsoaskfor anabstractin
Portuguese(resumo).Inbothcases,abstractsshouldnothavemorethan
10linesandmustbeinthefirstpageofthepaper.
Resumo. Este metaartigo descreve o estilo a ser usado na confeco de
artigos e resumos de artigos para publicao nos anais das conferncias
organizadaspelaSBC.solicitadaaescritaderesumoeabstractapenas
paraos artigos escritos em portugus.Artigos em ingls,deveropossuir
apenas abstract. Nos dois casos, o autor deve tomar cuidado para que o
resumo (e o abstract) no ultrapassem 10 linhas cada, sendo que ambos
devemestarnaprimeirapginadoartigo.

1.Introduo
AtualmenteasorganizaesdeT.I.estoenfrentandoumsriodesafio,porumlado
mercados cada vez mais competitivos, com mudanas quase que rotineiras nos
softwaresexecutandonumavariedadeimensadedispositivosesistemasoperacionais;
poroutrolado,ossistemasestocadavezmaiscomplexos,integradosaoutrosservios
eexigindoumaltograudeconfiabilidadeedisponibilidadedosmesmos[1].
Ao longo de muitos anos a indstria desenvolveu software definindo um
conjuntoespecificodeaes,atividades,tarefasemecanismosdegarantiadequalidade,
reunidosemfasesdeformasequencialelinear.Essesmodelosdedesenvolvimentode
softwaremuitasvezeschamadosdetradicionaissogeralmentebaseadosementregade
funcionalidades onde so especificados, desenvolvidos e testados em estgios
sequenciaiselineares[2].Nessemodelo,geralmente,aequipededesenvolvimento
responsvel por entregar as funcionalidades sendo formada exclusivamente por
desenvolvedores.Enquantoaequipedequalidade,formadatambmportestadores,a
que verifica e valida atravs da deteco e correo de bugs as funcionalidades
entregues.Porfimaequipedeoperao,constitudaporadministradoresderedes,de
sistemas,debancodedados,dentreoutros,serestringeaprepararosistemaparaa
produo. Logo, podesedizer quenessa abordagem a equipe de operao trabalho
isoladadasdemaisequipes,oqueacarretaumagrandedemandadetempoporparte
dessaparaconfigurarsistemasoperacionais,ambientes,infraestruturaderedesepor
vezesummiddlewareparaaintegraocomaaplicaodesenvolvida[3].
Hojeomodelotradicionaljnocapazdeatenderaosrequisitosdaindstria
de desenvolvimento de software devido necessidade crescente de otimizao do
processo de entrega e suporte que visa proporcionar o produto pronto e totalmente
funcionalemprazoscadavezmenores.Adifusoevidentedodesenvolvimentogilde
software, que teve o intuito de sanar essa necessidade, possibilitou o surgimento e
propagaoposteriordaculturadoDevOpsqueporsuavezpropem,atravsdaestreita
colaboraoeharmoniadotrabalhodosdesenvolvedoreseoperadoresdesistemasdeTI
emproldeumobjetivocomum,reduzirotempoeoesforonecessriosparaconstruir
softwaredequalidadeedeformaconsistente.

2.AbordagemTradicional
Metodologias de desenvolvimento de software evoluram, porm o processo de
transformarideiasemcdigoaindaenvolvediversasatividadescomo:levantamentode
requisitos, design, arquitetura, implementao e teste. Os Mtodos geis de
desenvolvimentodesoftwaresurgiramnofinaldadcadade90propondoumanova
abordagemparaorganizartaisatividades.Aoinvsderealizlasemfasesdistintas
modeloconhecidocomoprocessoemcascataelasacontecememparalelootempo
todo,emiteraescurtas.Aofinaldecadaiterao,osoftwaresetornamaisemaistil,
comnovasfuncionalidadesemenosbugs,eotimedecidejuntocomoclientequala
prximafatiaaserdesenvolvida[4].
Quandooclientedecidequeosoftwareestprontoparairaoareocdigo
colocado em produo, os usurios comeam a usar o sistema. Ento, outras
preocupaes se tornam relevantes como: suporte, monitoramento, segurana,
disponibilidade,desempenho,usabilidade,dentreoutras.Quandoosoftwareestem
produo,aprioridademantlorodandodeformaestvel.Emcasosdefalha,otime
precisaestarpreparadoparareagireresolveroproblemarapidamente.
Decertaformaparecehaversentidoemsepararaequipedodesenvolvimentoea
deoperaes.Enquantootimededesenvolvimentotrabalhaemiteraes,otimede
operaes precisa reagir instantaneamente quando algo d errado. Alm disso, as
ferramentaseoconhecimentonecessrioparatrabalharnessasequipessodiferentes.O
timededesenvolvimentoevoluiosistemaintroduzindomudanas.Poroutrolado,o
timedeoperaesevitamudanas,poiselastrazemumcertoriscoestabilidadedo
sistema.Criaseentoumconflitodeinteresseentreessasduasequipes[4].
Nos modelos tradicionais esse conflito gera uma barreira cultural e
organizacional,quesegundo[2],ocasiona:

Timesseparados:fazsecomquecadatimedefendaseusinteressesindividuais;
Ausncia de uma padronizao nos artefatos de software (documentao,
modelos,cdigofonteetc.):Timesespecializados,trabalhandoseparadamente,
desenvolvemidiomaprpriotrabalhandoemseusproblemasindividualmente,
aoinvsdedesenvolveremumidiomacomumtrabalhandoemproldeumnico
objetivo.
Temor:Equipesnocompartilhamconhecimentocomreceiodeperderpodere
desuasatividadesseremconfrontadas.

J nos modelos de processo de desenvolvimento que se baseiam em

metodologiasgeisondeaequipedetestadoreseequipedequalidadefazempartedo
timededesenvolvimento,junto comos desenvolvedores semfunes prdefinidas,
portanto, compartilhando o mesmo objetivo de desenvolver software de maneira
eficientedeacordocomasconstantesmudanasnosrequisitosdesoftware,oproblema
outro.
Nessaabordagemdetemposemtempos,aequipededesenvolvimentoempacota
o software que precisa ir para produo, escreve documentao explicando como
configurar o sistema, como realizar a instalao em produo e repassa a
responsabilidadeparaotimedeoperaes,fazechamadade handoff.Essafazeacaba

criando um gargalo no processo de levar cdigo do desenvolvimento e teste para

produo.comumchamaresseprocessodedeployemambientedeproduo,oque
emportugusseriacomoimplantar.Comopassardotempo,oprocessotendease
tornarmaisemaisburocrtico,fazendocomqueafrequnciadedeploysdiminua.Com
isso,onmerodemudanasintroduzidasemcadadeploytendeaacumular,aumentando
tambmoriscodecadadeployecriandoocicloviciosomostradonafigura1[4].

Figura 1. Ciclo vicioso entre desenvolvimento e operaes.

Esse ciclo vicioso no s diminui a habilidade da empresa de responder

rapidamente a mudanas no negcio, como tambm impacta etapas anteriores do
processode desenvolvimento. A separao entre os times dedesenvolvimento ede
operaes, o handoff de cdigo existente entre eles e a cerimnia envolvida no
processodedeployacabamcriandooproblemaconhecidocomoaltimaMilha[5].
A ltima milha se refere fase final do processo de desenvolvimento que
acontece aps o software atender todos os requisitos funcionais mas antes de ser
implantadoemproduo.Elaenvolvevriasatividadesparaverificarseoquevaiser
entregue estvel ou no, como: testes de integrao, testes de sistema, testes de
desempenho, testes de segurana, homologao com usurios,testes de usabilidade,
ensaiosdedeploy,migraodedadosetc.Issogeraconflitosdentrodaprpriaequipe
queprejudicaobomandamentodoprojeto.

3.BreveHistrico
Em 2008, Patrick Debois publicou um artigo intitulado Agile and Operations
Infrastrucuture:HowInfragileAreYou?[6],ondedemonstroucomoainfraestrutura
poderiaresponderdeformagilsmudanasdonegciodeformasimilarmentecomo
as metodologias geis de desenvolvimento respondiam constante adaptao do
negcioaomercado.Aindaem2008,emumaconfernciasobreprticasgeis,Deboise
AndrewShaferapresentaramotrabalhoAgileInfrastructure,eaomesmotempo,uma
listachamadaagilesysadminfoicriadanaEuropaparadiscutirsobremetodologiageis
nainfraestrutura,ouseja,comoaequipedeoperaespoderiatrabalhardeformagil
acompanhando assim a equipe de desenvolvimento. A partir da uma srie de
iniciativas,estudoseconfernciasarespeitodoassuntocomearamaaparecerese
tornarempopulares.

O termo DevOps teve origem em 2009 durante a conferncia Velocity da

OReilly,foiapresentandootrabalho10+DeploysPerDay:DevandOpsCooperation
atFlickrporJohnAllspawePaulHammond[7],quetevecomonfasedemonstrarum
estudodecasosobreacapacidadedeimplantaonumaempresadepoisqueamesma
colocou emprtica acolaboraoentreos desenvolvedores eaequipe deoperao
priorizando entregar software de qualidade respondendo assim com eficincia
dinmicadomercado.Essaapresentaofoiumdivisordeguasparaimpulsionaro
crescimento do movimento. Nesse mesmo evento surgiu a ideia de criar os
DevOpsDays,eventorealizadoemdiversospasescominiciativaslocaiscomobjetivo
dedisseminaraculturaDevOps.

4.DefiniodeDevOps
O termo DevOps amplamente utilizado nos dias de hoje e ainda no prescritivo,
muitos tipos diferentes de contedo esto associados a ele, envolvendo inmeras
atividadeseaspectos.
Segundo[2],DevOps uma mistura dedesenvolvimento (querepresentaos
desenvolvedoresdesoftware,incluindoprogramadores,testadoresepessoaldegarantia
dequalidade)e operaes (representandoos especialistas quecolocamsoftwareem
produo e gerenciam a infraestrutura de produo, incluindo administradores de
sistemas,administradoresdebancodedados,eostcnicosderede).DevOpsdescreve
prticasquesimplificamoprocessodeentregadesoftware,enfatizandooaprendizado
porstreamingfeedbackdeproduoparaodesenvolvimentoeamelhoriadotempodo
ciclo(isto,otempodesdeoincioataentrega).DevOpsnoscapacitaaentregar
softwaremaisrapidamente,mastambmajudaaproduzirmaiorqualidadedesoftware,
deixandoo mais alinhado com as necessidades individuais e as condies bsicas.
DevOpsenglobavriasactividadeseaspectos,como:

Cultura:Pessoascommaisprocessoseferramentas.Softwarefeitaporepara
pessoas.
Automao: Automao essencial para DevOps para ganhar rpida
comentrios.
Medio:DevOpsencontraumcaminhoespecficoparamedio.Qualidadee
compartilhou(oupelomenosalinhados)osincentivossocrticos.
Compartilhamento: Cria uma cultura onde as pessoas compartilham idias,
processoseferramentas.

Jsegundo[8],DevOpsumconjuntodeprticasdestinadasareduzirotempo
entrecometerumaalteraoemumsistemaeamudanasercolocadaemproduo
normal,assegurandoaomesmotempoaaltaqualidade,oquesignificaaptidopara
utilizaoporvriaspartesinteressadas,incluindousuriosfinais,desenvolvedoresou
administradores de sistema incluindo tambm disponibilidade, segurana e
confiabilidade.
Apesardetcnicas,processoseferramentasseremessenciais,DevOps,nasua
essncia, um movimento cultural, da colaborao e do compartilhamento de
conhecimentosentreasequipes.Umaorganizaopodepossuirprocessoseferramentas
automatizadasmaiseficientespossvel,pormissosetornaintilseaspessoasnoas

usaremdemaneiracorreta.ConstruirumaculturaDevOpsentoumpassoprincipal
paraadoodeDevOpsfocadosnoobjetivodaorganizaoaoinvsdosobjetivosde
equipesseparadas[9].

5.Funcionamentobsico
DevOpstemcomofocoprincipalacomunicaoecolaboraoentreasequipesde
desenvolvimentoeoperaoajudandoessasequipesatrabalharemjuntasedeforma
mais efetiva. Veremos a seguir qual o funcionamento bsico de uma equipe que
trabalhautilizandoessemtodo.
Ostimeseasorganizaesadotamumavariedadedeprincpiosdeacordocom
seutamanhoounaturezaoumetodologiasutilizadas,porm,algunsdessesprincpios,
so comuns entre elas, tais como o Desenvolvimento e Testes em ambientes
semelhantes ao da produo, processo de implantao repetvel e confivel,
monitoramentoevalidaodaqualidadeoperacionaleoaumentodosfeedbacksdos
consumidores/clientes[8].ConformevistonaFigura2otimedeoperaoemDevOps
trabalha desde a concepo do projeto e nos primeiros ciclos de desenvolvimento
fornecendoparaaequipededesenvolvimentoetestesumambientesimilaraoambiente
deproduoparaqueaaplicaosejadesenvolvidaetestadaantesdeestarprontapara
aimplantao.

Figura 2. Equipe de Operao em ciclos iniciais de desenvolvimento

Este ambiente similar evita vrios problemas a equipe de operao e

desenvolvimento afinando a comunicao entre as equipes, verificando o
comportamentodaaplicaoefacilitandoassimoprocessoparaaentregacontnuade
software. O Processo de implantao repetvel e confivel fundamental para se
implantarDevOpseissosedatravsdaautomaocriandoassimumpipelinede
entregaconfivel.Opipelinedeentregaconsisteemumconjuntodeestgiosqueuma
aplicaopassadesdeodesenvolvimentoataproduo.Opipelinedeimplantao,
assimcomotodooprocesso,precisasermonitoradoemtodoseuciclodevidaatravs
deautomaoecomvisibilidadeatodososmembrosdaequipe.Todoesseprocesso
fornece uma base para ampliar o feedback dos clientes e consumidores fornecendo
assimrespostasmaisrpidasatravsdeumcanaldecomunicaoeficiente[10].Cada

organizaopodeimplementarseupipelinedeacordocomsuasnecessidadeseseus
ambientes, mas a Figura 3 representa um pipeline tpico de DevOps para fornecer
agilidadeentregacontnuadesoftware.

Figura3.PipelinedeentregaDevOps[10]
Em um pipeline tpico o estgio de desenvolvimento muito parecido na
maioriadasorganizaes.Desenvolvedoresescrevemseuscdigoscolaborativamentee
comferramentasparadarapoiosatividadestaiscomogerenciamentodeconfigurao,
IDEs (integrated development environment), ferramentas de desenvolvimento, testes
unitrios,etc.Apsodesenvolvimentoamaioriadasorganizaespossuiumservidor
debuildcentralizadoondeocdigocompilado.apartirdorepositriodebuildsque
o processo se diferencia das metodologias geis tradicionais, pois, a partir desses
estgios, mltiplos builds so armazenados no repositrio para facilitarem suas
implantaes para fins distintos, ou seja, implantao para o provisionamento de
ambientes de testes dos mais variados tipos incluindo testes de volume, funcional,
performance e ambiente de produo. Nas abordagens tradicionais, um release
candidateatrasadoaomximoparagarantirqueosoftwaretenhaqualidadeeesteja
funcionalmentecompleto,mesmoquedemorandoesegastandomaistempoecustos,ao
passoqueemumpipelinetpicoDevOpscadacheckinumpotencialreleasecandidate
obedecendooambienteautomatizadodosestgiosdopipelineeeconomizandoassim
tempo e custos em testes prolongados. No pipeline de ambiente DevOps so feitas
vriasimplantaesparavriosambientessimilarmentesfeitasemproduoseguindo
uma estratgia de entrega de software, tais como ambiente de testes, de produo,
nuvemouatambientescompartilhadosporterceiros.Oobjetivotersempreemmente
avisualizaodeversoparaserimplantadadeacordocomanecessidadedecada
ambiente facilitando assim o processo de implantao na escolha da verso a ser
implantada.Nesseprocessoessencialousodevirtualizao,gernciadeconfigurao
eativosemambientedeinfraestruturaeambientesemnuvem.Assim,DevOpsoferece
umambientecompossibilidadeeeficinciadeimplantaoemminutosparaoambiente
desejado,almdeumambientecomtodavisibilidadedopipeline.
OpipelinedeDevOpsenvolvediversasprticasquehojesoimplantadaspor
organizaes de diferentes maneiras, cada uma de acordo com sua necessidade.
Conformevistoem[9]e[10]algumasprticassoutilizadasnopipelinedeentregae
tambmasprticasetcnicasquesuportamessepipeline.Algumasprticasqueso
utilizadas na implantao do pipeline so o planejamento do release, integrao
contnua,testescontnuos,implantaoeentregacontnua,monitoramentoefeedback
contnuo.Comoprticasquesuportamessepipelinesepodecitarainfraestruturade
ambientes,agernciadedadoseocontroledeversoavanado.

6. FerramentasparaAuxliodoDevOps
Fizemos umapesquisasobreferramentas queservemdeauxilioaousodeDevOps
vamos dar neste artigo enfoque a diversas ferramentas dado como bases etapas do
desenvolvimentodeumprojetodomundoreal,soestas:build,deploy.
Naetapade build desejaseferramentasquefaamcontroledeverses,execuodo
build ecompilaodocdigo.Falaremosarespeitosobreferramentasdecontrolede
verseseexecuodo build, umavezqueumaferramentadecompilao(JDKpor
exemplo)fogedofocodesteartigo.
6.1.Ferramentasusadasnoprocessodebuild
A) Gitumsistemadecontroledeversesdesignadoparalidardesdecompequenasat
grandesaplicaescomrapidezeeficincia.[2]
B) MavenUmaferramentautilizadapararealizaodo building dequalqueraplicao
Java,visandotornaresteprocessomaisfcileprovendoinformaessobreoprojetode
umamaneirarpida.[3]
6.2.Ferramentasdemonitoramento
Quando trabalhamos com grandes aplicaes devemos assumir uma espcie de
compromisso, temos que garantir a estabilidade do sistema podemos verificar seu
funcionamentosimplesmentetentandoacessloouverificandocadatipodefalhaque
possaocorrerouquetenhaocorrido.Pormtalprocessoconsometempo,paraisto
utilizamseferramentasdemonitoramentoondenelesdefinimosasverificaesaserem
feitasparaquesaibamosseosistemaestoperandonormalmenteouno.Esperasede
talsistemaqueelealerteosadministradoressobreaexistnciadafalhaparaqueesta
entopossasercorrigida.Umaferramentaqueatendeaesterequisitoo Nagiosque
mesmosendoumaferramentaantigaaindapossuiumagrandecomunidadeusuria.
Quando adicionamos uma ferramenta de monitoramento a algum sistema de boa
prticaquesetenhaumservidordedicadoespecialmenteaisto,vamossuporquenossa
ferramentademonitoramentorodajuntocomobancodedadosnummesmoservidor,
caso este servidor falhe tanto a base de dados quanto o software monitor ficaro
inutilizveis e com isso no poderemos saber e nem tratar a falha que ocorreu no
sistema.[DaniloSato,2014]
Neste contexto existem duas entidades, o supervisor e o supervisionado, onde o
primeirodeveverificarseosistemaestfuncionandocorretamenteeenviaralertascaso
encontrefalhaseosegundoquemdefatoexecutaalgummdulodosistemaonde
serameventualmenteencontradasfalhas.[DaniloSato,2014]
6.3.FerramentasdeConfiguraoeGerenciamento
Emprimeiromomentovamosdefiniralgunsconceitosaboradosnessasessodoartigo:
A) NodecentricArtifacts (NCA)so scripts imagensmodulosdeconfigurao,etc.que
so executados em um unico nodo seja este uma maquina virtual ou um servidor,
consequentementeNCAsnopodemserutilizadosparadesenvolverporcompletouma

topologia da aplicao.[Johannes Wettinger, Uwe Breitenbucher, Frank Leymann,

2014]
B) EnvironmentcentricArtifacts (ECA)sopacotes, templates ,etc.quesoexecutados
emumambientepotencialmentecontendovriosnodoscomovriosnodospodemestar
conectadosECAspodemserutilizadosparadesenvolvertopologiascompletasdeuma
aplicao.[JohannesWettinger,UweBreitenbucher,FrankLeymann,2014]
C) Artifacts soscripts,templates utilizadosedistribuidoslivrementepelacomunidade
quefazusodosDevOps[JohannesWettinger,UweBreitenbucher,FrankLeymann,
2014]

6.3.1.Chef
umFrameworkutilizadoparadefinirconfiguraesderecursostaiscomoVMs,por
exemplo,estasconfiguraessodefinidascomoreceitas,quandovariasdestasreceitas
estoacopladasemumpacotedamosaesteonomedecookbook(livrodereceitas).Por
exemploumlivrodereceitasMySQLdeveconterasreceitasparainstalaodeambos
clienteeservidorparaquesejamimplementadostodososelementosdoMySQL.
UmservidorChefagecomoumacentraldegestodereceitas,listasdeexecuoe
atributos, coookbooks soclassificadoscomoNCAumavezque scripts MySQLs
podemserutilizadosparaconfigurarumservioSQL,porexemplo.

Figura 1.Exemplo Chef

6.3.2.Juju
Juju serve como um ambiente central para implementao e configurao de
desenvolvimentoautomatizado.SimilaraoChefestaferramentapossui Charms onde
estes contem scripts para implementar um ciclo de vida bem definido de algum
componente,comoumservidorMySQL,porexemplo,tais scripts podemserescritos
emqualquerlinguagemdeprogramaodesdequeosscriptssejamexecutadosnonodo
alvodeformacorreta.
InstanciasdeCharmspodemserconectadasdamesmamaneiraqueumcomponentede
umaaplicaosecomunicacomumabasededados,porexemplo,.Estasinterligaes
so explicitamente expresadas e devem ser configurveis. Charms se encaixam na
categoriadeECA.

Figura 2. Exemplo Juju

6.3.3.Outrosaspectosaseremconsiderados
Noiniciodestasessolevantamosdoisconceitossobreartifacts,masficaaduvidade
qualdosdoistiposutilizaremdeterminadapartedodesenvolvimentodaaplicao,para
istodevemseobservaralgumascaracteristicas:
1) Niveldedependenciaalgunsartifactssodependentesdeprovedores,porexemplo,
templatesdeCloudFormationspodemserutilizadosemcombinaocomoprovedor
Amazon,porexemplo.[JohannesWettinger,UweBreitenbucher,FrankLeymann,
2014]
2) NiveldeVirtualizaoartifactspodemserdependentesdeferramentasde
virtualizao.[JohannesWettinger,UweBreitenbucher,FrankLeymann,2014 ]
3) ECAspodemserdistinguidosemdoisgruposcentradoseminfraestruturaecentrados
naaplicaoosartifactsdoprimeirogrupotemcomoobjetivoaconfiguraoe
orchestraodosrecursosdeinfraestrutura,VM,armazenamentodedados,rede,j
pacotesJujusomuitomaisfocadosemaplicaoumavezquefocamnaorchestrao
demiddlewaresoucomponentesdeaplicao.[JohannesWettinger,Uwe
Breitenbucher,FrankLeymann,2014]

Referncias
[1] Rebellabs. (2013) IT Ops & DevOps Productivity Report 2013: Tools,
Methodologies

and

People,
http://pages.zeroturnaround.com/rs/zeroturnaround/images/itopsdevops
productivityreport2013%20copy.pdf?
mkt_tok=3RkMMJWWfF9wsRouva7MZKXonjHpfsX66e0kWq6g38431UFwdcjKP
mjr1YAATcB0aPyQAgobGp5I5FEATrbYTK13t60OXw%3D%3D.
[2]Httermann,M.(2012).DevOpsfordevelopers.Apress.
[3] Braga, F. A. M. (2015). Um panorama sobre o uso de prticas DevOps nas
indstriasdesoftware.
[4]SatoD.(2014). DevOpsnaprtica:entregadesoftwareconfiveleautomatizada.
CasadoCdigo.
[5] Steinberg, D. (2008).The ThoughtWorks Anthology: Essays on Software
TechnologyandInnovation.PragmaticBookshelf.
[6]Debois,P.(2008,August).Agileinfrastructureandoperations:howinfragileare
you?.InAgile2008Conference.
[7]Allspaw,J.,&Hammond,P.(2009,June).10+DeploysPerDay:DevandOps
CooperationatFlickr.InVelocity:WebPerformanceandOperationsConference.
[8]Bass,L.,Weber,I.,&Zhu,L.(2015).DevOps:ASoftwareArchitect'sPerspective.
AddisonWesleyProfessional.
[9]SharmaS.(2014).DevOpsforDummies:AWileyBrand.

[10]HumbleJ.;MoleskyJ.(2011).WhyEnterprisesMustAdoptDevopstoEnable
ContinuousDelivery.CutterITJournal.