1

A CULTURA DEVOPS NO DESENVOLVIMENTO E ENTREGA DE

SOFTWARE: UMA REVISÃO NOS PROCESSOS TRADICIONAIS

Michael Juvenal de Oliveira, Pós-Graduação em

Arquitetura de Software.
Professor orientador: Ms. Thiago Chierici Cunha.

Resumo

O mercado de tecnologia está cada vez mais competitivo, exigindo da indústria de

tecnologia de informação uma resposta rápida as necessidades do mercado através de
softwares com qualidade, confiabilidade e de rápida entrega. Os processos tradicionais
de desenvolvimento de software não satisfazem as atuais exigências do mercado. Este
artigo apresenta a cultura devops e como suas práticas oferecem as empresas
oportunidade para otimizar o processo de entrega e desenvolvimento de software. Esta
pesquisa, de caráter exploratório e qualitativo, realizado por meio de revisão
bibliográfica permitiu concluir que através da cultura DevOps e suas áreas como a
integração continua, testes automatizados, automatização infraestrutura entre outras,
oferecem as organizações uma alternativa para atender os novos desafios do mercado.

Palavras-chave: Desenvolvimento de software; Cultura devops; Automatização de

processos; Testes automatizados; Automação de infraestrutura; Integração continua;
Qualidade de manutenção de software; Boas práticas em desenvolvimento de software.

Abstract

The technology market is increasingly competitive, requiring the information technology

industry to respond quickly to market needs through quality, reliable and fast delivery
software. Traditional software development processes do not meet current market
requirements. This article presents the culture DevOps and how their practices offer
companies the opportunity to optimize the process of delivery and software
development. This research, exploratory and qualitative, carried out through a literature
review allowed us to conclude that through the DevOps culture and its areas such as
continuous integration, automated testing, automation infrastructure and others offer
organizations an alternative to meet the new challenges of the market.

Keywords: Software development; DevOps culture; Automation of process; Automated

testing; Infrastructure automation; Continuous integration; Quality of software
maintenance; Best practices in software development.
 2

1. INTRODUÇÃO1

A indústria da tecnologia está cada vez mais competitiva, exigindo uma resposta rápida
as necessidades do mercado através de softwares com qualidade, confiabilidade e de
rápida entrega. Para (Macaúbas, 2010), o mercado está cada vez mais agressivo, e é
extremamente difícil conciliar as necessidades de inovação, criação e excelência
dentro de orçamentos e prazos apertados que regulam a indústria de desenvolvimento.
Ainda nesta linha, (Sharma e Coyne, 2017), afirma que neste cenário, muitas
organizações têm falhado em projeto de desenvolvimento de software e gerado perdas
de negócio. Geralmente suas falhas são relacionadas no processo de desenvolvimento
e entrega de software

Diante deste contexto apresentado, é possível levantar a seguinte questão: os

processos de desenvolvimento de software tradicionais são adequados ou a cultura
devops pode ser uma alternativa para atender os atuais desafios exigidos pelo
mercado?

Para responder esta questão, este trabalho tem como objetivo realizar uma análise nos
processos tradicionais e descrever como a cultura devops e suas práticas podem
atender as demandas exigentes atuais do mercado.

Como afirma Braga (2015),

dados históricos de 2001 (STANDISH GROUP, 2001), utilizando como base
8380 projetos, mostraram que apenas 16,2% dos projetos foram entregues
respeitando os prazos e os custos e com todas as funcionalidades
especificadas. Aproximadamente 31% dos projetos eram cancelados antes de
estarem completos e 52,7% eram entregues, porém com prazos maiores,
custos maiores ou com menos funcionalidades do que especificado no início do
projeto. Dentre os projetos que não eram finalizados de acordo com os prazos
e custos especificados, a média de atrasos era de 222%, e a média de custo
era de 189% a mais do que o previsto.

1 Você pode utilizar notas de rodapé. Entretanto, não é uma boa prática o uso excessivo. Fonte Arial
tamanho 10 – Espaço simples entre linhas.
 3

Segundo Kort (2016), o setor de desenvolvimento de software não tem uma boa
reputação quando se trata no cumprimento do projeto no tempo e orçamento acordado.

