Apostila - Módulo 4 - Bootcamp Engenheiro de Software Ágil

Prévia do material em texto

Implementação, Testes e Qualidade de Software no 
CVDS Ágil 
 
 
Bootcamp Engenheiro de Software Ágil 
 
 
 
 
Albert Tanure 
 
 
 
 
 
2021 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 2 de 45 
 
Implementação, Testes e Qualidade de Software no CVDS Ágil 
Bootcamp Engenheiro de Software Ágil 
Albert Tanure 
© Copyright do Instituto de Gestão e Tecnologia da Informação. 
Todos os direitos reservados. 
 
 
 
 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 3 de 45 
Sumário 
Capítulo 1. Processos e cultura ............................................................................. 5 
MPS.BR .................................................................................................................. 6 
Níveis .................................................................................................................. 7 
Modelos de referência ......................................................................................... 8 
Cultura .................................................................................................................... 9 
Capítulo 2. Repositórios ...................................................................................... 12 
Tipos de repositórios ............................................................................................. 12 
Branches ............................................................................................................... 13 
Capítulo 3. CI – Continuous Integration ............................................................... 16 
Estrutura de um CI ................................................................................................ 16 
Ferramentas .......................................................................................................... 19 
Capítulo 4. CD – Continuous Deployment/Delivery ............................................. 21 
Estratégias de deployment.................................................................................... 22 
Ferramentas .......................................................................................................... 23 
Capítulo 5. Qualidade .......................................................................................... 25 
Testes de Unidade ................................................................................................ 25 
TDD – Test Driven Development .......................................................................... 27 
Análise estática de códigos................................................................................... 29 
Segurança............................................................................................................. 31 
Checagem de vulnerabilidades de desenvolvimento ........................................ 31 
Vulnerabilidade de pacotes ............................................................................... 31 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 4 de 45 
Pirâmide de testes ................................................................................................ 32 
Capítulo 6. Gestão de mudanças ........................................................................ 34 
Configurações ....................................................................................................... 34 
Feature Toggles .................................................................................................... 36 
Wiki ....................................................................................................................... 38 
Capítulo 7. Monitoramento .................................................................................. 41 
Log ........................................................................................................................ 42 
Alertas ................................................................................................................... 44 
Referências............... ............................................................................................... 45 
 
 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 5 de 45 
Capítulo 1. Processos e cultura 
Para todo tipo de trabalho ou ações, são necessários processos. Este é um 
recurso poderoso em todas as organizações para atingirem seus objetivos mantendo 
um bom planejamento, previsibilidade e, além disso, qualidade nos serviços que são 
prestados. 
Durante muito tempo, os processos eram vistos, nas empresas que 
desenvolvem software, como uma burocracia desnecessária, cheia de imposições e 
documentos que só aumentava a complexidade do que deveria ser feito e entregue. 
De certa forma, esta insatisfação por parte dos colaboradores e também dos parceiros 
e clientes não era inválida. Os mecanismos utilizados para desenvolver softwares 
dentro de um escopo para proporcionar a “entrega perfeita” no melhor prazo e custo 
(lucro para a empresa), criaram o que eu chamo de disfunções burocráticas. Neste 
caso, a burocracia não é algo ruim e sim um direcionador do que deve ser feito, um 
processo, enquanto a disfunção desta burocracia é, justamente, o mal-uso dos 
processos, o grande desperdício de esforço para se atingir um objetivo. 
Processos no estilo waterfall tinham esta característica, de ser uma “boa 
burocracia”. No entanto, era utilizado para justificar os custos e os desperdícios e, 
além disso, as organizações passaram a atender aos parceiros e clientes orientados 
para o que se estava “escrito em uma pedra”, ou seja, não pode mudar, caso contrário 
gera custo e retrabalho. 
Mas vivemos em um cenário onde a grande estrela são nossos clientes e 
parceiros e, de fato, o mercado exige cada vez mais tecnologias de ponta para 
suportar a grande demanda e, além disso, exige-se adaptabilidade. Isso nos diz que 
as mudanças podem e devem acontecer mais rapidamente, levando em consideração 
os desejos e anseios dos que serão beneficiados com nossas soluções. 
Então, projetos e entregas que eram desenvolvidas em um Lead Time maior 
que 6 meses ou 1 ano, agora foram reduzidos para 2, 3 meses ou simplesmente 
semanas. Do ponto da definição da necessidade até a entrega de alguma versão da 
mesma, ou o famoso MVP (Minimum Valluable Product – mínimo produto viável), há 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 6 de 45 
apenas algumas semanas entre a preparação, desenvolvimento e entrega de um 
produto. Caso contrário, o Time do mercado pode ser perdido, jogando todo o 
investimento, ideias e estratégias no lixo. 
Então, quais seriam as estratégias para que as organizações possam atender 
às crescentes demandas e entregar mais e constantemente com a melhor qualidade? 
Além disso, como ser tão ágil? 
Neste caso, não há outra solução a não ser na adoção de um bom processo 
e também de uma cultura colaborativa e direcionada para a experiência dos clientes 
e parceiros, utilizando a boa burocracia. 
 
MPS.BR 
O MPS.BR é um processo suportado pela Softex e que tem o apoio do 
Ministério da Ciência e da Tecnologia, Inovações e Comunicações. Este processo 
tem como objetivo a melhoria na capacidade de desenvolvimento de soluções de 
software, serviços e também de gestão de RH. 
É, então, uma definição de processos visando as melhores práticas em 
diversos níveis a serem adotados em uma organização. Quanto maior o nível uma 
organização obtiver, mais maturidade ela possui para a entrega de soluções. 
Este é um ponto importante. O MSP.BR não é somente um direcionador. 
Através das diretrizes e direcionamentos impostos pelo programa, a empresa tem 
condições de ser certificada com um selo ou nível atestado por este programa. Isso 
significa que, ao cumprir determinados requisitos, uma empresa poderá receber um 
selo MPS.BR de acordo com o nível de requisitos,maturidade alcançada, atestando-
a não somente como uma boa opção para o fornecimento de determinados serviços, 
como ajudando-a a ter uma boa organização. Isso é um grande diferencial. Em um 
mercado tão concorrido, com tantas ofertas de fornecedores, quais seriam os mais 
indicados e confiáveis para atender a demandas de um parceiro ou cliente? Aqueles 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 7 de 45 
que possuem mais maturidade. Então associa-se o MPS.BR a uma certificação para 
a empresa, assim como já era feito para as “certificações CMMI”. 
O que é interessante é que as empresas avaliadas e que possuem o selo de 
qualidade do MPS.BR, juntamente com o seu nível, são disponibilizadas no site do 
programa, atestando a confiança. 
Níveis 
O MPS.BR possui 7 níveis e a figura 1 exibe uma comparação com os níveis 
do CMMI: 
Figura 1 – Comparativo entre MPS.BR e o CMMI. 
 
