Fala galera, beleza? Vamos falar um pouquinho agora sobre as ações do CodePipeline. Primeiro vamos entender o que é uma ação. A ação é definida por as propriedades que ela tem, que são os tipos de ação, por exemplo, o provedor de serviço que vai executar aquela ação, como o CodeBuild, como o CodeDeploy e assim por diante. A ordem que a ação vai ter para executar ali, ou seja, o passo a passo da ação. E a configuração específica necessária para executar aquela ação. E aqui para essa configuração específica, entra bastante coisa quando a gente está falando disso. Mas uma ação é isso. São os passo a passo, querendo ou não, e as propriedades de quando a gente está falando de algo que será realizado. Então, de novo, qual o tipo de a ação com o provedor da ação ea ordem da ação e também com a configuração dessa ação beleza são esses os quatro grandes atributos de uma ação quando está falando das ações vão falar quais são os tipos que a gente vê no code pipeline cada uma dentro de uma categoria específica de tarefa tá então primeiro no source se tem uma ação que obteve o código fonte do repositório de cor repositório de ituruba da bruxa de comitê e assim por diante ou seja se tem ação que obter e o local que você tem que buscar isso quando está falando de build está falando de compilação do código fonte e que execução dos testes empacotamento do software e assim por diante. Também colocando o que você vai usar para buildar essa implantação. Teste. Quando a gente vai executar os testes, a gente coloca ali as ações de execução da série de testes automatizados para validar a qualidade e funcionalidade do código, a ordem disso, quais são os testes que vão ser executados e assim por diante. Essas são as ações ali dentro. Deploy, a implantação do aplicativo no ambiente que você quer, desenvolvimento, teste, produção e assim por diante. E approval, que é a ação ali manual, que vai precisar de uma intervenção humana, de aprovar ou não aquela continuação do pipeline. Geralmente, quando a gente está falando de uma implementação em produção, a liderança vai lá, a liderança técnica dá o ok para aquilo continuar subindo e assim por diante. Quando a gente está falando das configurações de uma ação, você precisa especificar ali os detalhes operacionais, como onde está o código daquilo, os parâmetros de compilação, as configurações de ambiente, para qual ambiente você vai mandar aquilo, de teste, ambiente de produção e assim por diante. Também você precisa definir as credenciais de segurança, isso é muito importante. Quando você está colocando as ações dentro do CodePipeline, você está colocando uma execução automática. Como tudo na AWS, você começa com privilégios mínimos. Então, quando você vai colocar algum tipo de ação assim, você precisa ir lá no IAM e colocar a autorização para que esse CodePipeline consiga acessar os recursos para fazer essas ações automáticas. Esse é um passo a passo do que seria uma ação. E execução da ação. Quando o Pipeline é disparado, por exemplo, um commit, um repositório, ou seja, tem que definir qual vai ser o disparo da ação, qual o trigger que vai estourar aquela ação, fazer com que ela saia realizando alguma coisa. E pode ser um commit, pode ser um commit, por exemplo, no repositório de código, ou pode ser algum outro tipo de evento que você entenda que faça sentido para dar start no seu pipeline. O CodePip e vai processar são assim que você deu esse start é na ordem definida se uma ação por exemplo falha você pode definir se você quer parar aquilo e tem que ter uma ação anual para começar de novo ou ele pode enviar uma notificação falando olha falhou e alguém precisa executar alguma coisa, ou com base nessa notificação ele pode até tentar reexecutar e assim por diante e tentar de novo. Alguns pipelines tentam a primeira vez, fazem uma retentativa, quando não funciona, estoura uma notificação avisando que alguém tem que atuar, porque tem alguma coisa errada no CodePipeline. Então basicamente essa é a visão de ações que é legal a gente ter, que é o que a gente vai implementar dentro do Code Pipeline. Quando a gente está falando de transição de artefatos, vamos primeiro entender o que é um artefato. Quando a gente está falando do AWS Code Pipeline, um artefato pode ser um conjunto de arquivos que vão ser usados durante o processo de pipeline tá isso pode ser desde um código fonte até arquivo de configuração executáveis e assim por diante se tem ali alguma série de arquivos que você pode usar que serão executados durante um code pipeline então quando a gente está falando dessa transição de artefatos a gente tem algumas algumas coisas para pensar aqui. Primeiro, como é que vai funcionar isso daqui? Quando o pipeline vai ser executado, os artefatos normalmente, em uma fase, por exemplo, de compilação, esse artefato vai ser armazenado ali em um lugar intermediário, normalmente é dentro de um S3 bucket do Amazon ali, e depois esses artefatos são passados para a próxima fase do pipeline. A gente usa o S3 bucket, quer dizer, o Code Pipeline usa o S3 bucket para garantir a durabilidade daquela informação e assim por diante. Então ele garante que aquele artefato vai continuar vivo durante esse processo. Então esse artefato vai passar para a próxima fase do pipeline, por exemplo, depois das fases de compilação, eles vão ser utilizados por exemplo na fase de teste, depois na fase de implementação, então ele está sendo gravado ali no S3 bucket para você conseguir ir andando com esse artefato nas fases do CodePipeline. O gerenciamento dele, a AWS faz o gerenciamento ali do CodePipeline, ela faz o gerenciamento automático, a criação e armazenamento da transição destes artefatos entre as fases, ou seja, ela vai fazer essa sacada de colocar no S3 bucket e depois ir andando pelas fases, beleza? Ele usa o S3, como eu falei, para garantir durabilidade e disponibilidade e vai permitir que o seu CodePipeline seja resistente a falhas, ou seja, você não vai perder o que você colocou para ser publicado, tá bom? Ele consegue ser integrado com ferramentas externas, então você consegue integrar com a AWS CodePipeline com coisas como por exemplo GitHub, CodeCommit, Bitbucket ou outros tipos de integração aqui para código-fonte. Para ferramentas de build e teste você consegue integrar com Jenkins, consegue integrar com CodeBuploy, o Elastic Beanstalk ou você consegue usar o Kubernetes ou etc, aqui para você fazer a sua implementação beleza? O CodePipeline, no fim das contas o que a gente está falando, ele traz benefícios de algumas coisas na verdade, uma esteira de deploy automatizada traz esses benefícios e o CodePipeline como esteira de deploy automatizada traz esses benefícios. E o CodePipeline, como esteira de deploy automatizada, vai fazer isso. Primeiro, agilidade no desenvolvimento. Você vai ter menos tempo para entregar novas funcionalidades e correções, porque você está fazendo isso de forma mais rápida e mais automatizada. Outra coisa é que você vai diminuir erro, automatizando as horas de build e teste. Você consegue pegar erro de integração mais cedo, você também não vai ter erro humano, você diminui a chance de erro humano, de putz, esqueci algum componente ou de evoluir alguma fase assim por diante, ou pulei uma fase, esqueci de testar, por exemplo não vai acontecer, você também na parte de agilidade eu coloco um outro ponto, o fato de você estar com uma esteira de CI integrada o tempo todo, você acaba diminuindo erros de merge e com isso você também deixa mais rápido a sua integração, a sua entrega contínua. Você também vai ter ali uma flexibilidade, já que você consegue usar várias linguagens de programação, plataformas e assim por diante. E como é uma ferramenta que é gerenciada pela AWS ele consegue escalar automaticamente se tiver várias pessoas da empresa, várias pessoas do time usando ao mesmo tempo, ele vai escalar para dar vazão, beleza?