Este artigo está divido da seguinte forma: no próximo tópico, item 2, está detalhado a
metodologia de trabalho, seguido no tópico 3 de referencial teórico com os conceitos de
devops, práticas de ..., juntamente com as considerações finais.

2. METODOLOGIA

Este estudo de pesquisa apresenta evidencias no aspecto das metodologias e práticas

tradicionais em relação a cultura devops. A pesquisa é de natureza aplicada, e gera
conhecimento a respeito da cultura devops e suas práticas servindo como referência a
indústria de desenvolvimento de software que desejam conhecer ou aderir para se
adequar as necessidades do mercado atual.

Esta pesquisa é de abordagem exploratória e descritiva, uma vez que informações

sobre o tema foram identificadas e coletadas com base revisões bibliográficas em
livros, dissertações de mestrado através de uma análise qualitativa.

Estabeleceu-se nesta pesquisa a contextualização das metodologias tradicionais em

confronto a cultura devops e como estas práticas podem gerar benefícios. De acordo
com (Sharma e Coyne, 2017), a cultura DevOps aplicada a princípios de metodologia
ágil e lean no processo de desenvolvimento de software permite as empresas
aumentar a velocidade de entrega de um produto ou serviço.

Seria realizada uma pesquisa bibliográfica para identificar os seguintes pontos:

• Quais são as principais práticas devops e como elas podem gerar benefícios
para empresas de TI?
• Por que a cultura devops surge como alternativa para resolver novos desafios do
mercado exigente?
 4

• Os métodos tradicionais no desenvolvimento de software são suficientes para

realizar entregas repetidas e confiáveis?

Este artigo não tem a pretensão de apresentar todas as metodologias tradicionais e

ágeis disponíveis na literatura. Assim sendo, buscou-se identificar como as
metodologias e práticas tradicionais de desenvolvimento de software possuem
dificuldades para responder as necessidades de um software nos tempos atuais.
Assim, serão descritas práticas da cultura devops como: integração contínua, entrega
contínua, testes contínuos e automatizados, infraestrutura como código e pipeline de
implantação.

Os subitens adiante servem como fundamentação teórica da pesquisa e estudo de

caso proposto.

3. REVISÃO DE LITERATURA

3.1 DevOps

O termo devops vem da mistura da equipe de desenvolvimento (incluindo

desenvolvedores, equipe de testes e qualidade) e operações (representando
especialistas de implantação e mantenedores de infraestrutura). Devops descreve
práticas que agilizam o processo de entrega de software, enfatizando a melhoria
contínua, produzindo uma entrega rápida e um software de melhor qualidade alinhado
aos requisitos de negócios. (Hüttemann, 2012). Nesta mesma linha (Braga, 2015),
afirma que devops se baseia em princípios de metodologia ágeis como lean e ágil,
onde equipes de desenvolvimento, operações e qualidade trabalham de modo
colaborativo para desenvolvimento e entrega de um software de forma continua.

Segundo Braga (apud WOOTTON, 2013), as organizações estão descobrindo que os

modelos tradicionais de desenvolvimento de software e de entrega não são suficientes.
 5

Os processos manuais são propensos a erros, quebras, desperdício e atraso de

resposta às necessidades de negócios

Devops abrangem inúmeras atividades de aspectos como:

Cultura – pessoas em conjunto com ferramentas, onde os softwares são

desenvolvidos por pessoas e para pessoas.

Automação – automação como parte fundamental para receber rápido feedback.

Medição – devops encontra um caminho especifico para medição, onde qualidade e

compartilhamento são incentivos críticos.

Compartilhamento – pessoas compartilham suas ideias, processos e ferramentas.

3.1 Metodologia ágil

As metodolofias ágeis nasceram das definiciencias dos modelos tradicionais.

Segundo Silva (apud STEFFEN, 2012) “O ágil surgiu dada a necessidade de
melhorarmos a forma como estamos desenvolvendo software e nosso foco principal
é satisfazer o cliente”. O Manifesto Ágil é um documento criado em 2001 por 17
experientes programadores e arquitetos de software buscando resolver os
problemas frequentemente encontrados em projetos de desenvolvimento de
software (SILVA, 2016).