De acordo com a comparação, existe uma maior granularidade dos requisitos 
para cada nível do CMMI. Desta forma, uma organização poderá focar seus esforços 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 8 de 45 
em determinados níveis e dominar completamente tal nível aumentando a maturidade 
e diminuindo a complexidade do foco. Fazer bem e direito. Quanto maior o nível, mais 
maturidade a empresa possui. Neste caso, o maior nível de maturidade é o nível A e 
o menor nível o G. 
Figura 2 - Detalhamento dos níveis disponíveis. 
 
Fonte: https://promovesolucoes.com/quais-sao-os-niveis-de-maturidade-do-mps-br/. 
Modelos de referência 
O MPS.BR possui 3 modelos de referência: 
 MPSBR SW – Modelo para Software. 
 MPSBR SV – Modelo para Serviços. 
 MPSBR RH – Modelo para gestão de pessoas. 
https://promovesolucoes.com/quais-sao-os-niveis-de-maturidade-do-mps-br/
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 9 de 45 
Cada modelo possui seus respectivos requisitos e uma organização poderá 
se adequar a quaisquer um destes, de acordo com seu segmento e objetivos. 
Obter uma certificação ou um selo, seja o CMMI ou MPS.BR, é muito 
importante com relação à visão da empresa para o mercado e também é um ótimo 
ponto de partida para um nível de maturidade sem a necessidade de reinventar a 
roda. Processos são bons, importantes e, bem aplicados, ajudam a obter resultados 
excepcionais. 
 
Cultura 
Hoje é praticamente impossível não associar cultura ao termo DevOps. Já faz 
parte de um jargão. E por quê? Inicialmente talvez o mercado entendia o termo 
DevOps sendo como a “união entre dois times distintos, Dev + Ops”, não deixa de ser 
uma verdade, e também uma forte associação às ferramentas. Contudo, nada vai 
funcionar sem as pessoas, e outro termo muito utilizado para definir DevOps é: “A 
união entre pessoas, processos e ferramentas”. Esta união tem como objetivo gerar 
uma cultura para a entrega de valor constante, utilizando várias outras técnicas, mas 
sem as pessoas, parte fundamental, nada disso funciona. 
Figura 3 – Etapas do DevOps. 
 
Fonte: https://docs.microsoft.com/en-us/azure/devops/learn/what-is-devops. 
https://docs.microsoft.com/en-us/azure/devops/learn/what-is-devops
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 10 de 45 
A figura 3 demonstra, de forma resumida, as etapas relacionadas ao DevOps. 
É uma cultura colaborativa e incremental. Geralmente são etapas associadas apenas 
às práticas de desenvolvimento de código, mas seu conceito vai muito além. 
Entretanto, temos: 
 Plan – Nesta etapa, configura-se o planejamento dos objetivos a serem 
atingidos diante de uma necessidade. O planejamento está associado ao 
processo de uma organização e pode mudar constantemente, isso é normal. A 
cada entrega, um novo planejamento poderá ser criado com base nos 
resultados obtidos. 
 Build – Este é o momento de construção de alguma necessidade ou produto. 
Geralmente está relacionado ao desenvolvimento do software propriamente 
dito. Após planejar, é hora de desenvolver e atender aos objetivos definidos. A 
participação ativa de todo o time, independentemente de suas disciplinas, é de 
extrema importância. 
 Continuous Integration – Nesta etapa, acontece a primeira automatização 
para a construção do produto. Esta automatização será executada durante 
todo o ciclo de desenvolvimento, build. Os processos executados nesta etapa 
são basicamente a construção da aplicação, execução de testes e preparação 
de uma versão da aplicação. As etapas podem variar de aplicação para 
aplicação e também de acordo com a organização. O importante é que este é 
um processo que traz feedbacks constantes e facilita a resolução de problemas 
rapidamente. 
 Deploy (Continuous Deploy) – Também é um processo automatizado e 
executado, geralmente, após o Continuous Integration. Este processo não 
necessariamente obtém o pacote e efetua sua publicação em um ambiente, 
como também pode executar alguns outros processos, como obtenção de 
aprovação pelos responsáveis do produto ou até mesmo aplicar validações de 
segurança ou testes de integrações. 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 11 de 45 
 Operate – O que foi construído precisa de ser publicado em algum ambiente 
e, além disso, ser mantido e monitorado. Esta é a etapa que possui este 
objetivo. Geralmente associada ao time de infraestrutura ou ops, porém hoje, 
com a integração entre as pessoas e os times, este papel é distribuído entre 
diversas áreas. Alguns pontos são especificamente relacionados à equipe de 
ops, contudo, o objetivo aqui é manter, monitorar, evoluir e responder aos 
processos e mudanças relacionadas ao produto. 
 Continuous Feedback – Esta etapa não é executada somente após a 
aplicação ser publicada em algum ambiente. Os feedbacks são constantes 
durante todo o clico. Quantidade de tarefas a fazer, target do sprit, builds que 
falharam, problemas em ambientes, entre vários outros insumos que 
direcionam decisões e planos de ação. 
Como podemos observar, a cada interação temos a execução de 
praticamente todo o processo e ele afeta não apenas o produto, mas toda a 
organização, afinal aplica-se aqui a melhoria constante, trazendo mais maturidade e 
envolvimento das pessoas, gerando, finalmente, uma cultura colaborativa para 
entrega constante de valor. 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 12 de 45 
Capítulo 2. Repositórios 
Parte fundamental de todo o ciclo de desenvolvimento, os repositórios muitas 
vezes não são totalmente compreendidos, limitando o seu conceito em apenas um 
local para fazer o backup do código fonte. 
Neste caso, os repositórios são parte essenciais em todo o processo. Claro, 
o gerenciamento do código-fonte é uma de suas funções. Mas mais do que isso, os 
repositórios nos ajudam a organizar o desenvolvimento dos produtos entre as 
diversas equipes, nos proporciona a rastreabilidade, auditoria de tudo o que acontece 
durante o desenvolvimento, entre outros benefícios. 
 
Tipos de repositórios 
Existem, basicamente, dois tipos de repositórios – Centralizados e 
Descentralizados. 
 Centralizados – Todo repositório necessita de um servidor central para 
integrar o trabalho de toda equipe. No entanto, repositórios centralizados 
possui alguns benefícios e algumas características de permitir com que o 
trabalho possa ser feito somente on-line. Isso quer dizer que não é possível 
trabalhar em uma aplicação caso o servidor não esteja conectado por algum 
momento. Devido a funcionalidades como bloquear arquivos, sem esta 
conexão não é possível garantir este recurso. Além disso, podem haver perdas 
de código ou até mesmo uma grande complexidade de merge, dificultando até 
a rastreabilidade do trabalho. Contudo, são tipos de repositórios robustos que 
podem trabalhar com arquivos binários de forma eficiente. Um exemplo de 
repositório centralizadoé o Team Foundation Version Control. 
 Descentralizados – Repositórios descentralizados possuem, é claro, um 
servidor central. Contudo, todo o processo que é feito de forma conectada, 
pode ser feito localmente, na máquina do desenvolvedor. Isso porque nesta 
abordagem, todos os processos executados em um repositório podem ser 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 13 de 45 
executados localmente, como um servidor central. O melhor exemplo de 
repositório descentralizado é o Git. É muito rápido, porém não é o mais 
indicado para se trabalhar com arquivos binários ou arquivos muito grandes, 
apesar de haver configurações específicas para estes cenários. 
 
