Você está na página 1de 45

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
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 2 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 3 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 4 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 5 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 6 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 7 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.

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 8 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.

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 9 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 10 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 11 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 12 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 13 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.

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 14 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.

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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ão có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 26 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 27 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 28 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 29 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/.

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 30 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ém disso, 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

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 31 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.

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 32 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 33 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.

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 34 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

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 35 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 36 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

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 37 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 38 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 39 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.

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 40 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 41 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 anomalias
e 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 42 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/.

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 43 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 44 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.

Implementação, Testes e Qualidade de Software no CVDS Ágil – Página 45 de 45

Você também pode gostar