O manifesto ágil possui quatro valores, sendo eles:

• Indivíduos e interações mais que processos e ferramentas
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.
 6

Foi definido também os 12 princípios por trás do manifesto ágil:

1. Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e

contínua de software de valor.
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos
ágeis se adequam a mudanças, para que o cliente possa tirar vantagens
competitivas.
3. Entregar software funcionando com freqüencia, na escala de semanas até
meses, com preferência aos períodos mais curtos.
4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em
conjunto e diáriamente, durante todo o curso do projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e
suporte necessário, e confiar que farão seu trabalho.
6. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de
um time de desenvolvimento, é através de uma conversa cara a cara.
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os patrocinadores,
desenvolvedores e usuários, devem ser capazes de manter indefinidamente,
passos constantes.
9. Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser
feito.
11. As melhores arquiteturas, requisitos e designs emergem de times auto-
organizáveis.
12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se
ajustam e otimizam seu comportamento de acordo.

3.2 Scrum
 7

3.2 Metodologias tradicionais

O modelo tradicional dominou o desenvolvimento de software até meados dos anos 90,
mesmo recebendo advertências sobre os problemas gerados sobre adoção desta visão
sequencial de tarefas de pesquisadores e desenvolvedores da área. Metodologias
tradicionais ou metodologias pesadas ou orientadas a documentação, surgiram em um
cenário de desenvolvimento de software diferente do atual, onde se baseou apenas em
mainframe e terminais burros. Assim, o software era planejado e documentado antes
de ser implementado (Soares, 2004).

Para (Souza e Rivas, 2014), afirma que,

o método waterfall sempre foi efetivo em projetos com requisitos bem definidos,
tecnologia bem conhecida e baixo risco geral. Neste contexto, o escopo, os
requisitos, a tecnologia, as tarefas requeridas e os níveis de recursos são
suficientemente previsíveis para que o projeto possa ser totalmente planejado
antecipadamente.

3.2.1 Metodologia cascata

A modelo cascata, utiliza uma abordagem sequencial para o desenvolvimento de

software, acontecendo em fases definidas como análise, design, implementação,
testes, integração e manutenção. A saída de cada uma dessas fases serve como
entrada para a fase seguinte. Este modelo assume que o desenvolvimento de
software é preditivo e linear, onde o cliente sabe o que quer, os desenvolvedores
sabem como implementar e nada ou quase nada irá mudar durante a fase de
desenvolvimento. (Macaúbas, 2010).

• Definição de requisitos – os requisitos são coletados junto ao cliente, a

seguir estes requisitos passam por aprovação do cliente e seguem para o
projeto do software.

• Projeto do software – são realizados a definição da estrutura de dados,

arquitetura de software, detalhes procedais e caracterização das interfaces.
 8

• Implementação – etapa onde são criados os sistemas através de

codificação.

• Manutenção - consiste na correção de bugs que não foram detectados na

fase de implementação.
 9

3.2.1 PROPOSTA DE APLICAÇÃO DA CULTURA DEVOPS EM UMA EMPRESA DE

TI PARA ATENDER AS EXIGÊNCIAS DO MERCADO
A empresa
 10

4. CONTEXTUALIZAÇÃO DAS METODOLOGIAS TRADICIONAIS COM A

CULTURA DEVOPS

5. METODOLOGIA TRADICIONAL

Em 1970, a partir da publicação de um artigo nasceu o framework mais conhecido

de metodologia de software, chamado de waterfall (Rivas & Souza, 2014). Esta
metodologia de desenvolvimento de software é composta por um conjunto de
atividades que auxiliam o desenvolvimento de um software. Braga (2015) explica que
no waterfall cada fase do desenvolvimento é iniciada após a finalização da anterior.
Equipe de testes e equipe de operações iniciam atividades apenas quando as
atividades antecessoras foram concluídas. As equipes são separadas em silos, cada
equipe defende seus interesses trabalhando separadamente e não compartilham
informações

Há inúmeras metodologia disponíveis no mercado, porém elas possuem