Branches 
Independentemente do tipo de repositório, uma técnica muito utilizada para 
garantir o melhor gerenciamento das versões do código-fonte são os branches. De 
forma simples, são similares a copiar o código-fonte da sua pasta corrente para uma 
outra pasta com outro nome. Dessa forma, você consegue trabalhar de forma segura 
nessa “nova pasta” sem afetar o código original, podendo ignorar o novo código a 
qualquer momento ou, posteriormente, reintegrá-lo ao código original, executando o 
famoso processo de merge. 
Todo repositório possui pelo menos um branch. Hoje, a primeira branch em 
um repositório é chamada de main. Até poucos meses atrás, era chamada de master. 
Mas já imaginou vários membros de um time atuando na mesma branch? 
Novos códigos, manutenções, correção de bugs urgentes? É algo complexo de se 
gerenciar e, por isso, se faz necessário ter uma boa estratégia de branches para 
melhorar o gerenciamento do seu código. 
A definição da melhor estratégia vai depender do cenário de uma 
organização, mas recomenda-se utilizar referências como um ponto de partida. 
Uma ótima opção é a utilização do GitFlow. 
 
 
 
 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 14 de 45 
Figura 4 – Git Flow. 
 
Fonte: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow. 
O GitFlow possui um fluxo bem definido para trabalhar com diversas 
necessidades no ciclo de desenvolvimento, como por exemplo, o uso de feature-
branches. As feature-branches são criadas por funcionalidade, contextualizando o 
desenvolvimento, facilitando o gerenciamento e diminuição de problemas com merge 
na reintegração com a branch principal. 
Outra estratégia muito utilizada, porém, acompanhada de outras técnicas, é 
a chamada de Trunk Based. É justamente o uso de um e apenas um branch, 
remetendo aos problemas relatados anteriormente. Contudo, esta estratégia não 
impede a criação de outros branches, desde que estes possuam um curto ciclo de 
vida. 
 
 
 
 
 
 
 
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 15 de 45 
Figura 5 – Trunk Based. 
 
Fonte: https://trunkbaseddevelopment.com/. 
Esta é uma outra opção para equipes mais maduras, mas deve ser utilizada 
com outras técnicas, justamente para permitir com que não haja problemas com a 
evolução dos vários contextos de desenvolvimento no mesmo branch. 
https://trunkbaseddevelopment.com/
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 16 de 45 
Capítulo 3. CI – Continuous Integration 
Continuous Integration ou integração contínua (CI) é o processo 
automatizado para a construção de uma aplicação sempre que um membro da equipe 
submete alterações para o servidor de controle de versão. A submissão de um novo 
código para o repositório dispara a ação automatizada que executa algumas tarefas 
para construção e também para a validação de qualidade do que foi desenvolvido. 
A CI surgiu como uma prática recomendada porque os desenvolvedores de 
software geralmente trabalham isolados e, então, precisam integrar suas alterações 
no repositório. A não integração constante de códigos pode gerar vários problemas, 
entre eles a execução de merges complexos. 
O uso do CI é muito poderoso em equipes que trabalham com estratégias de 
branches, permitindo a utilização de boas práticas, como o Code Review, através de 
Pull Requests. Um desenvolvedor envia uma “Pull request” quando uma feature ou 
correção de bug é concluída e, após a análise do código (Code Revirew) para a 
adequação dos parâmetros de qualidade de desenvolvimento, acontece a aprovação 
e então as alterações são mescladas no branch master/main. 
O uso constante do CI em conjunto com a poderosa ferramenta do Code 
Review proporciona feedbacks rápidos e constante para toda a equipe de 
desenvolvimento, evitando ações tardias somente em ambientes produtivos. 
 
Estrutura de um CI 
Conforme mencionado anteriormente, o CI é um processo automatizado 
composto por tarefas que são executadas sequencialmente. A configuração do script 
de automatização vai depender de ferramenta para ferramenta. 
Uma boa prática, neste caso, é optar por ferramentas que sejam extensíveis, 
ou seja, permitem a instalação de novas funcionalidades para a criação do CI. Deve-
se levar em consideração também o uso de ferramentas que permitem a criação de 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 17 de 45 
scripts que podem ser versionados, afinal de contas, o processo de automatização 
deve possuir governança. Geralmente os scripts são versionados no mesmo 
repositório de código-fonte da aplicação em que o CI será executado. 
Também conhecido como Pipeline, o CI é altamente customizável, permitindo 
a adição ou remoção de tarefas de acordo com a necessidade da aplicação. 
Figura 6 – Script de CI no Azure DevOps. 
 
A Figura 6 demonstra um script e CI criado no padrão YML e utilizado no 
Azure DevOps. 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 18 de 45 
Os arquivos YML possuem uma hierarquia baseada na indentação, ou seja, 
a forma que está organizada uma propriedade define qual o seu contexto. Por 
exemplo, observe na Figura 6 as linhas 25 a 32. Neste caso, temos uma tarefa que 
executa a geração de um artefato publicável da aplicação. As propriedades 
displayName e inputs são “filhas” desta task, enquanto as propriedades definidas 
nas linhas 28 a 32 são “filhas” de input. No entanto, este é um arquivo legível e pode 
ser versionado. 
A linha 6 representa a ação que dispara o CI, ou seja, qualquer atualização 
de código na branch main irá disparar a execução do fluxo de integração contínua. 
Ao ser executado, este pipeline tentará construir a aplicação levando em 
consideração as tarefas e caso haja algum problema, o fluxo será interrompido, 
conforme é exibido na Figura 7: 
Figura 7 – CI em execução. 
 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 19 de 45 
No exemplo acima, o CI foi executado, mas houve uma falha no processo de 
compilação, ou seja, existe um bug no código. Logo após esta execução, uma 
notificação poderá ser disparada ao time de desenvolvimento fazendo com que a 
ação de correção aconteça imediatamente. 
Neste processo, é importante haver outras tarefas como a execução de testes 
de unidade e análise estática de código. Com base no resultado destas execuções, 
informações, como cobertura de testes e vulnerabilidades, podem fazer com que o CI 
seja interrompido direcionando o time a desenvolver com mais qualidade, evitando 
submeter aos ambientes uma aplicação defeituosa. Isso gera um grande desperdício. 
O CI é a tradução de um processo que já foi executado por nós 
desenvolvedores de forma manual. 
 
Ferramentas 
Existem diversas ferramentas para se trabalhar com o CI, como: 
 Jenkins; 
 Azure DevOps; 
 Circle CI; 
 Git Lab; 
 Bit Bucket; 
 Git Actions; 
 Etc. 
As mais utilizadas são o Jenkins e o Azure DevOps e, mais recentemente, o 
Git Actions. 
 
 
 Implementação, Testes e Qualidade de Software no CVDSÁgil – Página 20 de 45 
