# Implementação da integração e entrega contínuas
Esta seção discute as maneiras pelas quais você pode começar a implementar um modelo de CI/CD em sua organização. Este whitepaper não discute como uma organização com um DevOps maduro e um modelo de transformação em nuvem cria e usa um pipeline de CI/CD. Para ajudar em sua jornada de DevOps, a AWS tem vários [parceiros de DevOps certificados](https://aws.amazon.com/devops/partner-solutions/) que podem fornecer recursos e ferramentas. Se quiser obter mais informações sobre como se preparar para uma mudança para a Nuvem AWS, consulte [Building a Cloud Operating Model](https://d1.awsstatic.com/whitepapers/building-a-cloud-operating-model.pdf).
# Um caminho para a integração e entrega contínuas
A CI/CD pode ser representada como um pipeline (consulte a figura a seguir), em que o novo código é enviado em uma extremidade, testado em uma série de estágios (fonte, compilação, preparação e produção) e, então, publicado como código pronto para produção. Se a sua organização é nova em CI/CD, ela pode abordar esse pipeline de forma iterativa. Isso significa que você deve começar em uma escala pequena e iterar em cada estágio para que possa entender e desenvolver seu código de uma forma que ajude sua organização a crescer.
![\[Pipeline de CI/CD\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image2.png)
* Pipeline de CI/CD *
Cada estágio do pipeline de CI/CD é estruturado como uma unidade lógica no processo de entrega. Além disso, cada estágio atua como um portão que examina determinado aspecto do código. À medida que o código avança pelo pipeline, a suposição é que a qualidade do código é maior nos estágios posteriores, porque mais aspectos dele continuam a ser verificados. Problemas descobertos em um estágio inicial impedem que o código progrida pelo pipeline. Os resultados dos testes são enviados imediatamente à equipe, e todas as outras compilações e lançamentos serão interrompidos se o software não passar do estágio.
Estas etapas são sugestões. Você pode adaptar os estágios com base nas necessidades da sua empresa. Alguns estágios podem ser repetidos para vários tipos de teste, segurança e performance. Dependendo da complexidade do seu projeto e da estrutura de suas equipes, alguns estágios podem ser repetidos várias vezes em diferentes níveis. Por exemplo, o produto final de uma equipe pode se tornar uma dependência no projeto da próxima equipe. Isso significa que o produto final da primeira equipe será posteriormente preparado como um artefato no projeto da próxima equipe.
A presença de um pipeline de CI/CD terá um grande impacto no amadurecimento dos recursos de sua organização. A organização deve começar com pequenos passos e não tentar construir um pipeline totalmente maduro, com vários ambientes, muitas fases de teste e automação em todos os estágios no início. Lembre-se de que mesmo as organizações que têm ambientes de CI/CD altamente maduros ainda precisam melhorar continuamente seus pipelines.
Construir uma organização habilitada para CI/CD é uma jornada, e há muitos destinos ao longo do caminho. A próxima seção discute um possível caminho que sua organização poderia seguir, começando com a integração contínua por meio dos níveis de entrega contínua.
# Integração contínua
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-source-and-build.png)
* Integração contínua: fonte e compilação *
A primeira fase da jornada de CI/CD é desenvolver a maturidade na integração contínua. Você deve certificar-se de que todos os desenvolvedores confirmem regularmente seu código em um repositório central (como um hospedado no CodeCommit ou GitHub) e mesclar todas as alterações em uma ramificação de lançamento para a aplicação. Nenhum desenvolvedor deve manter o código isolado. Se uma ramificação de recurso for necessária por determinado período, ela deve ser mantida atualizada com a mesclagem baseada no upstream o mais rápido possível. Confirmações e fusões frequentes com unidades completas de trabalho são recomendadas para que a equipe desenvolva disciplina e seja incentivada pelo processo. Um desenvolvedor que mescla o código cedo e com frequência provavelmente terá menos problemas de integração no futuro.
Você também deve incentivar os desenvolvedores a criar testes de unidade o mais cedo possível para as aplicações e executar esses testes antes de enviar o código ao repositório central. Os erros detectados no início do processo de desenvolvimento de software são os mais baratos e fáceis de corrigir.
Quando o código é enviado a uma ramificação em um repositório de código-fonte, um mecanismo de fluxo de trabalho que monitora essa ramificação enviará um comando a uma ferramenta do compilador para criar o código e executar os testes de unidade em um ambiente controlado. O processo de compilação deve ser dimensionado adequadamente para lidar com todas as atividades, incluindo pushes e testes que podem acontecer durante o estágio de confirmação, para um feedback rápido. Outras verificações de qualidade, como cobertura de teste de unidade, verificação de estilo e análise estática, também podem ocorrer nesse estágio. Por fim, a ferramenta compiladora cria uma ou mais compilações binárias e outros artefatos, como imagens, folhas de estilo e documentos para a aplicação.
# Entrega contínua: criação de um ambiente de preparação
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-staging.png)
* Entrega contínua: preparação *
A entrega contínua (CD) é a próxima fase e envolve a implantação do código da aplicação em um ambiente de preparação, que é uma réplica da pilha de produção e a execução de mais testes funcionais. O ambiente de preparação pode ser um ambiente estático predefinido para testes, ou você pode provisionar e configurar um ambiente dinâmico com infraestrutura comprometida e código de configuração para testar e implantar o código da aplicação.
# Entrega contínua: criação de um ambiente de produção
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-production.png)
* Entrega contínua: produção *
Na sequência do pipeline de implantação/entrega, depois do ambiente de preparação, está o ambiente de produção, que também é construído usando infraestrutura como código (IaC).
# Implantação contínua
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-cd.png)
*Implantação contínua*
A fase final do pipeline de implantação de CI/CD é a implantação contínua, que pode incluir automação total de todo o processo de lançamento de software, incluindo a implantação no ambiente de produção. Em um ambiente de CI/CD totalmente maduro, o caminho para o ambiente de produção é totalmente automatizado, o que permite que o código seja implantado com alta confiança.
# Maturidade e além
À medida que a organização amadurece, ela continuará a desenvolver o modelo de CI/CD para incluir mais das seguintes melhorias:
+ Mais ambientes de preparação para testes específicos de performance, conformidade, segurança e interface do usuário (UI)
+ Testes de unidade de infraestrutura e código de configuração junto com o código da aplicação
+ Integração a outros sistemas e processos, como revisão de código, rastreamento de problemas e notificação de eventos
+ Integração à migração de esquema de banco de dados (se aplicável)
+ Etapas adicionais para auditoria e aprovação empresarial
Até mesmo as organizações mais maduras que têm pipelines complexos de CI/CD em vários ambientes continuam buscando melhorias. DevOps é uma jornada, não um destino. O feedback sobre o pipeline é coletado continuamente e melhorias na velocidade, escala, segurança e confiabilidade são alcançadas como uma colaboração entre as diferentes partes das equipes de desenvolvimento.
# Equipes
A AWS recomenda organizar três equipes de desenvolvedores para implementar um ambiente de CI/CD: uma equipe de aplicações, uma equipe de infraestrutura e uma equipe de ferramentas (consulte a figura a seguir). Essa organização representa um conjunto de práticas recomendadas que foram desenvolvidas e aplicadas em startups em rápida evolução, grandes organizações corporativas e na própria Amazon. As equipes devem ter o máximo de pessoas para as quais duas pizzas devem ser o suficiente, ou seja, cerca de 10 a 12 pessoas. Isso segue a regra de comunicação de que conversas significativas atingem limites à medida que o tamanho dos grupos aumenta e as linhas de comunicação se multiplicam.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image7.png)
*Equipes de aplicações, infraestrutura e ferramentas*
## Equipe de aplicações
A equipe de aplicações cria a aplicação. Os desenvolvedores de aplicações possuem o backlog, as histórias e os testes de unidade e desenvolvem recursos com base em um destino de aplicação especificado. O objetivo organizacional dessa equipe é minimizar o tempo que esses desenvolvedores gastam em tarefas de aplicações não essenciais.
Além de ter habilidades de programação funcional na linguagem da aplicação, a equipe de aplicações deve ter habilidades de plataforma e um entendimento da configuração do sistema. Isso permitirá que eles se concentrem exclusivamente no desenvolvimento de recursos e no fortalecimento da aplicação.
## Equipe de infraestrutura
A equipe de infraestrutura escreve o código que cria e configura a infraestrutura necessária para executar a aplicação. Essa equipe pode usar ferramentas nativas da AWS, como o AWS CloudFormation, ou ferramentas genéricas, como Chef, Puppet ou Ansible. A equipe de infraestrutura é responsável por especificar quais recursos são necessários e trabalha em estreita colaboração com a equipe de aplicações. A equipe de infraestrutura pode consistir em apenas uma ou duas pessoas para uma pequena aplicação.
A equipe deve ter habilidades em métodos de provisionamento de infraestrutura, como o AWS CloudFormation ou o HashiCorp Terraform. A equipe também deve desenvolver habilidades de automação de configuração com ferramentas como Chef, Ansible, Puppet ou Salt.
## Equipe de ferramentas
A equipe de ferramentas cria e gerencia o pipeline de CI/CD. Eles são responsáveis pela infraestrutura e pelas ferramentas que compõem o pipeline. Eles não fazem parte da equipe de duas pizzas, porém, criam uma ferramenta que é usada pelas equipes de aplicações e infraestrutura da organização. A organização precisa amadurecer continuamente sua equipe de ferramentas, para que ela esteja um passo à frente das equipes de aplicações e infraestrutura em desenvolvimento.
A equipe de ferramentas deve ser habilidosa na construção e integração de todas as partes do pipeline de CI/CD. Isso inclui a criação de repositórios de controle de fonte, mecanismos de fluxo de trabalho, ambientes de compilação, frameworks de teste e repositórios de artefatos. Essa equipe pode optar por implementar softwares como AWS CodeStar, AWS CodePipeline, AWS CodeCommit, AWS CodeDeploy, AWS CodeBuild e AWS CodeArtifact, junto com Jenkins, GitHub, Artifactory, TeamCity e outras ferramentas semelhantes. Algumas organizações podem chamá-la de equipe de DevOps, mas a AWS não recomenda e, em vez disso, incentiva pensar em DevOps como a soma de pessoas, processos e ferramentas na entrega de software.
# Estágios de teste em integração e entrega contínuas
As três equipes de CI/CD devem incorporar testes ao ciclo de vida de desenvolvimento de software nos diferentes estágios do pipeline de CI/CD. No geral, os testes devem começar o mais cedo possível. A pirâmide de teste a seguir é um conceito fornecido por Mike Cohn em *Aplicando métodos ágeis com sucesso*. Ela mostra os vários testes de software em relação ao custo e à velocidade com que são executados.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image8.png)
* Pirâmide de testes de CI/CD *
Os testes de unidade estão na parte inferior da pirâmide. Eles são os mais rápidos de executar e os mais baratos. Portanto, os testes de unidade devem constituir a maior parte da sua estratégia de teste. Uma boa regra prática é de cerca de 70%. Os testes de unidade devem ter cobertura de código quase completa porque os bugs capturados nessa fase podem ser corrigidos de forma rápida e barata.
Os testes de serviço, componente e integração estão acima dos testes de unidade na pirâmide. Esses testes exigem ambientes detalhados e, portanto, são mais caros em requisitos de infraestrutura e mais lentos para serem executados. Os testes de performance e conformidade são o próximo nível. Eles exigem ambientes de qualidade de produção e ainda são mais caros. Os testes de aceitação da interface do usuário e do usuário estão no topo da pirâmide e exigem ambientes de qualidade de produção também.
Todos esses testes fazem parte de uma estratégia completa para garantir um software de alta qualidade. No entanto, para velocidade de desenvolvimento, a ênfase está no número de testes e na cobertura na metade inferior da pirâmide.
As seções a seguir discutem os estágios de CI/CD.
## Configuração da fonte
No início do projeto, é essencial configurar uma fonte na qual você possa armazenar o código bruto e as alterações de configuração e esquema. No estágio de fonte, escolha um repositório de código-fonte, como um hospedado no GitHub ou o AWS CodeCommit.
## Configuração e execução de compilações
A automação da compilação é essencial para o processo de CI. Ao configurar a automação da compilação, a primeira tarefa é escolher a ferramenta de compilação correta. Existem muitas ferramentas de compilação, como:
+ Ant, Maven e Gradle para Java
+ Make para C/C\$1\$1
+ Grunt para JavaScript
+ Rake para Ruby
A ferramenta de compilação que funcionará melhor para você depende da linguagem de programação do projeto e do conjunto de habilidades da equipe. Depois de escolher a ferramenta de compilação, todas as dependências precisam ser claramente definidas nos scripts de compilação, juntamente com as etapas de compilação. Também é uma prática recomendada fazer a versão dos artefatos de compilação finais, o que facilita a implantação e o controle dos problemas.
## Desenvolvimento
No estágio de compilação, as ferramentas de compilação receberão como entrada qualquer alteração no repositório de código-fonte, compilarão o software e executarão os seguintes tipos de testes:
**Teste de unidade:** testa uma seção específica do código para garantir que ele faça o que é esperado. O teste de unidade é realizado por desenvolvedores de software durante a fase de desenvolvimento. Nesse estágio, podem ser aplicados uma análise de código estático, análise de fluxo de dados, cobertura de código e outros processos de verificação de software.
**Análise de código estático:** esse teste é realizado sem realmente executar a aplicação após o teste de compilação e unidade. Essa análise pode ajudar a encontrar erros de codificação e falhas de segurança, além de garantir a conformidade com as diretrizes de codificação.
## Preparação
Na fase de preparação, são criados ambientes completos que espelham o ambiente de produção eventual. Os seguintes testes são realizados:
**Teste de integração**: verifica as interfaces entre os componentes em relação ao design do software. O teste de integração é um processo iterativo e facilita a compilação de interfaces robustas e integridade do sistema.
**Teste de componentes**: testa a transmissão de mensagens entre vários componentes e seus resultados. Um dos principais objetivos desse teste pode ser a idempotência no teste de componentes. Os testes podem incluir volumes de dados extremamente grandes ou situações de borda e entradas anormais.
**Teste do sistema**: testa o sistema de ponta a ponta e verifica se o software atende aos requisitos empresariais. Isso pode incluir o teste da interface do usuário (UI), da API, da lógica de backend e do estado final.
**Teste de performance:** determina a capacidade de resposta e a estabilidade de um sistema conforme ele é executado em uma workload específica. O teste de performance também é usado para investigar, medir, validar ou verificar outros atributos de qualidade do sistema, como escalabilidade, confiabilidade e uso de recursos. Os tipos de testes de performance podem incluir testes de carga, testes de estresse e testes de pico. Os testes de performance são usados para testes comparativos com relação a critérios predefinidos.
**Teste de conformidade:** verifica se a alteração do código está em conformidade com os requisitos de uma especificação e/ou regulamentos não funcionais. Ele determina se você está implementando e atendendo aos padrões definidos.
**Teste de aceitação do usuário:** valida o fluxo de negócios de ponta a ponta. Esse teste é executado por um usuário final em um ambiente de preparação e confirma se o sistema atende aos requisitos da especificação do requisito. Normalmente, os clientes empregam metodologias de teste alfa e beta nesse estágio.
## Produção
Por fim, depois de passar nos testes anteriores, a fase de preparação é repetida em um ambiente de produção. Nessa fase, um *teste canary final* pode ser concluído implantando o novo código somente em um pequeno subconjunto de servidores ou até mesmo em um servidor, ou uma Região da AWS antes de implantar o código em todo o ambiente de produção. Os detalhes sobre como implantar com segurança na produção são abordados na seção [Métodos de implantação](deployment-methods.md).
A próxima seção discute a criação do pipeline para incorporar esses estágios e testes.
## Criação do pipeline
Esta seção discute a criação do pipeline. Comece estabelecendo um pipeline apenas com os componentes necessários para a CI e depois faça a transição para um pipeline de entrega contínua com mais componentes e estágios. Esta seção também discute como você pode considerar o uso de funções do AWS Lambda e aprovações manuais para grandes projetos, planos para várias equipes, filiais e Regiões da AWS.
# Começar com um pipeline mínimo viável para integração contínua
A jornada da sua organização em direção à entrega contínua começa com um pipeline mínimo viável (MVP). Conforme discutido em [Implementar integração e entrega contínuas](implementing-continuous-integration-and-continuous-delivery.md), as equipes podem começar com um processo muito simples, como implementar um pipeline que executa uma verificação de estilo de código ou um único teste de unidade sem implantação.
Um componente importante é uma ferramenta de orquestração de entrega contínua. Para ajudar a criar esse pipeline, a Amazon desenvolveu o [AWS CodeStar](https://aws.amazon.com/codestar).
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/aws-codestar-setup.png)
* Página de configuração do AWS CodeStar *
O AWS CodeStar usa AWS CodePipeline, AWS CodeBuild, AWS CodeCommit e AWS CodeDeploy com um processo de configuração integrado, ferramentas, modelos e painel. O AWS CodeStar disponibiliza tudo o que for necessário para desenvolver, criar e implantar rapidamente aplicações na AWS. Isso permite que você comece a liberar o código mais rapidamente. Os clientes que já estão familiarizados com o Console de gerenciamento da AWS e buscam um nível mais alto de controle podem configurar manualmente as ferramentas do desenvolvedor preferidas e podem fornecer serviços individuais da AWS conforme necessário.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codestar-dashboard.png)
* Painel do AWS CodeStar *
O AWS CodePipeline é um serviço de CI/CD que pode ser usado por meio do AWS CodeStar ou do Console de gerenciamento da AWS para atualizações rápidas e confiáveis de aplicações e infraestrutura. O AWS CodePipeline cria, testa e implanta o código toda vez que há uma alteração de código, com base nos modelos de processo de lançamento que você define. Isso permite disponibilizar recursos e atualizações de forma rápida e confiável. Você pode criar facilmente uma solução completa usando nossos plugins pré-criados para serviços de terceiros populares, como o GitHub, ou integrando seus próprios plugins personalizados em qualquer estágio do processo de liberação. Com o AWS CodePipeline, você só paga pelo que usa. Não há tarifas antecipadas nem compromissos de longo prazo.
As etapas do AWS CodeStar e do AWS CodePipeline mapeiam diretamente para os [estágios de CI/CD de fonte, compilação, preparação e produção](testing-stages-in-continuous-integration-and-continuous-delivery.md). Embora a entrega contínua seja desejável, você pode começar com um pipeline simples de duas etapas que verifica o repositório de fonte e executa uma ação de compilação:
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-source-build.png)
* AWS CodePipeline: estágios de fonte e compilação *
Para o AWS CodePipeline, o estágio de fonte pode aceitar entradas do GitHub, do AWS CodeCommit e do Amazon Simple Storage Service (Amazon S3). Automatizar o processo de criação é um primeiro passo fundamental para implementar a entrega contínua e avançar para a implantação contínua. Eliminar o envolvimento humano na produção de artefatos de criação elimina a carga da equipe, minimiza os erros introduzidos pelo empacotamento manual e permite que você comece a empacotar artefatos consumíveis com mais frequência.
O AWS CodePipeline funciona perfeitamente com o AWS CodeBuild um serviço de compilação totalmente gerenciado, para facilitar a configuração de uma etapa de compilação no pipeline que empacota o código e executa testes de unidade. Com o AWS CodeBuild, você não precisa provisionar, gerenciar nem dimensionar seus próprios servidores de compilação. O AWS CodeBuild dimensiona continuamente e processa várias compilações simultaneamente para que elas não fiquem esperando em uma fila. O AWS CodePipeline também se integra a servidores de compilação, como Jenkins, Solano CI e TeamCity.
Por exemplo, no estágio de compilação a seguir, três ações (teste de unidade, verificações de estilo de código e coleta de métricas de código) são executadas em paralelo. Com o AWS CodeBuild, essas etapas podem ser adicionadas como novos projetos sem nenhum esforço adicional na compilação ou instalação de servidores de compilação para lidar com a carga.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-build-functionality.png)
* AWS CodePipeline: funcionalidade de compilação *
Os estágios de fonte e compilação mostrados na figura *AWS CodePipeline: estágios de fonte e compilação*, juntamente com processos de suporte e automação, apoiam a transição de sua equipe para uma integração contínua. Nesse nível de maturidade, os desenvolvedores precisam prestar atenção regularmente aos resultados de compilação e teste. Eles precisam crescer e manter uma base de teste de unidade íntegra também. Isso, por sua vez, reforça a confiança de toda a equipe no pipeline de CI/CD e promove sua adoção.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-stages.png)
* Estágios do AWS CodePipeline *
# Pipeline de entrega contínua
Depois que o pipeline de integração contínua tiver sido implementado e os processos de suporte forem estabelecidos, as equipes poderão começar a transição para o pipeline de entrega contínua. Essa transição exige que as equipes automatizem a construção e a implantação de aplicações.
Um pipeline de entrega contínua é caracterizado pela presença de etapas de preparação e produção, onde a etapa de produção é executada após uma aprovação manual.
Da mesma forma que o pipeline de integração contínua foi criado, as equipes podem começar gradualmente a criar um pipeline de entrega contínua escrevendo seus scripts de implantação.
Dependendo das necessidades de uma aplicação, algumas das etapas de implantação podem ser abstraídas pelos serviços existentes da AWS. Por exemplo, o AWS CodePipeline integra-se diretamente ao AWS CodeDeploy, um serviço que automatiza implantações de código para instâncias do Amazon EC2 e instâncias em execução on-premises, ao AWS OpsWorks, um serviço de gerenciamento de configuração que ajuda você a operar aplicações usando o Chef, e ao AWS Elastic Beanstalk, um serviço para implantação e dimensionamento de serviços e aplicações Web.
A AWS tem uma [documentação](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-w.html#getting-started-w-create-deployment) detalhada sobre como implementar e integrar o AWS CodeDeploy à infraestrutura e ao pipeline.
Depois que a equipe automatiza com sucesso a implantação da aplicação, os estágios de implantação podem ser expandidos com vários testes. Por exemplo, você pode adicionar outras integrações prontas para uso com serviços como o Ghost Inspector, o Runscope e outros, conforme mostrado na figura a seguir.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-code-test-deployment.png)
* AWS CodePipeline: testes de código nos estágios de implantação *
# Adicionar ações do Lambda
O AWS CodeStar e o AWS CodePipeline são compatíveis com a [integração ao AWS Lambda](https://docs.aws.amazon.com/codepipeline/latest/userguide/how-to-lambda-integration.html). Essa integração permite implementar um amplo conjunto de tarefas, como a criação de recursos personalizados no ambiente, a integração a sistemas de terceiros (como o Slack) e a realização de verificações no ambiente recém-implantado.
As funções do Lambda podem ser usadas em pipelines de CI/CD para realizar as seguintes tarefas:
+ Lançar alterações no ambiente aplicando ou atualizando um modelo do AWS CloudFormation.
+ Criar recursos sob demanda em um estágio de um pipeline usando o AWS CloudFormation e excluí-los em outro estágio.
+ Implantar versões de aplicações sem tempo de inatividade no AWS Elastic Beanstalk com uma função do Lambda que troca os valores de [registro de nome canônico](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) (CNAME).
+ Implantar em instâncias do Docker do Amazon Elastic Container Service (ECS).
+ Fazer backup de recursos antes de construir ou implantar criando um snapshot da AMI.
+ Adicionar integração de produtos de terceiros ao pipeline, como publicar mensagens a um cliente do Internet Relay Chat (IRC).
# Aprovações manuais
Adicionar uma ação de aprovação a um estágio em um pipeline no ponto em que você deseja que o processamento do pipeline seja interrompido para que uma pessoa com as permissões do AWS Identity and Access Management (IAM) necessárias possa aprovar ou rejeitar a ação.
Se a ação for aprovada, o processamento do pipeline será retomado. Se a ação for rejeitada, ou se ninguém aprovar ou rejeitar a ação em um prazo de sete dias depois de o pipeline acessar a ação e ser interrompido, o resultado será igual a uma falha de ação, e o processamento do pipeline não prosseguirá.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codedeploy-manual-approvals.png)
* AWS CodeDeploy: aprovações manuais *
# Implantar alterações de código de infraestrutura em um pipeline de CI/CD
O AWS CodePipeline permite selecionar o AWS CloudFormation como uma ação de implantação em qualquer estágio do pipeline. Depois, você pode escolher a ação específica que o AWS CloudFormation deve executar, como criar ou excluir pilhas e criar ou executar [conjuntos de alterações](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3952). Uma [pilha](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3929) é um conceito do AWS CloudFormation e representa um grupo de recursos relacionados da AWS. Embora existam muitas maneiras de provisionar infraestrutura como código, o AWS CloudFormation é uma ferramenta abrangente recomendada pela AWS como uma solução escalável e completa que pode descrever o conjunto mais abrangente de recursos da AWS como código. A AWS recomenda o uso do AWS CloudFormation em um projeto do AWS CodePipeline para [rastrear alterações e testes de infraestrutura](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/continuous-delivery-codepipeline.html).
# CI/CD para aplicações sem servidor
Você também pode usar o AWS CodeStar, o AWS CodePipeline, o AWS CodeBuild e o AWS CloudFormation para criar pipelines de CI/CD para aplicações sem servidor. As aplicações sem servidor integram serviços gerenciados, como o [Amazon Cognito](https://aws.amazon.com/cognito), o Amazon S3 e o Amazon DynamoDB, com serviços orientados por eventos e o AWS Lambda para implantar aplicações de uma maneira que não requer gerenciamento de servidores. Se você for um desenvolvedor de aplicações sem servidor, poderá usar a combinação dos serviços AWS CodePipeline, AWS CodeBuild e AWS CloudFormation para automatizar a criação, o teste e a implantação de aplicações sem servidor expressos em modelos criados com o AWS Serverless Application Model. Para obter mais informações, consulte a documentação do AWS Lambda sobre [Como automatizar a implantação de aplicações com base no Lambda](https://docs.aws.amazon.com/lambda/latest/dg/automating-deployment.html).
Você também pode criar pipelines de CI/CD seguros que seguem as práticas recomendadas da sua organização com os AWS Serverless Application Model Pipelines (AWS SAM Pipelines). Os AWS SAM Pipelines são um novo recurso da CLI do AWS SAM que oferecem acesso aos benefícios de CI/CD em minutos, como acelerar a frequência de implantação, reduzir o tempo de espera para alterações e reduzir erros de implantação. Os AWS SAM Pipelines vêm com um conjunto de modelos de pipeline padrão para o AWS CodeBuild/CodePipeline que seguem as práticas recomendadas de implantação da AWS. Para obter mais informações e ver o tutorial, consulte o blog [Introducing AWS SAM Pipelines](https://aws.amazon.com/blogs/compute/introducing-aws-sam-pipelines-automatically-generate-deployment-pipelines-for-serverless-applications/) (Apresentação de AWS SAM Pipelines).
# Pipelines para várias equipes, ramificações e regiões da AWS
Para um projeto grande, não é incomum que várias equipes trabalhem em componentes diferentes. Se várias equipes usarem um único repositório de código, ele poderá ser mapeado para que cada uma tenha sua própria ramificação. Também deve haver uma ramificação de integração ou lançamento para a fusão final do projeto. Se uma arquitetura orientada a serviços ou de microsserviços for usada, cada equipe poderá ter seu próprio repositório de código.
No primeiro cenário, se um único pipeline for usado, é possível que uma equipe possa afetar o progresso das outras bloqueando o pipeline. A AWS recomenda que você crie pipelines específicos para ramificações de equipe e outro pipeline de lançamento para a entrega do produto final.
# Integração do pipeline ao AWS CodeBuild
O AWS CodeBuild foi projetado para permitir que sua organização crie um processo de compilação altamente disponível com escala quase ilimitada. O AWS CodeBuild fornece ambientes de início rápido para vários idiomas populares, além da capacidade de executar qualquer contêiner do Docker que você especificar.
Com as vantagens de uma forte integração ao AWS CodeCommit, ao AWS CodePipeline e ao AWS CodeDeploy, bem como as ações do Git e do CodePipeline Lambda, a ferramenta CodeBuild é altamente flexível.
O software pode ser criado por meio da inclusão de um arquivo `buildspec.yml` que identifica cada uma das etapas de compilação, incluindo ações de pré e pós-compilação, ou ações especificadas por meio da ferramenta CodeBuild.
Você pode visualizar o histórico detalhado de cada compilação usando o painel do CodeBuild. Os eventos são armazenados como arquivos de log do Amazon CloudWatch Logs.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cloudwatch-logs-log-files.png)
* Arquivos de log do CloudWatch Logs no AWS CodeBuild *
# Integração do pipeline ao Jenkins
Você pode usar a ferramenta de criação do Jenkins [para criar pipelines de entrega](https://www.jenkins.io/doc/book/pipeline/getting-started/). Esses pipelines usam trabalhos padrão que definem etapas para implementar estágios de entrega contínua. No entanto, essa abordagem pode não ser ideal para projetos maiores, pois o estado atual do pipeline não persiste entre as reinicializações do Jenkins, a implementação da aprovação manual não é direta e o rastreamento do estado de um pipeline complexo pode ser complicado.
Em vez disso, a AWS recomenda que você implemente a entrega contínua com o Jenkins usando o [plugin do AWS Code Pipeline](https://wiki.jenkins-ci.org/display/JENKINS/AWS+CodePipeline+Plugin). Esse plugin permite que fluxos de trabalho complexos sejam descritos usando uma linguagem específica de domínio semelhante ao Groovy e pode ser usado para orquestrar pipelines complexos. A funcionalidade do plug-in do AWS Code Pipeline pode ser aprimorada com o uso de plugins satélites, como o [Pipeline Stage View Plugin](https://plugins.jenkins.io/aws-codepipeline/), que visualiza o progresso atual dos estágios definidos em um pipeline, ou o [Pipeline Multibranch Plugin](https://plugins.jenkins.io/workflow-multibranch/), que agrupa as compilações de diferentes ramificações.
A AWS recomenda que você armazene a configuração do pipeline no *Jenkinsfile* e faça com que ela seja verificada em um repositório de código-fonte. Isso permite rastrear alterações no código do pipeline e se torna ainda mais importante ao trabalhar com o Pipeline Multibranch Plugin. A AWS também recomenda que você divida o pipeline em estágios. Isso agrupa logicamente as etapas do pipeline e também permite que o Pipeline Stage View Plugin visualize o estado atual do pipeline.
A figura a seguir mostra um exemplo de pipeline Jenkins, com quatro estágios definidos visualizados pelo Pipeline Stage View Plugin.
![\[alt text not found\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/defined-stages-of-jenkins.png)
*Estágios definidos do pipeline do Jenkins visualizados pelo Pipeline Stage View Plugin*