algumas atividades em comum como a especificação de software, projeto de
implementação de software, validação de software e evolução do software. É comum
que as empresas adaptem esta metodologia a sua realidade e outras que não adotem
nenhum tipo de metodologia (SOARES, 2004).

De acordo com MASSITELA (2016), a metodologia tradicional possui as seguintes

vantagens:

• Ordem sequencial de fases torna o processo estruturado;

• Uma fase inicia apenas até que as anteriores estejam completas;
• Todas as atividades são essenciais e acontecem na ordem definida;
• É utilizado como norma no desenvolvimento de grandes softwares;
• Identifica um conjunto de documento produzidos através de cada etapa do
processo de desenvolvimento.
 11

Massitela (2016) descreve que o modelo clássico por possuir tarefas claras e
definidas, se torna simples se estabelecer custo, prazo de entrega e fácil entendimento.
A metodologia tradicional é ideal para projetos onde os requisitos sofrem poucas
alterações durante o desenvolvimento. Ainda nesta linha, Rivas & Souza apud Boehm
(2003) “[...] o método waterfall sempre foi efetivo em projetos com requisitos bem
definidos, tecnologia bem conhecida e baixo risco geral”.

3.3 Práticas Devops

Integração contínua

Ainda nesta linha, para Silva (2015), integração continua é uma prática que consiste
em integrar continua o trabalho realizado pelos desenvolvedores a cada envio ao
repositório de fontes.

Fowler (2009), explica que a integração continua funciona com a codificação de uma
pequena parte de um sistema, onde o processo inicia quando o programador obtém
uma cópia das fontes atualizadas através de um sistema de controle de código. Após a
conclusão da tarefa de implementação, realiza-se a construção de uma versão do
sistema de forma automatizada a partir desta nova implementação, onde são
realizados testes automatizados. Somente os builds que não tiverem erros serão
considerados bons e serão persistidos no repositório.
 12

Figura 1 - Integração contínua. Fonte: Sharma e Coyne, 2017.

Para Sharma e Coyne (2017), o conceito que os desenvolvedores integrem seus

trabalhos com o resto da equipe para em um segundo passo possa realizar testes
integrados. A integração continua possibilita a descoberta precoce e a exposição dos
riscos de integração.

Entrega contínua

A entrega continua nasceu para reduzir custos, tempo e risco no processo de entrega
de software. Através de automatização via ferramentas e scripts, é possível implantar
um software a qualquer momento. A gerência de configuração oferece técnicas,
processos e ferramentas para automatizar a implantação de softwares em ciclos curtos
(Almeida, 2014).

Para Fowler (2013), você está realizando uma entrega contínua quando:
• O software é implantável durante seu ciclo de vida e sua equipe prioriza manter
o software implantável ao trabalhar com novos recursos.
• Habilidade de feedback rápido e automatizado sobre a prontidão de produção de
seus sistemas sempre que acontece uma mudança.
• Você pode executar implantações automatizadas de qualquer versão do
software em diferentes ambientes.
 13

Para Silva (2014), a entrega continua é uma pratica que possibilita a entrega de
software para o ambiente de produção através de um processo confiável, previsível,
visível e automatizado. Essas entregas acontecem em pequenas porções com uma
frequência muito maior que as entregas tradicionais. Através desta prática diminuem o
tempo o risco associado as entregas de novas versões para os usuários, permitindo o
feedback e colaboração entre a equipe.

Testes integrados

Testes integrados representam a automação de testes que são executados através da

integração contínua em cada fase possibilitando a rastreabilidade dos resultados. Com
implantações sendo feitas cada mais rapidamente, se torna impossível executar testes
manuais de todas as funcionalidades a cada nova release. Através desta prática, erros
podem ser identificados e corrigidos mais rapidamente (Silva, 2014).

Com os testes contínuos é admissível testar o código o mais cedo possível durante o
ciclo de desenvolvimento de software, o que possibilita redução e aumento da
qualidade do produto gerado, assim é possível validar o código implementado e
integrado a outros desenvolvedores (Sharma & Coyne, 2017).

Implantação automatizada

Feedback contínuo
 14

As ilustrações podem ser inseridas no conteúdo do texto. Se a Figura for grande