Vai depender da necessidade da organização. Uma ótima opção seria o uso 
do Azure DevOps, por já conter os principais grupos relacionados ao DevOps. Através 
desta ferramenta, podemos gerenciar, controlar os repositórios, implementar 
pipelines de CI e de CD, garantir qualidade e compartilhar recursos. É uma ferramenta 
muito completa e extensível e, além disso, não está limitada a somente tecnologia 
Microsoft. 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 21 de 45 
Capítulo 4. CD – Continuous Deployment/Delivery 
A entrega contínua, continuous deployment/delivery (CD), é também um 
processo automatizado que geralmente executa posteriormente a um build. Tem 
como objetivo principal a promoção de artefatos de software entre diversos 
ambientes. 
Figura 8 – CD - Continuous deployment/delivery. 
 
Conforme demonstrado na Figura 8, após a geração de um artefato bem-
sucedido através do processo de CI, é então disparada uma trigger para a promoção 
deste artefato para ambientes distintos. É neste caso que temos a diferença sutil entre 
deployment e delivery. 
Basicamente, o conceito de deployment está associado à publicação de 
novas versões da aplicação em todos os ambientes, inclusive o ambiente produtivo, 
automaticamente. Para isso, é claro, exige-se um alto nível de maturidade do time e 
do processo, afinal de contas, no momento em que um desenvolvedor faz uma 
integração, esta poderá ser submetida diretamente ao usuário final. Neste caso, é 
muito importante ter uma boa cobertura de testes e análise estática de códigos, além 
do monitoramento para proporcionar essa submissão automática. Este é o nível de 
independência que toda organização deseja estar. 
O delivery tem as mesmas características mencionadas acima, inclusive as 
relacionadas à qualidade. No entanto, é um processo feito e forma assistida, ou seja, 
depende de um ou mais aprovadores, no caso, para permitir que uma nova versão 
seja submetida para produção. Demanda um pouco mais de planejamento e, apesar 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 22 de 45 
da ação de aprovação ser manual, ao concedê-la, a execução do deployment é feito 
de forma automatizada. 
 
Estratégias de deployment 
Tão importante quanto o processo de CD é a estratégia de publicação. Esta 
técnica visa diminuir os transtornos causados aos usuários. Um bom exemplo para 
este cenário é quando você assiste sua série favorita em uma aplicação de streaming. 
Durante a execução do seu vídeo, novas atualizações podem estar sendo feitas em 
background, sem que você perceba. Isso é transparente para o usuário. Então uma 
boa estratégia pode lhe trazer mais segurança ao atualizar recursos em seu produto 
e também trazer mais confidencialidade aos usuários. 
Algumas estratégias de publicação: 
 Blue-Green: uma das estratégias mais utilizadas. Consiste em ter dois 
ambientes, o Blue que encontra-se em execução e o Green,ambiente que 
recebe a nova versão da aplicação. Neste ponto, após a publicação para o 
ambiente Green, podem ser feitos testes para validar a correta execução e 
posteriormente é executada uma ação de Swap que é gerenciada por um Load 
Balance que irá redirecionar as requisições para a nova versão da aplicação, 
fazendo com que a Green seja a principal e a Blue a secundária. 
 A/B test: uma técnica muito interessante onde podem haver publicações de 
novas versões ou até mesmo de possíveis novas funcionalidades e estas 
estarem disponíveis em % para algum conjunto de usuários. É uma técnica 
muito interessante até para fazer pesquisas, coletar dados e impressões para 
tomadas de decisões estratégicas. 
 Canary: um pouco parecido com a estratégia Blug-Green. No entanto, é 
publicada uma nova versão da aplicação e a disponibiliza para uma pequena 
amostragem de usuários para medir se a aplicação se comporta corretamente. 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 23 de 45 
Esta disponibilização é feita através do Load Balance. Se tudo estiver ok, a 
nova verão é liberada. 
 Dark launches: assim como acontece na estratégia A/B teste, a estratégia 
Dark launches pode ser utilizada para acrescentar features, mesmo que em 
fase experimental. Esta atualização é feita de forma sutil e liberada a uma 
amostragem de usuários. Os usuários acessam, mas não tem conhecimento 
de que houve uma atualização. Então, ao descobrirem, passam a utilizar e 
geram vários tipos de dados e informações que permitem com que a 
organização defina estratégias ou até mesmo teste um MVP. 
Existem outras estratégias, mas é importante planejar corretamente a 
submissão de atualizações em outros ambientes de maneiras seguras. 
 
Ferramentas 
Geralmente, as ferramentas que implementam o CI também implementam o 
processo de deployment. Contudo, neste caso, podemos relacionar praticamente as 
mesmas ferramentas disponíveis para o Continuous Integration: 
 Jenkins; 
 Azure DevOps; 
 Circle CI; 
 Git Lab; 
 Bit Bucket; 
 Git Actions; 
 Etc. 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 24 de 45 
Em geral, o script de CD pode variar de ferramenta para ferramenta. Assim 
como no processo de CI, o mais recomendado é a utilização de scripts que podem 
ser versionados. Porém, em ferramentas como o Azure DevOps, há a separação dos 
dois processos, sendo pipeline o CI e releases o CD. Além disso, no Azure DevOps, 
o script de CD é criado de maneira visual e não é versionado no código fonte da 
aplicação, gerando uma dependência. Contudo, essa separação não será continuada 
e, com isso, os processos de CI e CD serão implementados via scripts baseados em 
arquivos YML, com todas as funcionalidades disponíveis hoje, como pré-approvals, 
Gates, etc. 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 25 de 45 
Capítulo 5. Qualidade 
Assim como o processo automatizado é muito importante para trazer 
agilidade ao entregar soluções, o processo de qualidade é essencial. Como sabermos 
que um artefato de software possui qualidade suficiente para ser promovido aos 
ambientes disponíveis, de forma automática? 
Neste caso é necessário criar mecanismos de checagem do trabalho 
efetuado. Tais mecanismos não estão relacionados apenas a testes negociais, mas 
também à qualidade de código, segurança e de carga. 
 
Testes de Unidade 
Um teste de unidade tem como objetivo testar um recurso com uma 
responsabilidade definida para garantir a integridade da implementação. Por 
exemplo, observe a seguinte figura: 
Figura 9 – Exemplo de teste de unidade. 
 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 26 de 45 
