MODELOS DE PROCESSOS DE SOFTWARE 3

Prévia do material em texto

Modelos de Processos 
de Software
Material Teórico
Responsável pelo Conteúdo:
Prof. Me. Artur Marques
Revisão Textual:
Prof.ª Dr.ª Luciene Oliveira da Costa Granadeiro 
Controle e Entrega de Software
• Introdução;
• Mudança de Requisitos;
• Gestão de Mudança Ágil;
• DevOps e Entrega Contínua;
• Integração Contínua.
• Compreender a importância do controle de mudança e requisitos em processos de 
softwares para criação de produtos de qualidade.
OBJETIVO DE APRENDIZADO
Controle e Entrega de Software
Orientações de estudo
Para que o conteúdo desta Disciplina seja bem 
aproveitado e haja maior aplicabilidade na sua 
formação acadêmica e atuação profissional, siga 
algumas recomendações básicas: 
Assim:
Organize seus estudos de maneira que passem a fazer parte 
da sua rotina. Por exemplo, você poderá determinar um dia e 
horário fixos como seu “momento do estudo”;
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
alimentação saudável pode proporcionar melhor aproveitamento do estudo;
No material de cada Unidade, há leituras indicadas e, entre elas, artigos científicos, livros, vídeos 
e sites para aprofundar os conhecimentos adquiridos ao longo da Unidade. Além disso, você tam-
bém encontrará sugestões de conteúdo extra no item Material Complementar, que ampliarão sua 
interpretação e auxiliarão no pleno entendimento dos temas abordados;
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de discus-
são, pois irão auxiliar a verificar o quanto você absorveu de conhecimento, além de propiciar o 
contato com seus colegas e tutores, o que se apresenta como rico espaço de troca de ideias e 
de aprendizagem.
Organize seus estudos de maneira que passem a fazer parte 
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Mantenha o foco! 
Evite se distrair com 
as redes sociais.
Determine um 
horário fixo 
para estudar.
Aproveite as 
indicações 
de Material 
Complementar.
Procure se alimentar e se hidratar quando for estudar; lembre-se de que uma 
Não se esqueça 
de se alimentar 
e de se manter 
hidratado.
Aproveite as 
Conserve seu 
material e local de 
estudos sempre 
organizados.
Procure manter 
contato com seus 
colegas e tutores 
para trocar ideias! 
Isso amplia a 
aprendizagem.
Seja original! 
Nunca plagie 
trabalhos.
UNIDADE Controle e Entrega de Software
Introdução
Uma das coisas mais comuns que ocorrem em um projeto de software é que seus 
requisitos vão mudar. Se não bastasse isso, também as funcionalidades e as formas de 
fazer as coisas mudarão durante o tempo do projeto de software, assim como coisas 
que não existiam serão criadas durante esse período de tempo pelos usuários, pelo 
sponsor, pelo seu chefe, pelo chefe do seu chefe, pela sociedade, por alguma “ideia 
brilhante” etc. Isso irá acontecer, independe de ser utilizado um processo de desenvol-
vimento de software tradicional ou ágil e – com perdão pela franqueza – como muitos 
“agilistas de plantão” dizem: “a mudança é trabalhosa, a mudança cansa e a mudança 
impede implementações livres de erro”. Certo, mas então por que aceitamos a mu-
dança e como isso virou um “mantra” na área de TI no planeta?
Bom, porque a humanidade evoluiu até hoje por causa das mudanças. Somos 
uma espécie curiosa e tudo o que fazemos gera mudança, alteramos até mesmo 
o ecossistema do planeta para nos servir, por exemplo, ou seja, a mudança nos 
moldou e acaba definindo a nossa própria espécie. Portanto, o jeito é administrar e 
controlar a mudança para que o benefício seja maior que o malefício, e isso inclui 
a sua saúde.
Vamos entender como isso ocorre num processo de sistema, mas primeiro va-
mos entender Gestão de Mudança.
Mudança de Requisitos
As alterações podem se originar de várias fontes, incluindo clientes, usuários 
finais, equipe de projeto ou equipe de testes. As requisições de mudanças podem 
vir também de clientes e usuários finais e essas realmente seriam mudanças em 
seus requisitos.
Quando falamos da equipe do projeto, podem vir alterações de design, da equi-
pe de teste. Eles podem solicitar alterações no código ou em comportamento mo-
tivados por regras de negócios mal interpretadas ou incompletas. 
De qualquer forma, esses pedidos de alterações são comunicados ao gerente do 
projeto, e, se estamos falando de um processo formal – é bom que seja assim –, 
usaremos um formulário de Solicitação de Mudança. Esse formulário deve conter 
detalhes do projeto, módulo e componente que provavelmente serão afetados pelo 
pedido de mudança, assim como as razões ou motivos para que essa mudança seja 
acatada apesar dos riscos, custos, cronogramas e possível resultado. Incluindo o 
fato de que é extremamente difícil, às vezes, o ROI – Retorno sobre o Investimento 
– ser medido adequadamente e satisfatoriamente.
Infelizmente, o leitor deste texto, em algum momento de sua carreira na área, pode-
rá receber como justificativa para a mudança uma resposta do tipo “porque eu quis”.
8
9
O que fica como verdadeiro nessa discussão sem saída é que a mudança de re-
quisitos é um dos problemas críticos que o desenvolvimento de software enfrenta. 
Além disso, a falha em lidar com esse problema ameaça o sucesso do desenvolvi-
mento de software no mundo todo. Pense nos problemas de recall das montadoras 
de veículos que estão aumentando de forma exponencial, ou os veículos autôno-
mos, os softwares de vigilância e de saúde – são apenas alguns exemplos.
Quando, em um processo formal, analisamos a mudança, normalmente passa-
mos por uma análise. A análise determinará:
• Se a implementação do pedido de mudança é viável;
• A quantidade de esforço e tempo de calendário necessários para implementar 
o pedido de mudança;
• O impacto do pedido de mudança no projeto geral e, aí, pensamos de forma 
tradicional e no bom e velho triângulo de ferro das restrições de projetos, criado 
por Harold Kerzner, especialmente em termos de esforço, cronograma e custo.
Em outras palavras, uma análise de impacto é necessária.
Se você tratar isso como um processo, algumas estratégias que podem ser ado-
tadas passam por:
• Implementar pedidos de mudança, como e quando recebidos, imediatamente 
após o recebimento;
• Agrupar todos os pedidos de mudanças e implementá-los no final do desen-
volvimento;
• Fazer uma implementação situacional:
» Se o componente que é afetado pelo pedido de mudança ainda não foi co-
dificado ou está sendo codificado, implemente-o somente quando o compo-
nente estiver codificado ;
» Se a codificação do componente afetado pelo pedido de mudança for conclu-
ída, mantenha o pedido de mudança pendente e atualize-o no final.
Uma vez decidida a implementação, pense no seguinte:
• O pedido de mudança será alocado para resolução a um ou mais mem-
bros da equipe de desenvolvimento?
• Os membros da equipe executarão a codificação e modificação neces-
sárias do código existente, conforme necessário. Essa atividade será re-
gida pelas diretrizes de codificação do projeto ou por algo não definido 
tipo “go crazy horses”;
• O pedido de mudança será alocado para que haja uma revisão por pa-
res, caso se esteja usando um processo baseado em XP – Programação 
Extrema? Se, sim, os pares revisariam o código para garantir que:
• A implementação atende aos requisitos do pedido de mudança;
• A implementação está em conformidade com as diretrizes de codificação 
definidas e outros padrões de engenharia de software da organização;
9
UNIDADE Controle e Entrega de Software
• Não há código lixo ou código malicioso no software;
• O código alterado garante eficiência nos tempos de execução e res-
posta (requisitos de qualidade).
• Depois que o pedido de mudança for aprovado na Revisão por Pares, 
ele será enviado para a equipe de testes para um Teste de Regressão;
• A equipe de teste executaria o teste de regressão para garantir que 
todas as funcionalidades solicitadas no pedido de mudança estejam fun-
cionando corretamente e que nenhuma outra funcionalidadeoriginal 
seja afetada pela implementação;
• Depois que o teste de regressão é concluído, e todos os defeitos apon-
tados na revisão por pares ou no teste de regressão são resolvidos e 
fechados, o pedido de mudança é fechado, ou seja, está resolvido e 
implementado. (BRIGHT HUB MEDIA, 2009, p. 3)
Atualizado
Atualizado
Atualizado
Veri�cação
Veri�cação
Identi�cação da Mudança
• Elicitação
• Representação
Análise da Mudança
• Impacto
• Prioridade
Estimativa de Esforço
Custos da mudança
• Custos
• Tempo
Veri�cação
Veri�cação
Veri�cação
Partes Interessadas
Requisitos Voláteis
Figura 1 – Sugestão de um Processo de gerenciamento de mudanças tradicional
“Identificamos três áreas principais de uma abordagem prática para ge-
renciar mudanças. Essas áreas são: identificação de mudanças, análise de 
mudanças e estimativa de custos de mudanças.” Conforme adaptação de 
JAYATILLEKE, S.; LAI, R. Uma revisão sistemática do gerenciamento de 
alterações de requisitos. 2018. p. 172.
Gestão de Mudança Ágil
Quando falamos de processos ágeis, o que nos vem à mente é Scrum, porque é 
a forma natural de se liderar, ou melhor, gerenciar um projeto ágil. E um dos gran-
des chavões usados pelos agilistas é “abrace as mudanças”. Bem, muitas vezes, ape-
sar do Scrum e tudo o mais, há certa ausência de um processo formal. Nesse caso, 
recomenda-se que pequenas mudanças que não tenham um impacto significativo 
no projeto sejam aprovadas diretamente pelo Dono do Produto (Product Owner). 
A tolerância para essas pequenas mudanças pode ser definida no nível organi-
zacional, grau de maturidade organizacional, ou ainda, pelo patrocinador de um 
projeto de software específico. 
Na maioria dos projetos, as solicitações de mudança ou os pedidos de mudança 
podem ser classificados como pequenas alterações que devem ser aprovadas pelo 
dono do produto. 
10
11
Portanto, o dono do produto desempenha um papel muito importante no ge-
renciamento de mudanças em um Projeto Ágil e, por consequência, sua gestão 
utilizando o Scrum.
Mas qual é normalmente a dinâmica de um processo de mudança no Scrum? 
Bem, via de regra, os pedidos não aprovados, uma vez encaminhados e discutidos, 
podem ser aprovados pelo dono do produto, ou por alguma parte interessada mais 
o dono do produto, ou, ainda, por algum gestor sênior. Portanto, a gravidade da 
mudança indica a ordem que declaramos – mudanças mais impactantes ou signi-
ficantes ficam a encargo do gerente sênior. Mas... Quando aprovar as mudanças? 
Quando falamos em processo ágil e, principalmente, em Scrum, aprovamos mu-
danças quando estamos diante de desenvolver epopeias, criar backlog priorizado 
do produto e/ou preparar backlog priorizado do produto. 
As solicitações de mudança aprovadas são priorizadas juntamente com outros 
requisitos do produto e suas respectivas histórias de usuário e, em seguida, incor-
poradas ao backlog priorizado do produto.
Os projetos de desenvolvimento do Scrum aceitam as mudanças usando pequenos 
ciclos de desenvolvimento que incorporam o feedback do cliente sobre as entregas 
do projeto após cada Sprint. Isso permite que o cliente interaja regularmente com os 
membros da equipe Scrum, visualize os incrementos do produto à medida que estive-
rem prontos e altere os requisitos anteriormente no ciclo de desenvolvimento. Além 
disso, as equipes de gerenciamento de portfólio ou programa podem responder a 
solicitações de mudança referentes a projetos Scrum aplicáveis em seu nível.
Uma vez feito o trâmite, o backlog atualizado e priorizado do produto deverá ser 
atualizado com as alterações aprovadas.
Mudanças
Priorizadas -
Não Aprovadas
Mudanças
Priorizadas -
Aprovadas
Mudanças
Priorizadas -
Aprovadas
Mudança 1
Mudança 2 Mudança 2
História do usuário 1 História do usuário 1
História do usuário 2
História do usuário 3 História do usuário 2
História do usuário 3História do usuário 4
História do usuário 5
História do usuário 4
História do usuário 5
Mudança 3
Mudança 4 Mudança 4
Mudança 4Mudança 5
Mudança 6
Mudança 7 Mudança 7
Mudança 7
Backlog do Produto
com Priorização
Atualizada
Mudança 2
Figura 2 – Backlog priorizado do produto é atualizado com alterações aprovadas
Fonte: Adaptado de SCRUMSTUDY. Como lidar com solicitações de mudança ou solicitações de mudança em um projeto Scrum? 2017
11
UNIDADE Controle e Entrega de Software
Algumas definições ainda criam muita dúvida no pretendente a usuário Scrum, 
as definições de epopeias e temas são alguns desses casos.
• Epopeias: são histórias grandes de usuários, geralmente grandes demais para 
serem implementadas em uma única iteração e, portanto, precisam ser desa-
gregadas em histórias de usuários menores em algum momento. As epopeias 
geralmente são histórias de usuários com prioridade mais baixa porque, uma 
vez que a epopeia se aproxima da parte superior da pilha de itens de trabalho, 
ela é reorganizada em história de usuários menores. Não faz sentido desagre-
gar um épico de baixa prioridade, porque você estaria investindo tempo em 
algo que talvez nunca consiga abordar, a menos que uma parte do épico seja 
de alta prioridade e precise ser provocada. Lembre-se de adiar o comprome-
timento, isso é um mandamento Scrum e do XP também. Assim como em 
FDD, isso ficará para o time de desenvolvimento, algo mais “just in time” ou 
JIT – isso, num time ágil, é bom, além de boa prática para aumentar a produ-
tividade geral;
• Temas: é uma coleção de histórias de usuário relacionadas. Por exemplo, para 
um sistema de matrícula em uma universidade, pode haver temas em torno 
dos alunos, gerenciamento de cursos, geração de turmas, admissão em classes, 
administração de notas e processamento financeiro, entre outros. Os temas 
costumam ser usados para organizar histórias em lançamentos ou organizá-las 
para que várias subequipes possam trabalhar nelas.
Cada iteração implementará os itens
de trabalho de maior prioridade
Cada novo item de trabalho
é priorizado e adicionado a pilha
Itens de trabalho que podem ser
priorizados a qualquer tempo
Itens de trabalho que podem ser
removidos a qualquer tempo
Item de
Trabalho
Baixa
Prioridade
Alta
Prioridade
Modelada em
Baixo detalhe
Modelada em
Grande detalhe
Figura 3 – Processo disciplinado de gerenciamento de mudanças ágeis
Fonte: Adaptado de AMBLER, S.W. Histórias de usuários: uma introdução ágil, 2009
12
13
Independentemente do tamanho de um projeto, existem algumas maneiras de 
aplicar o pensamento ágil ao gerenciamento de mudanças.
• Nunca modele muito à frente. Quanto mais você modelar, menos responsivo 
será o seu design para alterar as solicitações. No entanto, essa necessidade 
deve ser equilibrada com a disponibilidade das partes interessadas;
• Colabore e ajuste com frequência. Primeiro, colabore com os clientes, porque 
eles impulsionam seus produtos. Em seguida, colabore com as partes interes-
sadas e outras equipes, conforme necessário;
• Certifique-se de ter um processo de mudança simples e rápido. Essa é a linha 
de base do seu fluxo de trabalho ágil de gerenciamento de alterações. Se você 
não possui um sistema para alterar seu projeto, ele não é realmente ágil e mui-
to menos o gerenciamento ágil de mudanças;
• Pense em “eficiência da mudança” em vez de “controle da mudança”. Em ágil, 
a mudança é desejável e natural. Essa mudança de perspectiva é uma das mais 
importantes quando se trata de tornar seu processo de gerenciamento de mu-
danças mais eficiente;
• Estabeleça processos regulares baseados em regras para todos os itens acima. 
Há uma razão pela qual o Scrum é realizado diariamente – funciona. O es-
tabelecimento de rotinas, hábitos e sistemas garante que as políticas sejam 
seguidas. Crie documentação e faça o mesmo para todas as opções acima, 
incluindo colaboração, processos de mudança e assim por diante.
DevOps e Entrega Contínua
Não se trata de nada extraordinário, apenas duas siglas que significam desen-
volvimento e operações. É uma expressão de desenvolvimento de software empre-sarial usada para significar um tipo de relação ágil entre o desenvolvimento e as 
operações de TI. 
A problemática é bem antiga e conhecida de todos os que atuam na área de 
tecnologia da informação. Os desenvolvedores e os administradores de sistema 
nem sempre estão de olho em muitas coisas, mas concordam que seus clientes fre-
quentemente os levam a direções diferentes. Por um lado, os usuários corporativos 
exigem mudanças, novos recursos, novos serviços, novos fluxos de receita, o mais 
rápido possível. Ao mesmo tempo, eles também querem um sistema estável e livre 
de interrupções. Isso cria um problema no qual as empresas sentem que precisam 
escolher entre entregar mudanças rapidamente e lidar com um ambiente de produ-
ção instável, ou manter um ambiente estável, porém, obsoleto.
O objetivo de DevOps é mudar e melhorar o relacionamento, defendendo uma 
melhor comunicação e colaboração entre essas duas áreas. Lembrando que de-
senvolvimento é “desenvolvimento de software” e operações são “sustentação ou 
suporte de software e infraestrutura que faz o software rodar”.
13
UNIDADE Controle e Entrega de Software
Vamos imaginar o DevOps como “uma comunidade multidisciplinar de prática 
dedicada ao estudo da construção, evolução e operação de sistemas resilientes que 
mudam rapidamente em escala”, é como Mueller (2010, p. 1) enxerga esse modelo.
Portanto, é a prática de engenheiros de operações e desenvolvimento que par-
ticipam juntos de todo o ciclo de vida do software, desde o design até o processo 
de desenvolvimento e o suporte à produção. Claro, não devemos esquecer que o 
DevOps também é caracterizado pela equipe de operações que utiliza muitas das 
mesmas técnicas que os desenvolvedores para o funcionamento de seus sistemas, 
desde o uso do controle de origem até o teste, até a participação em um processo 
de desenvolvimento Agile.
Tem fortes afinidades com as abordagens Agile e Lean. A visão anti-
ga das operações tendia ao lado “Dev”, sendo os “criadores” e o lado 
“Ops”, às “pessoas que lidam com a criação após o seu nascimento” - a 
realização do dano que foi causado na indústria de esses dois sendo tra-
tados como silos é o principal fator por trás do DevOps. Dessa forma, 
o DevOps pode ser interpretado como uma consequência do desenvol-
vimento ágil de software - Agile prescreve uma colaboração estreita de 
clientes, gerenciamento de produtos, desenvolvedores e (às vezes) con-
trole de qualidade para preencher as lacunas e iterar rapidamente em 
direção a um produto melhor - o DevOps diz que sim , mas a entrega de 
serviços e a forma como o aplicativo e os sistemas interagem também são 
uma parte fundamental da proposta de valor para o cliente e, portanto, a 
equipe do produto precisa incluir essas preocupações como um item de 
nível superior. (MUELLER, 2010, p. 3)
• Valores do DevOps: são efetivamente capturados no Manifesto Agil, focados 
no serviço geral ou no software totalmente entregue ao cliente em vez de sim-
plesmente no “software de trabalho”; 
• Princípios do DevOps: infraestrutura como código é um princípio DevOps 
comumente citado. No nível conceitual, é principalmente apenas a ampliação 
dos princípios do Agile para incluir sistemas e operações, em vez de interrom-
per suas preocupações no check-in de código;
• Métodos do DevOps: podemos usar o Scrum com operações, o Kanban com 
operações, embora geralmente se concentre mais na integração de operações 
com Dev QA – Garantia da Qualidade e Produto nas equipes de produto. Exis-
tem alguns métodos mais distintos, como o controle de alterações e o uso do 
Sistema de Comando de Incidentes para resposta a incidentes;
• Práticas do DevOps: integração contínua e a implantação contínua, usan-
do esquemas de gerenciamento de configuração, métricas e monitoramento, 
uma abordagem de cadeia de ferramentas. Mesmo o uso da virtualização e da 
computação em nuvem é uma prática comum para acelerar as alterações no 
mundo da infraestrutura moderna;
• DevOps Tools: no mundo do DevOps, houve uma explosão de ferramentas 
em release, por exemplo (Jenkins e Teamcity), gerenciamento de configuração 
14
15
(Fantoche e Chef), orquestração (Zookeeper e Noah), monitoramento, virtuali-
zação e contêiner (OpenStack, Docker e AWS).
Há 3 grandes áreas para a aplicação do DevOps:
• Automação de infraestrutura: crie sistemas, configurações de sistema opera-
cional e implantações de aplicativos como código;
• Entrega contínua: crie, teste, implante aplicativos de maneira rápida e auto-
matizada;
• Engenharia de confiabilidade do local: opere sistemas, monitore e orques-
tre, mas também projete a operacionalidade em primeiro lugar.
Para que DevOps funcione, é necessário que alguns pilares estejam bem assen-
tados na organização:
• Colaboração: desenvolvimento de sistemas e sustentação trabalham juntas. 
Embora a desconexão entre esses dois grupos tenha sido o ímpeto para sua 
criação, o DevOps se estende muito além da organização de TI, porque a 
necessidade de colaboração se estende a todos os interessados na entrega de 
software, não apenas entre desenvolvedores e operadores, mas todas as equi-
pes, incluindo teste, gerenciamento de produtos e executivos;
• Automação: o DevOps depende muito da automação, ele conta com cadeias 
de ferramentas para automatizar grandes partes do processo de desenvolvi-
mento e implantação de software de ponta a ponta;
• Integração Contínua: é um princípio fundamental da abordagem do Ágil, 
uma técnica projetada e nomeada por Grady Booch, que mescla continua-
mente as atualizações de código-fonte de todos os desenvolvedores de uma 
equipe em uma linha principal compartilhada. Essa fusão contínua impede que 
a cópia local de um projeto de software de um desenvolvedor vá muito longe, 
à medida que novos códigos são adicionados por outras pessoas, evitando 
conflitos catastróficos de mesclagem. O princípio de integração contínua do 
desenvolvimento ágil tem uma implicação cultural para o grupo de desenvol-
vimento. Forçar os desenvolvedores a integrar seu trabalho com o trabalho de 
outros desenvolvedores com frequência, pelo menos diariamente, expõe pro-
blemas e conflitos de integração muito antes do que ocorre no desenvolvimen-
to em cascata. No entanto, para alcançar esse benefício, os desenvolvedores 
precisam se comunicar com muito mais frequência, um processo que contraria 
a imagem do codificador genial solitário, trabalhando por semanas ou meses 
em um módulo antes de estar “pronto” para enviá-lo. Processos de engenharia 
de software como o XP têm práticas como a programação em pares, releases
contínuas e código coletivo que enfatizam, reforçam, e criam a cultura necessá-
ria para que a integração contínua deixe de ser um problema de egos e passe 
a ser algo natural e orgânico;
• Teste Contínuo: não é apenas uma função de controle de qualidade; de 
fato, começa no ambiente de desenvolvimento. Acabaram os dias em que os 
15
UNIDADE Controle e Entrega de Software
desenvolvedores poderiam simplesmente lançar o código por cima do muro 
para o controle de qualidade e “lavar as mãos”. Em um ambiente de DevOps, 
a qualidade é tarefa de todos. Os desenvolvedores criam qualidade no código e 
fornecem conjuntos de dados de teste. Os engenheiros de controle de qualida-
de configuram os casos de teste de automação e o ambiente de teste. Na ver-
dade, é interessante quando analisamos que o teste contínuo cria um sistema 
central de decisão que ajuda a avaliar o risco comercial que cada aplicativo 
apresenta para a empresa. Aplicado de forma consistente, orienta as equipes 
de desenvolvimento para atender às expectativas dos negócios e fornece visi-
bilidade aos gerentes para tomar decisões, a fim de otimizar o valor comercial 
de um software candidato a lançamento;
• Entrega Contínua: uma prática de desenvolvimento de software na qual as 
alterações de código são criadas, testadas e preparadas automaticamente para 
uma liberação para produção. Ou seja, implantam-se todas as alterações de 
códigoem um ambiente de teste ou em um ambiente de produção após o está-
gio de construção. Quando a entrega contínua é implementada corretamente, 
os desenvolvedores sempre terão um artefato de construção pronto para im-
plementação que passou por um processo de teste padronizado. A frequência 
real de lançamento pode variar bastante, dependendo do legado e das metas 
da empresa. O que é lançado varia também, algumas organizações classificam 
as liberações em potencial: muitas vão diretamente para os usuários, outras 
voltam para o desenvolvimento e algumas simplesmente não são implanta-
das. Outras organizações enviam tudo o que vem dos desenvolvedores aos 
usuários e contam com monitoramento em tempo real e correção rápida para 
minimizar o impacto da falha rara. E é importante observar que, como cada 
atualização é menor, a chance de qualquer uma delas causar uma falha é sig-
nificativamente reduzida;
• Monitoramento Contínuo: não há como implementar o tipo de teste rigoroso 
de pré-lançamento normalmente exigido nas abordagens de desenvolvimento 
em cascata. Em um ambiente DevOps, as falhas devem ser encontradas e 
corrigidas em tempo real. O monitoramento contínuo ajuda a identificar as 
causas principais dos problemas rapidamente, para prevenir proativamente 
as interrupções e minimizar os problemas do usuário. Alguns especialistas 
em monitoramento até defendem que a definição de um serviço deve incluir o 
monitoramento – eles o veem como parte integrante da prestação do serviço. 
Há 2 tipos, o monitoramento de servidor e o monitoramento de desempenho 
de aplicativos. As discussões sobre monitoramento rapidamente se resumem 
às ferramentas, porque não há monitoramento eficaz sem as ferramentas ade-
quadas em DevOps. Aliás, você já deve ter percebido que nada sobre DevOps 
é manual, tem que ser tudo automatizado e isso é levado ao extremo com o 
menor nível de intervenção manual possível, pois daí deixaria de ser DevOps.
DevOps no Brasil ainda é um terreno incipiente, excetuando-se as empresas 
transnacionais, cujas matrizes na Europa, América do Norte e Ásia fazem com que 
nós o utilizemos em suas filiais. O restante é realmente um punhado de gente bem 
16
17
intencionada e esforçada tentando implementar DevOps sem ferramental adequa-
do, sem capacitação adequada, sem liderança com experiência suficiente nesse tipo 
de processo, tendo que contratar inúmeras empresas de consultoria que “sabem 
tudo” e produzem um resultado pífio, fazendo com que muitas iniciativas e projetos 
acabem sendo cancelados. Sim, DevOps exige pessoal sênior, experiente e prepa-
rado, caso contrário, torna-se um fiasco. Fora isso, a grande maioria dos orçamen-
tos da área de TI das empresas está emagrecendo, o que é contraditório, pois as 
empresas precisam de TI em níveis cada vez mais críticos. Como tudo em nosso 
país, temos ao menos mais uns 5 anos pela frente para que DevOps se transforme 
em algo mais rotineiro e estratégico nas empresas brasileiras. 
Oferecemos para sua leitura esse case Fedtech: GOLDSTEIN, P. Como a Fannie Mae usou o 
DevOps para melhorar suas operações de TI. 2016. Disponível em: http://bit.ly/39xN1OlEx
pl
or
Está em inglês, a língua mãe da tecnologia da informação, todavia, com as faci-
lidades do Google Tradutor, você conseguirá ler em português sem muito esforço. 
Mas recomendamos fortemente que você se matricule em algum curso de inglês 
e aprenda com a máxima urgência possível. Trata-se, caso você não saiba inglês, 
de uma questão de sobrevivência no mercado e de um conselho profissional. Fique 
atento(a), o mundo fala inglês!
Visão geral do ciclo DevOps: http://bit.ly/2vO3CyE 
Ex
pl
or
• Build (Construir): nesta fase do DevOps, o desenvolvimento de software é 
constantemente realizado. Todo o processo de desenvolvimento é dividido em 
pequenos ciclos de desenvolvimento. Isso beneficia a equipe do DevOps para 
acelerar o processo de desenvolvimento e entrega de software;
• Test (Teste): a equipe de controle de qualidade usa ferramentas para identifi-
car e corrigir erros no novo código;
• Release (Versão): nesta fase, a nova funcionalidade é integrada ao código 
existente e os testes são realizados. O desenvolvimento contínuo só é possível 
devido à integração e testes contínuos; 
• Deploy (Implantar): nesta fase, o processo de implementação ocorre conti-
nuamente. Isso é feito de forma que qualquer alteração ocorrida em qualquer 
momento no código não afete a operação do site de alto tráfego; 
• Operate (Operar): nesta fase, a equipe operacional será responsável pelo com-
portamento inadequado do sistema ou pelos erros encontrados na produção;
• Monitor (Monitoramento): nesta fase, são avaliados os indicadores de produ-
tividade e de desempenho.
Fonte: Traduzido e adpatado de CHAVES, G. DevOps, “El ciclo sin fin”. Disponível em: http://bit.ly/2SCx2rs
17
UNIDADE Controle e Entrega de Software
Integração Contínua
É a prática de automatizar a integração de alterações de código de vários con-
tribuidores em um único projeto de software. O processo é composto por ferra-
mentas automáticas que afirmam a correção do novo código antes da integração. 
Um sistema de controle de versão do código-fonte é o ponto crucial do processo. 
O sistema de controle de versão também é complementado com outras verifica-
ções, como testes automatizados de qualidade de código, ferramentas de revisão de 
estilo de sintaxe, entre outras necessidades.
Sem integração contínua, os desenvolvedores devem coordenar e se comunicar 
manualmente quando contribuem com código para o produto final. Essa coordena-
ção se estende além das equipes de desenvolvimento até o restante da organização. 
As equipes de produto devem coordenar quando iniciar sequencialmente os recur-
sos e correções, e definir quais membros da equipe serão responsáveis.
Exemplo de Processo de Integração Contínua: http://bit.ly/398iVAE
Ex
pl
or
O processo de Integração Contínua inicia-se sempre que um programador 
concluir o desenvolvimento de uma funcionalidade (chamado de história na me-
todologia de Desenvolvimento Ágil Scrum) e submete o código ao repositório da 
aplicação (processo commit). Neste momento, testes unitários são executados auto-
maticamente por alguma ferramenta de automação (como o Jenkins) para garantir 
que não haja erros no código. Testes unitários são aqueles que validam uma funcio-
nalidade isolada de uma aplicação sem considerar outras partes que eventualmente 
estão relacionadas. Servem para validar a menor parte testável de uma aplicação. 
Os testes unitários são fundamentais para a Integração Contínua e devem ideal-
mente ser criados com base na metodologia TDD (Test Driven Development/
Desenvolvimento orientado a teste), que é uma metodologia em que se deve iniciar 
a programação com a codificação de um teste que valide a funcionalidade plane-
jada. Em seguida, testes de integração devem ser aplicados automaticamente para 
validar se o novo código não irá comprometer o restante da aplicação. Esses testes 
devem ser criados sempre que um novo código precisar se relacionar com outras 
partes da aplicação. Para aplicações que usam linguagens que precisam ser compi-
ladas, o novo código é antes compilado (processo build) automaticamente e dispo-
nibilizado em um servidor (comumente chamado de servidor de integração ou de 
desenvolvimento) onde são executados os testes de integração. Como o processo 
de Integração Contínua deve ser contínuo, caso o servidor de integração não esteja 
disponível, ele deverá ser criado automaticamente durante o processo de validação. 
O desenvolvedor recebe notificações sobre o sucesso ou não das validações. Ele 
deve idealmente submeter seu código pelo menos duas vezes ao dia ao processo de 
Integração Contínua para não correr o risco de perder tempo desenvolvendo um 
código que possa conflitar com o restante já criado (DIAS, 2017. p. 2 e 3). 
18
19
Integração, implantação e entrega contínuas são três fases de um pipeline de 
lançamento de software automatizado. Essastrês fases levam o software da ideia à 
entrega ao usuário final. A fase de integração é a primeira etapa do processo. A in-
tegração abrange o processo de vários desenvolvedores que tentam mesclar suas 
alterações de código com o repositório de código mestre de um projeto.
Continuous Integration
Continuous Delivery
Continuous Deployment
Auto Auto Auto
Auto Auto Auto
Auto Auto Auto Auto
Manual
Build Unit Tests
Deploy to
stage
Deploy to
stage
Deploy to
stage
Build Unit Tests
Build Unit Tests
Acceptance
Tests
Acceptance
Tests
Acceptance
Tests
Deploy to
production
Deploy to
production
Figura 4 – Processos Continuous Integration (Integração Contínua), 
Continuous Delivery (Entrega Contínua) e Continuous Deployment (Implantação Contínua)
A implantação contínua (continuous deployment) não se aplica a toda empresa. 
Foi pensada principalmente, mas não exclusivamente, para o desenvolvimento de 
aplicações para web. Há, muitas vezes, regras de governança rígidas e necessidade 
de testes manuais que impedem o uso dessa metodologia. Mas se recomenda às 
empresas que tenham a possibilidade que tentem aplicá-la porque promove mudan-
ças positivas e profundas na organização. Como o programador tem capacidade 
de colocar suas alterações em produção de forma autônoma, ele passa a ser mais 
preocupado com questões de qualidade e confiabilidade. Com pequenas mudanças 
disponíveis constantemente em produção, a empresa passa a receber feedbacks
pontuais e realistas de seus clientes e, assim, pode determinar o valor agregado e 
decidir se deve investir mais na nova funcionalidade. Implantação contínua deve 
incorporar ferramentas de monitoramento no ambiente de produção para certificar 
como as alterações influenciaram o uso de recurso. Métricas como quantidade de 
acesso, volume de tráfego, tempo de resposta, uso de recursos e outras devem ser 
monitoradas automaticamente.” (DIAS, 2017. p. 2 e 3).
DIAS, R.R. Diferenças entre integração, entrega e implantação contínua (2017. p. 2 e 3) 
Disponível em: http://bit.ly/2SBsscQEx
pl
or
19
UNIDADE Controle e Entrega de Software
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
DevOps // Dicionário do Programador
https://youtu.be/iwf6kcvxeD4
Palestra de Integração e Entrega Contínua no Workshop práticas DevOps
https://youtu.be/415ABfs_WX4
Engenharia de Software - Lidando com mudanças
https://youtu.be/vzCwfhHaiV0
 Leitura
Da Balbúrdia ao Ágil: Estudo de Caso de Resistência à Mudança ao Adotar o Scrum em Equipes de 
Desenvolvimento de Software
http://bit.ly/38omenw
20
21
Referências
BRIGHT HUB MEDIA. O que você faz com as solicitações de mudança no 
desenvolvimento de projetos de software: o processo de manipulação. 2009. 
Disponível em: <https://www.brighthubpm.com/change-management/5737-chan-
ge-management-in-software-development-projects/>. Acesso em: 12/12/19.
DIAS, R. R. Diferenças entre integração, entrega e implantação contínua.
2017. p. 2 e 3.
JAYATILLEKE, S.; LAI, R. Uma revisão sistemática do gerenciamento de altera-
ções de requisitos. 2018. p. 172. Disponível em: <https://www.sciencedirect.com/
science/article/pii/S0950584917304664#fig0001>. Acesso em: 10/12/2019
MUELLER, E. O que é o DevOps? 2010. Disponível em: <https://theagileadmin.
com/what-is-devops/>. Acesso em: 9/12/2019.
21