demais para o final de uma página, insira o máximo de texto possível para não ficar
espaços sem conteúdo.

A Figura deve ficar na mesma página do seu Título e da sua Fonte. A figura deve estar
legível o suficiente para o leitor e não utilize figuras em língua estrangeira, deve ser
centralizada e não pode ultrapassar o limite da página.

Figura 1: Características da Web 2.0.

Fonte: BLATTMANN; SILVA, 2007, p. 192.

Tamanho da Fonte da Figura e de sua Fonte – Arial 10 – espaço simples entre linha.
Não é boa prática ter Ilustrações seguidas sem um texto de contexto entre elas.

Quadro 1. Comparativo entre conceitos e linguagens semânticas e não semânticas

Origem Primitiva Expressividade Representação Semânticas

Distribuída Formais
E/R 1976 Relação • Não Não
UML 1995 Objetos •• Não Sim
XML 1998 Entidades •• Sim Não
RDF/ 2004 Recursos •••• Sim Sim
OWL

Fonte: Mika, 2007. (Adaptado pelos autores).

Não finalizar uma seção com uma Ilustração sem um pequeno contexto.
 15

4. DISCUSSÃO DOS RESULTADOS

Ainda sobre as Ilustrações, se for de sua autoria, deve constar na fonte conforme a
FIG. 2.

Figura 2: Modelo de arquitetura corporativa na mineração de dados.

 16

Fonte: o autor, 2016.

Outra boa prática é não finalizar uma seção com uma figura, sem um breve contexto da
mesma.

5. CONSIDERAÇÕES FINAIS

Parte final do artigo, na qual se apresentam as conclusões.

REFERÊNCIAS

Utilize o mesmo padrão de fonte e espaçamento do artigo. Contudo, alinhe as

Referências à esquerda e as coloque em ordem alfabética. Abaixo têm-se alguns
exemplos.

Livros
SOBRENOME, Nome. Título: subtítulo (se houver). 2. ed. (número da edição – se
houver. Somente da segunda adiante). Local de publicação: Editora, data de
publicação da obra.

MIKA, P. Social networks and the semantic web. New York: Springer, 2007.

Capítulo de livro
SOBRENOME, Nome do autor do capítulo. Título: subtítulo (se houver) do capítulo. In:
AUTOR DO LIVRO (tipo de participação do autor na obra, Org(s), Ed(s) etc. se houver).
Título do livro: subtítulo do livro (se houver). Local de publicação: Editora, data de
publicação. paginação referente ao capítulo.
 17

Artigos
SOBRENOME, Nome; SOBRENOME, Nome. Título: subtítulo (se houver). Nome do
periódico, local de publicação, volume, número ou fascículo, paginação, data de
publicação do periódico.

BLATTMANN, U.; SILVA, F. C. C. Colaboração e interação na Web 2.0 e Biblioteca 2.0.

Revista ACB, Florianópolis, v. 12, p. 191-215, 2007.

Teses e dissertações
SOBRENOME, Nome. Título: subtítulo (se houver). Total de folhas. Tese (Doutorado)
ou Dissertação (Mestrado) - Instituição onde a Tese ou Dissertação foi defendida. Local
e data de defesa.

Documento publicado na internet

AUTOR(ES). Título: subtítulo (se houver) Disponível em:<endereço da URL>. Data de
acesso: (exemplo 25 out. 2016).

Normas da ABNT:
ABNT. NBR 6022: informação e documentação: artigo em publicação periódica
científica impressa: apresentação. Rio de Janeiro, 2003. 5 p.
ABNT. NBR6023: informação e documentação: elaboração: referências. Rio de
Janeiro, 2002. 24 p.
ABNT. NBR6024: Informação e documentação: numeração progressiva das seções de
um documento. Rio de Janeiro, 2003. 3 p.
ABNT. NBR6028: resumos. Rio de Janeiro, 2003. 2 p.
ABNT. NBR10520: Informação e documentação: citações em documentos. Rio de
Janeiro, 2002. 7p
ABNT. NBR 14724: informação e documentação: trabalhos acadêmicos: apresentação.
Rio de Janeiro, 2002. 6 p.