Conforme demonstrado na figura acima, temos um teste de unidade com a 
responsabilidade de testar um caso, a divisão de dois valores através do método 
Dividir da classe Calculadora. A unidade testada aqui é o método Dividir e, além disso, 
está sendo testado uma, e somente uma, única responsabilidade deste método. Isso 
é denominado caso de teste, ou seja, o método pode até ter uma implementação mais 
complexa, entretanto, o objetivo aqui é testar um caso onde o método se dispõe a 
fazer o básico, dividir um número. Os inputs podem variar para obter resultados 
diferentes. 
Contudo, esta prática é muito importante não somente para criar uma 
burocracia a mais no desenvolvimento da solução, mas também contribui para uma 
melhor escrita do código e também provê maior segurança ao garantir o que foi 
desenvolvido. Quanto mais testes de unidade aplicados a diversos casos relacionado 
ao contexto desenvolvido, maior a cobertura, maior a qualidade. Por outro lado, a 
existência de muitos testes e uma alta cobertura não garantem completamente que o 
sistema possui uma ótima qualidade. Vai depender do trabalho executado entre a 
equipe de qualidade e de desenvolvimento. Testes sãocódigo, mas se escritos da 
maneira errada, não fazem qualquer sentido, será somente um número a mais. Isso 
significa que posso testar a unidade de uma classe específica com um teste que não 
faz qualquer sentido, a não ser no objetivo de fazer com que o Assert seja executado 
com sucesso e estes são casos de testes viciados. 
Outro ponto importante é que os testes sempre são deixados para o final do 
desenvolvimento e visto, muitas vezes, como perda de tempo ou “algo a mais a ser 
feito” e vamos focar nas funcionalidades. Isso é um grande erro. Sem uma boa 
cobertura de códigos, é impossível garantir a qualidade das aplicações para serem 
distribuídas de forma automatizada e, além disso, os testes devem ser feitos, sim, 
pelo time de Devs durante o desenvolvimento. Não são perda de tempo, mas uma 
prática essencial em uma cultura DevOps. 
 
 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 27 de 45 
TDD – Test Driven Development 
O TDD é uma prática às vezes incompreendida, porém traz muitos benefícios 
no ciclo de desenvolvimento. Apesar do termo estar associado à disciplina de testes, 
é uma estratégia de desenvolvimento, muitas vezes divertida, e que apoia no melhor 
desenho de classes e aplicações de padrão. 
Utilizar o TDD pode ser complexo inicialmente, afinal, como testar o que não 
foi desenvolvido. Contudo, essa é a ideia principal aqui. Evoluir o seu código com 
base “no que pode dar errado”. Isso traz mais consistência no momento do 
desenvolvimento. É uma mudança de visão e, à medida que esta prática é aplicada 
constantemente, é quase impossível voltar a desenvolver alguma coisa sem ela. 
O TDD também auxilia no domínio do problema, já que ao desenvolver 
concentramos em pequenos contextos e seus problemas, com isso aprendemos mais 
sobre as necessidades e, em muitos casos, descobrimos problemas não mapeados. 
Um bom ponto de partida para aplicar o TDD seria na reunião de detalhamento das 
tarefas que serão desenvolvidas pelo time. Aqui é um bom momento para o time 
conjecturar junto com a equipe de qualidade os principais problemas em cada cenário 
e, com isso, gerar casos de testes que possam ser cobertos durante o 
desenvolvimento. 
De forma prática, o TDD funciona da seguinte maneira: 
 Desenvolver; 
 Testar; 
 Falhar; 
 Refatorar. 
Este ciclo se repete a cada interação até se esgotarem todos os casos de 
testes. Conforme demonstrado na figura anterior, o teste de unidade foi feito para um 
método Dividir, que tem como objetivo a divisão de dois valores inteiros. O primeiro 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 28 de 45 
caso encontra-se testado. Mas analisando outro caso, o que poderia trazer problema 
no método? 
Bom, sabemos que não há divisões por zero. E se o valor B (linha 7) for 
alterado para 0, o teste vai falhar. Isso não é algo ruim, mas o indício de que existe 
uma falha na implementação. 
A ação aqui, neste caso, não será implementar a correção imediatamente no 
método Dividir, mas na criação do caso de teste. 
Figura 10 – Teste de divisão por zero. 
 
Criou-se outro caso de teste. O anterior permanece intacto, porque já era um 
caso funcional. Neste novo método, queremos testar a divisão por zero. Ao executar 
os testes, um será executado com sucesso e o outro vai falhar. Calma, normal. É o 
processo do TDD. Agora, o que deve ser esperado aqui? É aí que vem um dos 
grandes benefícios do TDD, refletir orientado a objetos e refatorar. O que deve ser 
aplicado aqui não seria a alteração da assinatura do método, afinal devemos nos 
preocupar com a abstração e encapsulamento. Neste caso, gostaríamos que dois 
valores fossem divididos e esperamos que, caso haja algum problema aqui, neste 
caso, uma exception é esperada. Isso é muito importante porque em muitos casos 
uma provável refatoração para o método seria verificar se o divisor é zero. Se for zero, 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 29 de 45 
então substitui o seu valor para 1. No entanto, o método tomou uma decisão que não 
era de sua responsabilidade. 
Qual será o procedimento? O esperado, neste caso, é uma exceção. 
Figura 11 – Refatorando o teste. 
 
Não houve qualquer alteração específica no código do método Dividir porque 
o próprio compilador lança uma exception caso haja a divisão de algum número por 
zero, contudo, ao executar novamente os testes, todos os métodos passarão. E é 
uma outra característica da implementação de testes com esta prática. Prover 
rastreabilidade e consistência. 
Havendo a necessidade, por exemplo, de alguma alteração em algum 
método, ao executar a análise dos testes, alguns outros podem falhar. Desta forma, 
sabemos exatamente os impactos gerados por alterações e temos a oportunidade 
aqui de novamente refatorar e melhorar a qualidade e cobertura de teste do código 
implementado. 
 
