As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Análise do CI/CD
Integração e entrega contínuas (CI/CD) é o processo de automatizar o ciclo de vida do lançamento do software. Em alguns casos, o *D* em CI/CD também pode significar *implantação*. A diferença entre *entrega contínua* e *implantação contínua* ocorre quando você libera uma alteração no ambiente de produção. Com a entrega contínua, é necessária uma aprovação manual antes de promover mudanças na produção. A implantação contínua apresenta um fluxo ininterrupto em todo o pipeline, e nenhuma aprovação explícita é necessária. Como essa estratégia analisa os conceitos gerais de CI/CD, as recomendações e as informações fornecidas são aplicáveis às abordagens de entrega contínua e implantação contínua.
O CI/CD automatiza muitos ou todos os processos manuais tradicionalmente necessários para obter um novo código de um commit na produção. Um pipeline de CI/CD abrange as etapas de origem, criação, teste, preparação e produção. Em cada etapa, os pipelines de CI/CD provisionam qualquer infraestrutura necessária para implantar ou testar o código. Ao usar um pipeline de CI/CD, as equipes de desenvolvimento podem fazer alterações no código que são automaticamente testadas e enviadas para implantação.
Vamos analisar o processo básico de CI/CD antes de discutir algumas das maneiras pelas quais você pode, consciente ou inconscientemente, se desviar do CI/CD totalmente automatizado. O diagrama a seguir mostra as etapas e as atividades de CI/CD em cada etapa.
![\[As cinco etapa de um processo de CI/CD e as atividades e ambientes de cada um.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/strategy-cicd-litmus/images/cicd-stages.png)
## Sobre a integração contínua
A integração contínua ocorre em um repositório de código, como um repositório Git no GitHub. Você trata uma única ramificação principal como a fonte confiável da base de código, e cria ramificações de curta duração para o desenvolvimento de recursos. Você integrará uma ramificação de recurso à ramificação principal quando estiver pronto para implantar o recurso em ambientes superiores. As ramificações de recurso nunca são implantadas diretamente nos ambientes superiores. Para obter mais informações, consulte [Abordagem baseada no trunk](fully-cicd-process-differences.md#trunk-based-approach) neste guia.
*Processo de integração contínua*
1. O desenvolvedor cria uma nova ramificação da ramificação principal.
1. O desenvolvedor faz alterações, cria e testa localmente.
1. Quando as alterações estiverem prontas, o desenvolvedor criará uma [pull request](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (documentação do GitHub) com a ramificação principal como destino.
1. O código é revisado.
1. Quando o código é aprovado, ele é incorporado à ramificação principal.
## Sobre a entrega contínua
A entrega contínua ocorre em ambientes isolados, como ambientes de desenvolvimento e de produção. As ações que ocorrem em cada ambiente podem variar. Muitas vezes, uma das primeiras etapas é usada para fazer atualizações no próprio pipeline antes de continuar. O resultado final da implantação é que cada ambiente é atualizado com as alterações mais recentes. O número de ambientes de desenvolvimento para criação e teste também varia, mas recomendamos que você use pelo menos dois. No pipeline, cada ambiente é atualizado em ordem de importância, terminando com o ambiente mais importante, o ambiente de produção.
*Processo de entrega contínua*
A parte de entrega contínua do pipeline começa extraindo o código da ramificação principal do repositório de origem e passando-o para a etapa de criação. O documento de infraestrutura como código (IaC) do repositório descreve as tarefas que são executadas em cada etapa. Embora o uso de um documento de IaC não seja obrigatório, um serviço ou uma ferramenta de IaC, como [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) ou [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html), é altamente recomendado. As etapas mais comuns incluem:
1. Testes de unidades
1. Criação de código
1. Provisionamento de recursos
1. Testes de integração
Se algum erro ocorrer ou algum teste falhar em qualquer etapa do pipeline, a etapa atual voltará ao estado anterior e o pipeline será encerrado. As alterações subsequentes devem começar no repositório de código e passar por todo o processo de CI/CD.
# Testes para pipelines de CI/CD
Os dois tipos de testes automatizados comumente mencionados nos pipelines de implantação são *testes de unidades* e *testes de integração*. No entanto, há muitos tipos de testes que você pode executar em uma base de código e no ambiente de desenvolvimento. O [AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/application-pipeline/) define os seguintes tipos de testes:
+ **Teste de unidade**: estes testes criam e executam o código da aplicação para verificar se está operando de acordo com as expectativas. Eles simulam todas as dependências externas usadas na base de código. Exemplos de ferramentas de teste de unidade incluem [JUnit](https://junit.org/), [Jest](https://jestjs.io/) e [pytest](https://pytest.org/).
+ **Teste de integração**: estes testes verificam se a aplicação atende aos requisitos técnicos por meio de testes em um ambiente de teste provisionado. Exemplos de ferramentas de teste de integração incluem [Cucumber](https://cucumber.io/), [vRest NG](https://vrest.io/) e [integ-tests](https://docs.aws.amazon.com/cdk/api/v2/docs/integ-tests-alpha-readme.html) (para AWS CDK).
+ **Teste de aceitação**: estes testes verificam se a aplicação satisfaz os requisitos do usuário por meio de testes em um ambiente de teste provisionado. Exemplos de ferramentas de teste de aceitação incluem [Cypress](https://cypress.io/) e [Selenium](https://selenium.dev/).
+ **Teste sintético**: estes testes são executados continuamente em segundo plano para gerar tráfego e verificar se o sistema está íntegro. Exemplos de ferramentas de teste sintético incluem o [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) e o [Dynatrace Synthetic Monitoring](https://www.dynatrace.com/monitoring/platform/synthetic-monitoring/).
+ **Teste de performance**: estes testes simulam a capacidade de produção. Eles determinam se a aplicação atende aos requisitos de performance e comparam as métricas com a performance anterior. Exemplos de ferramentas de teste de performance incluem [Apache JMeter](https://jmeter.apache.org/), [Locust](https://locust.io/) e [Gatling](https://gatling.io/).
+ **Teste de resiliência**: também conhecido como *teste de caos*, esses testes injetam falhas nos ambientes para identificar áreas de risco. Os períodos em que as falhas são injetadas são então comparados aos períodos sem falhas. Exemplos de ferramentas de teste de resiliência incluem o [AWS Fault Injection Service](https://aws.amazon.com/fis/) e o [Gremlin](https://www.gremlin.com/).
+ **Teste de segurança de aplicações estáticas (SAST)**: estes testes analisam o código em busca de violações de segurança, como [injeção de SQL](https://owasp.org/www-community/attacks/SQL_Injection) ou [cross-site scripting (XSS)](https://owasp.org/www-community/attacks/xss/). Exemplos de ferramentas de SAST incluem o [Amazon CodeGuru](https://aws.amazon.com/codeguru/), [SonarQube](https://www.sonarqube.org/) e [Checkmarx](https://checkmarx.com/).
+ **Teste dinâmico de segurança de aplicações (DAST)**: estes testes também são conhecidos como *testes de penetração* ou *pen test*. Eles identificam vulnerabilidades, como injeção de SQL ou XSS em um ambiente de teste provisionado. Exemplos de ferramentas do DAST incluem o [Zed Attack Proxy (ZAP)](https://www.zaproxy.org/) e o [HCL AppScan](https://www.hcltechsw.com/appscan). Para obter mais informações, consulte [Teste de penetração](https://aws.amazon.com/security/penetration-testing/).
Nem todos os pipelines de CI/CD totalmente automatizado executam todos esses testes. No entanto, no mínimo, um pipeline deve executar testes de unidades e testes SAST na base de código, bem como testes de integração e aceitação em um ambiente de teste.
# Métricas para pipelines de CI/CD
De acordo com o [AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/application-pipeline/), você deve, no mínimo, rastrear as quatro seguintes métricas de pipelines de CI/CD:
+ **Prazo de entrega**: o tempo médio necessário para que um único commit chegue ao ambiente de produção. Recomendamos definir como meta um prazo de entrega entre 1 hora e 1 dia, conforme apropriado para seu caso de uso.
+ **Frequência de implantação**: o número de implantações de produção em um determinado período. Recomendamos definir como meta frequências de implantação entre várias vezes por dia e duas vezes por semana, conforme apropriado para seu caso de uso.
+ **Tempo médio entre falhas (MTBF)**: o tempo médio entre o início de um pipeline com êxito e o início de um pipeline com falha. Recomendamos ter como meta um MTBF que seja o mais alto possível. Para obter mais informações, consulte [Increasing MTBF](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/increasing-mtbf.html).
+ **Tempo médio de recuperação (MTTR)**: o tempo médio entre o início de um pipeline com falha e o início do próximo pipeline com êxito. Recomendamos ter como meta um MTTR que seja o mais baixo possível. Para obter mais informações, consulte [Redução do MTTR](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html).
Essas métricas ajudam as equipes a acompanhar seu progresso em direção ao CI/CD totalmente automatizado. As equipes devem ter discussões abertas com as partes interessadas da organização sobre quais devem ser as metas ideais. As situações e necessidades variam muito de organização para organização, e até mesmo de equipe para equipe.
É muito importante lembrar que mudanças rápidas e drásticas geralmente aumentam o risco de surgirem problemas. Estabeleça metas para buscar pequenas melhorias incrementais. Um prazo de entrega ideal comum para pipelines de CI/CD totalmente automatizado é inferior a três horas. Uma equipe que começa com um prazo de entrega de 5,2 dias deve ter como meta uma redução de um dia a cada poucas semanas. Depois que essa equipe atingir um prazo de entrega de um dia ou menos, ela poderá permanecer lá por vários meses e passar para um prazo de entrega mais agressivo, somente se as partes interessadas da equipe e da organização considerarem necessário.