Análise estática de códigos 
Não é somente a nível negocial e funcional que deve ser o foco das nossas 
aplicações. Um ponto muito importante aqui é também a preocupação constante com 
o código que foi desenvolvido. Este código deve aplicar as boas prática de 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 30 de 45 
desenvolvimento, evitando retrabalho e, é claro, mantendo-o livre de quaisquer 
implementações que possam comprometer tanto o funcionamento da solução quanto 
a sua evolução e manutenção. 
Uma boa prática é o uso de ferramentas como o Sonar 
(https://www.sonarqube.org/) ou o NDepend (https://www.ndepend.com/). 
Ambas têm como característica analisar o código desenvolvido, seja durante 
o processo de CI ou durante a codificação. 
Através desta análise, são gerados relatórios contendo informações de bugs, 
vulnerabilidade de segurança, débitos técnicos, cobertura, entre outros indicadores. 
O Sonar, especificamente, possui vários analisadores para diversas linguagens e é 
extensível, permitindo a customização de regras de acordo com os padrões da 
organização. Desta forma, podemos habilitar ou desabilitar quaisquer tipos de 
análises que fazem sentido ao padrão de desenvolvimento da organização. 
Como resultado, é gerado um relatório contendo um valor de Quality Gate 
que está relacionado a uma meta definida para o seu projeto. Assim, se a 
configuração de quality gate for, por exemplo, de 80% e ao executar o processo de 
CI a análise retorne 70%, significa problemas e seu build vai falhar. É uma prática 
muito importante durante o clico de desenvolvimento, contudo, esta meta pode ser 
alimentada gradativamente, começando com valores menores e a cada interação o 
arquiteto e o time podem definir novas metas, nunca menores do que as anteriores. 
Figura 12 – Sonar. 
 
Fonte: https://docs.sonarqube.org/latest/. 
https://www.sonarqube.org/
https://www.ndepend.com/
https://docs.sonarqube.org/latest/
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 31 de 45 
Segurança 
Uma das maiores preocupações das aplicações atualmente está relacionada 
à segurança. Todo o código desenvolvido também deve ser testado a nível de 
segurança, em diversos níveis, de acordo com sua criticidade. 
Durante o processo de automatização, seja no CI ou no CD, podemos 
executar processos de testes, especificamente para chegar vulnerabilidades. 
Esta prática estende a cultura DevOps para DevSecOps. Ou seja, ocorre a 
aplicação de práticas de segurança em nosso ciclo de desenvolvimento. 
Checagem de vulnerabilidades de desenvolvimento 
Uma boa prática nesse caso é a utilização de ferramentas como CheckMarx 
(https://www.checkmarx.com/) ou o Owasp Zap (https://owasp.org/www-project-zap/). 
Existem opções pagas e free. O Owasp Zap tem como característica tanto 
uma execução mais básica para chegar às vulnerabilidades em seu código, podendo 
ser executado em uma branch específica, geralmente a main, durante o processo de 
pipeline. Alémdisso, existe uma outra opção e executá-lo no processo de CD, de 
forma agendada, por ser um processo mais demorado pelo fato de efetuar diversos 
tipos de ataques na aplicação. 
O Owasp Zap é gratuito e possui uma forma de executá-lo via Docker 
container, facilitando o seu uso em diversas ferramentas e cenários. 
Vulnerabilidade de pacotes 
Assim como o código deve ser analisado em busca de vulnerabilidades, outra 
boa prática é o uso de ferramentas para checagem dos pacotes nos quais a aplicação 
depende. Utilizar pacotes de terceiros é uma prática comum. Frequentemente 
utilizamos libraries para facilitar o desenvolvimento das funcionalidades, como 
serialização de objetos em Json, geração de logs, entre outros. Mas utilizar tais 
pacotes não garantem a segurança de nossas aplicações, ainda mais quando estes 
pacotes são open source. Como garantir que tais bibliotecas possuem os mesmos 
processos e procedimentos aplicados em nossa organização? Impossível. Neste 
https://www.checkmarx.com/
https://owasp.org/www-project-zap/
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 32 de 45 
caso, é importante executar checagens nas dependências dos processos. Tais 
checagens podem variar de acordo com o nível de necessidade. 
Uma boa sugestão nesse caso é o uso da ferramenta White source bolt 
(https://www.whitesourcesoftware.com/free-developer-tools/bolt/). Esta ferramenta é 
paga, porém tem uma versão gratuita e limitada que pode ser executada no processo 
de CI. 
O seu trabalho é chegar, além das vulnerabilidades das dependências do 
projeto, também nos termos de uso ou licenças. Ela nos traz um ótimo relatório do 
diagnóstico das dependências da solução e também pode ser configurada para ser 
executada em determinados branches. 
Este tipo de verificação é muito importante para garantir, de forma 
automatizada, a saúde e segurança dos projetos de forma automatizada. 
 
Pirâmide de testes 
A pirâmide de testes é um bom direcionador para nossos projetos, definindo 
contextos bem delimitados sobre o que testar e quando testar. 
Figura 13 – Pirâmide de testes. 
 
Fonte: https://martinfowler.com/articles/practical-test-
pyramid.html?ref=hackernoon.com. 
https://www.whitesourcesoftware.com/free-developer-tools/bolt/
https://martinfowler.com/articles/practical-test-pyramid.html?ref=hackernoon.com
https://martinfowler.com/articles/practical-test-pyramid.html?ref=hackernoon.com
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 33 de 45 
Existem algumas variações desta pirâmide, tendo em vista mais camadas da 
mesma para separar ainda mais o contexto a ser testado. O que é importante aqui é 
não somente a definição dos momentos em que algo deve ser testado, mas como e 
porquê. 
De acordo com a Figura 13, podemos entender completamente a importância 
de cada fase. A base da pirâmide é maior, tendo em vista que há menos custo e maior 
facilidade de implementação. É uma boa relação com a cobertura de códigos de uma 
aplicação. 
Quanto mais subimos na pirâmide, maior são os testes de integração e 
juntamente com eles o aumento da complexidade de criá-los e o custo, não 
especificamente relacionado a valor monetário, mas sim no tempo. É importante se 
ater que subir nos níveis das pirâmides não quer dizer algo ruim, pelo contrário. Mas 
testar o que é necessário, de acordo com as camadas e quando necessário, é muito 
importante. Vale uma reflexão aqui: No topo da pirâmide encontramos os testes E2E 
(end-to-end) e que geralmente são automatizados. Será que realmente tudo deve ser 
automatizado? Lembre-se, dependendo da sua cobertura de testes nas bases 
inferiores, muitas das necessidades de testes já foram sanadas, então testar fluxos 
mais coerentes e mais importantes fazem sentido aqui. 
Conforme mencionado, a pirâmide é um bom direcionador para as equipes 
sobre o ponto de vista de qualidade. Ela ajuda até mesmo definir os momentos 
corretos de execução dos testes nos processos automatizados. Além disso, cada fase 
depende de ferramentas e práticas específicas, portanto, um bom planejamento e 
alinhamento entre os times é de extrema importância. 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 34 de 45 
Capítulo 6. Gestão de mudanças 
Com a atual demanda do mercado, as mudanças de planejamento e 
estratégias no desenvolvimento de software são constantes. Saber planejar e 
documentar corretamente as soluções é uma ótima prática. Além disso, vários tipos 
de mudanças que ocorrem no ciclo de desenvolvimento podem surgir como 
oportunidades de melhorias nos processos e, em vários casos, serem um grande 
motivador para a implementações de estratégias para obter ganhos importante em 
nossas aplicações. 
 
Configurações 
Como são geridas as configurações de sua aplicação? Em arquivos de 
configuração? Ok. Um ótimo ponto de partida. Da mesma forma, como são 
gerenciadas essas mesmas configurações para o ambiente? 
Segundo uma ótima fonte de referência para o desenvolvimento de 
aplicações modernas, The twelve-factor app (https://12factor.net/), as configurações 
podem variar constantemente entre os deployments e é uma boa prática gerenciá-las 
de maneira segura e eficaz. 
Sabemos que as aplicações possuem diversos contextos onde é primordial 
prezar pela segurança. Sendo assim, gerenciar credenciais, dados de conexão com 
banco de dados, chaves de integração com serviços (por exemplo, gateways de 
pagamento), entre outras, devem ser mantidas e geridas de forma segura, e não 
somente isso. Esta gestão facilita as constantes mudanças que podem ocorrer em 
alguma dessas dependências e suas alterações devem ser transparentes para as 
aplicações. 
Por isso, uma boa prática é a utilização de um Config Server. 
 
 
https://12factor.net/
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 35 de 45 
Figura 14 – Config Server. 
 
Como exibido na imagem acima, temos o exemplo de uma aplicação .Net 
Core que geralmente depende de arquivos de configuração (appsettings.json). Tais 
configurações são modificadas de acordo com o ambiente e, geralmente, uma boa 
prática executada são as alterações de scripts baseado em Strings Transformations 
durante o processo de CD. 
Contudo, apesar de uma boa prática, havendo a necessidade de mudança, 
um processo de CD deve ser iniciado novamente. E, além disso, ainda não existe um 
ambiente seguro para gestão das configurações, que não deve ser de 
responsabilidade da ferramenta de automação. 
O Config Server atua como ponto central para as configurações. Conforme o 
exemplo da imagem, a aplicação .Net Core está conectada a um servidor de 
configuração, neste caso, o Spring Cloud Config (https://cloud.spring.io/spring-cloud-
config/reference/html/). O Config Sever obtém a configuração de acordo com a 
aplicação e ambiente, baseado em um repositório git, por exemplo. Este repositório 
tem acesso limitados e é possível, além de manter a rastreabilidade, definir 
configurações para diversos tipos de cenários. Outro ponto positivo é que caso haja 
https://cloud.spring.io/spring-cloud-config/reference/html/
https://cloud.spring.io/spring-cloud-config/reference/html/
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 36 de 45 
uma atualização em alguma configuração, ela será feita no arquivo de configuração 
e a aplicação será beneficiada com as atualizações de forma transparente. 
O uso do Config Server é extremamente recomendado por centralizar toda a 
gestão das configurações e também evitar erros humanos, sendo fácil implementar e 
estender entre os ambientes. 
Existem muitas soluções que implementam o conceito de Config Server, a se 
destacar: 
 Spring Cloud Config; e 
 Azure App Conguration. 
 
Feature Toggles 
Uma outra prática muito poderosa, mas que também vem acompanhada de 
alguma complexidade, são os feature toggles ou feature flags.As aplicações funcionam com base em comportamentos. Esses 
comportamentos são executados de acordo com um fluxo. Utilizando a técnica de 
Feture Toggle, temos a possibilidade de alterar o funcionamento de uma aplicação 
on-line, sem a necessidade de recompilar novamente a solução. É uma ótima 
estratégia e muitas vezes é utilizada para apoiar o desenvolvimento com a estratégia 
de branch Trunk based, no entanto, o feature toggle vai muito mais além. 
Afinal de contas, o que é o feature toggle? 
 
 
 
 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 37 de 45 
Figura 15 – Feature Toggle. 
 
Fonte: https://featureflags.io/feature-flag-introduction/. 
Como podemos observar nesta imagem, os toggles são um “liga desliga” que 
se resume, basicamente, em um IF no código fonte da aplicação. 
Constantemente utilizamos este recurso de forma sutil nos aplicativos que 
temos em nossos dispositivos, como configurar para não baixar vídeos e imagens 
automaticamente ao receber mensagens. 
Contudo, o uso de feature toggles não é somente para permitir a criação de 
aplicações altamente configuráveis. Além disso, pode ser utilizado para aplicar testes 
A/B, promover mudanças de infraestrutura de aplicações, habilitar recursos 
específicos para determinados tipos de usuários ou até mesmo como estratégia de 
atualização de algum recurso nas aplicações, ou seja, havendo algum problema, 
basta agir desligando o toggle, sem a necessidade de novos builds ou rollbacks. 
O uso de feature toggles também traz autonomia para a equipe de negócios, 
e faz parte de todo o clico de desenvolvimento. Assim, os responsáveis pelos projetos 
têm a capacidade de habilitar ou desabilitar funcionalidades e, além disso, uma 
https://featureflags.io/feature-flag-introduction/
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 38 de 45 
feature é planejada como parte importante do processo de entrega de valor e deve 
ser assistida, já que o uso desta prática também gera o famoso débito técnico. Então 
é uma poderosa prática que não se limita apenas a pontos de decisão no código, mas 
faz parte de todo o processo de desenvolvimento e a participação de todos os times 
é essencial. 
 
Wiki 
Todas as decisões e padrões dos projetos devem ser documentadas e serem 
de conhecimento de todos. Neste caso, é melhor prezar por ter uma documentação 
consistente o suficiente para todos conseguirem fazer o seu trabalho de acordo com 
os padrões do projeto e da organização. Não existe o óbvio neste ponto. Todas as 
decisões, padrões, riscos, problemas etc., devem ser documentados. 
De forma prática, todo projeto possui requisitos, decisões, riscos e cada 
tópico vai variar de contexto para contexto. 
Pensando, especificamente, no time de desenvolvimento, devemos nos ater: 
 Arquitetura da aplicação: Não é necessário neste caso uma visão 4+1 ou um 
documento arquitetural extremamente detalhado, mas existe a necessidade de 
demonstrar um desenho arquitetural, as decisões, componentes existentes, 
ambientes, responsáveis, riscos, métricas, ferramentas, etc. Cada um desses 
itens pode ser direcionado a outros documentos, mas é importante que o time 
tenha conhecimento completo da solução. 
 Gestão de código: Qual é a estratégia de branh definida para o projeto, 
padrões de nomenclatura, versionamento, padrões de comentários, pull 
requests, code reivew? 
 Diretrizes de Code Review: Todo o time é responsável por fazer reviews de 
outros códigos. No entanto, deve haver um documento que possua o mínimo 
esperado para uma revisão, de acordo com o contexto. Quais as premissas? 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 39 de 45 
Quais os pontos críticos comuns? Quais seriam as ações necessários durante 
esse fluxo? 
 Processo: Independentemente se sua organização atua com um framework 
específico de processos, é importante contextualizar e alinhar os conceitos em 
cada projeto. Como são definidos os planejamentos, quais os ritos 
necessários, tipos de itens de trabalho (Epicos, Task, Sprint, etc.)? Pode haver 
um projeto base com essas informações, mas é importante que haja uma 
referência para este padrão no projeto e, consequentemente, as 
particularidades definidas neste contexto. 
 Glossário e padrões de nomes: Nem todos os termos e siglas são de 
conhecimento de todos. Por isso, é importante contextualizar sobre a 
linguagem utilizada no projeto, quais seriam os padrões de nomenclaturas 
utilizadas, por exemplo, para nomear recursos de nuvem, etc.? 
 Informações do projeto: Qual é o problema que esse projeto resolve e quem 
são os responsáveis e os membros do time disponíveis? Estas informações 
devem se manter atualizadas e direcionadas corretamente com os respectivos 
contados para conhecimento de todos. 
O Wiki é uma das opções para fazer com que estas informações estejam 
disponíveis para todos os envolvidos no projeto de forma ágil e viva. Deve ser 
revisitado e atualizado constantemente. Ferramentas como o Azure DevOps 
possuem o Wiki disponível. 
 
 
 
 
 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 40 de 45 
Figura 16 – Wiki no Azure DevOps. 
 
Fonte: https://docs.microsoft.com/en-us/azure/devops/project/wiki/wiki-create-
repo?view=azure-devops&tabs=browser. 
https://docs.microsoft.com/en-us/azure/devops/project/wiki/wiki-create-repo?view=azure-devops&tabs=browser
https://docs.microsoft.com/en-us/azure/devops/project/wiki/wiki-create-repo?view=azure-devops&tabs=browser
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 41 de 45 
Capítulo 7. Monitoramento 
Um dos objetivos do monitoramento é atingir alta disponibilidade, 
minimizando problemas, agindo de forma proativa. Alguns benefícios relacionados ao 
monitoramento são: 
 TTD – Tempo de detecção: Em outras palavras, assim que o desempenho e 
outros problemas surgem, os dados gerados apoiam diagnóstico sobre os 
problemas e são enviados para as equipes de desenvolvimento por meio de 
monitoramento automatizado. 
 TTM – Tempo de mitigação: As equipes de DevOps agem com base nas 
informações para mitigar os problemas o mais rápido possível para que os 
usuários não sejam mais afetados. 
 TTR – Tempo de resolução: Os tempos de resolução são medidos e as equipes 
trabalham para melhorar ao longo do tempo. Após a mitigação, as equipes 
trabalham em como remediar os problemas na causa raiz para que não 
ocorram novamente. 
Um segundo objetivo do monitoramento é permitir o “aprendizado validado” 
rastreando o uso. O conceito central do aprendizado validado é que cada implantação 
é uma oportunidade de rastrear resultados experimentais que apoiam ou diminuem 
as hipóteses. Rastrear o uso e as diferenças entre as versões permite que os times 
meçam o impacto da mudança e conduzam as decisões de negócios. Se uma 
hipótese for diminuída, a equipe pode “errar rápido” ou “pivotar”. Se a hipótese for 
confirmada, a equipe pode dobrar ou “perseverar”. Essas decisões baseadas em 
dados levam a novas hipóteses e priorização do backlog. 
Além disso, também temos a “Telemetria”, que é o mecanismo de coleta de 
dados de monitoramento. A telemetria pode usar agentes que são instalados nos 
ambientes, um SDK integrado ao código-fonte, direcionados a um servidor ou uma 
combinação destes. Normalmente, a telemetria distingue entre o pipeline de dados 
otimizado para alertas e dashboards em tempo real com dados de maior volume 
necessários para solução de problemas ou análise de uso. 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 42 de 45 
O monitoramento é frequentemente usado para “testar em produção”. Uma 
implantação bem monitorada transmite os dados sobre sua integridade e 
desempenho para que a equipe possa detectar incidentes de produção 
imediatamente. Combinado com o CD, o monitoramento detectará novas anomaliase permitirá a mitigação imediata. Isso permite a descoberta de “incógnitas 
desconhecidas” no comportamento do aplicativo que não pode ser previsto em 
ambientes de pré-produção. 
O monitoramento eficaz é essencial para permitir que as equipes de DevOps 
entreguem com rapidez, obtenham feedback da produção e aumentem a satisfação, 
aquisição e retenção dos clientes. 
Ferramentas como o Application Insights (Microsoft) ou Dynatrace são ótimas 
opções. 
Monitorar nossas soluções é uma prática altamente recomendada e não deve 
restringir apenas à coleta de dados para validar problemas em uma aplicação. O 
monitoramento pode ser feito também a nível de utilização por parte dos usuários, 
para entender o seu comportamento e como a aplicação atende ou não diversos 
cenários. Neste caso, o uso de analytics, como o Google Analytics, é muito importante 
como um direcionador das estratégias de um produto. 
 
Log 
Frequentemente ignorado no desenvolvimento de soluções, o log é uma parte 
do monitoramento e não deve ser apenas um texto escrito em um arquivo, caso 
aconteça alguma exceção. A orquestração de logs também é uma forma de apoio às 
ações proativas em relação a aplicação e deve contar com dados que possibilitam na 
rápida identificação e correção dos problemas. 
Existem muitas opções de mercado direcionadas para se trabalhar com logs: 
 Elastic Search (Kibana e logstash); 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 43 de 45 
 Exceptionless; 
 Elmah; 
 Sentry; 
 Entre outras. 
Uma ferramenta bastante recomendada e que pode ser instalada em sua 
infraestrutura é o Sentry (https://sentry.io/welcome/). 
Um ponto positivo desta ferramenta é a grande capacidade de integrações 
com tecnologias e ferramentas. Possui ótimos SDKs para diversas linguagens e tem 
um ótimo nível de detalhe sobre os erros. 
Através do seu dashboard, é possível gerir uma ou mais aplicações e 
rapidamente criar alertas de problemas, bugs para o time de desenvolvimento, entre 
muitas outas facilidades. 
Figura 17 – Sentry. 
 
Fonte: https://docs.sentry.io/product/error-monitoring/dashboards/. 
https://sentry.io/welcome/
https://docs.sentry.io/product/error-monitoring/dashboards/
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 44 de 45 
Alertas 
O monitoramento também pode ser automatizado com base em alertas. Os 
principais providers de nuvem, por exemplo, possuem várias ferramentas que 
auxiliam no monitoramento dos recursos utilizados, permitindo acompanhar ou tomar 
decisões no ambiente com base em métricas. Exemplificando, é possível configurar 
um alerta para escalar uma nova instância para uma determinada aplicação ou 
recurso com base no percentual de utilização. Este alerta pode enviado através do e-
mail ou de uma mensagem no Microsoft Teams ou Slack e, além disso, 
automaticamente provisionar uma nova versão da aplicação. 
Assim como os alertas, são um grande auxílio no monitoramento já que 
podem ser configurados para diversos propósitos em vários tipos de recursos, como 
informar que o limite de crédito em sua subscrição de nuvem está chegando a um 
limite e você deve tomar algum tipo de ação. 
Como podemos ver, o uso de monitoramento nos permite um feedback 
constante em todo ciclo de desenvolvimento. Os processos de CI, CD, execução de 
testes, o uso das aplicações em ambientes diferentes e até os dados de utilização 
das aplicações são fatores importantes a serem monitorados para manter a saúde 
das soluções e gerar dados para constantes e seguras tomadas de decisões. 
 
 
 
 
 
 
 
 
 
 
 Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 45 de 45 
Referências 
FOWLER, Martin. The pratical Test Pyramid. martinFlowler.com, 2018. Disponível em: 
<https://martinfowler.com/articles/practical-test-pyramid.html?ref=hackernoon.com>. 
Acesso em: 21 jan. 2021. 
GUCKENHEIMER, Sam. What is DevOps?. Microsoft, 2018. Disponível em: 
<https://docs.microsoft.com/pt-br/azure/devops/learn/what-is-devops>. Acesso em: 
21 jan. 2021. 
MICROSOFT. Architecture Guid. Disponível em: 
<https://dotnet.microsoft.com/learn/dotnet/architecture-guides>. Acesso em: 21 jan. 
2021. 
MICROSOFT. Microsoft Docs. Disponível em: <https://docs.microsoft.com>. Acesso 
em: 21 jan. 2021. 
https://martinfowler.com/articles/practical-test-pyramid.html?ref=hackernoon.com
https://docs.microsoft.com/pt-br/azure/devops/learn/what-is-devops
https://dotnet.microsoft.com/learn/dotnet/architecture-guides
https://docs.microsoft.com/