GitOps é uma forma de implementar Continuous Deployment para aplicações Cloud Native. Ela se concentra em uma experiência centrada no desenvolvedor para operar a infraestrutura, usando ferramentas com as quais os devs já estão familiarizados. A ideia central do GitOps é ter um repositório Git, que sempre concentra arquivos declarativos da infraestrutura desejada no ambiente de produção e um processo automatizado para fazer com que o ambiente de produção corresponda ao estado descrito no repositório. Para implantar uma nova aplicação ou atualizar uma existente, basta atualizar o repositório. O processo automatizado cuida de todo o restante. atualizar o repositório. O processo automatizado cuida de todo o restante. Bom, eu acho que com isso a gente consegue, usando esse tipo de abordagem, a gente também consegue, é quase como se fosse uma evolução da infraestrutura como código. Isso ainda é infraestrutura como código, mas é uma abordagem já um pouquinho mais diferente, a gente consegue ter mais deployments e com mais frequência, e fica um pouquinho mais fácil também a gente ter uma recuperação, um rollback do ambiente, uma vez que a gente utiliza esse tipo de abordagem, tá? Então, para a gente fazer um rollback, por exemplo, basta a gente fazer um git revert, a gente vai ter o código no estado anterior, a gente vai ter uma monitoração em cima desse código, vai esparar toda a automação e vai, tipo, assim, puta, beleza. Tipo, toda aquela alteração que eu tinha feito, agora eu vou conseguir reverter automaticamente, tá? Nesse tipo de abordagem, teremos pelo menos dois tipos de repositórios, os repositórios de app e os repositórios de configuração do ambiente. O repositório de app contém o código fonte e os manifestos da implantação para a implantação, enquanto o repositório de configuração do ambiente contém todos os manifestos de implantação da infraestrutura desejada. Ele descreve quais apps e serviços de infraestrutura, como brokers de mensagem, clusters Kubernetes, service mesh, ferramentas de monitoramento, enfim, devem ser executados, com qual configuração e versão do ambiente de implantação. Existem dois tipos de implementação nesse tipo de abordagem de GitOps, o BASED e o PUSH-BASED. E a diferença entre esses dois tipos de implantação é como é garantido que o ambiente de implantação realmente esteja no estado da infraestrutura desejada. Bom, vamos falar um pouquinho aqui sobre a abordagem de P-Based. Tudo começa com o nosso repositório de aplicação, que é onde a gente vai ter o código-fonte da nossa aplicação, certo? Junto a gente também vai ter os arquivos Yemo do Kubernetes, para a gente conseguir fazer o deployment na segunda pipeline, que é a pipe de provisionamento. A gente vai rodar essa pipeline que vai fazer todos os testes, passar por toda a bateria de testes dessa aplicação. Vai fazer o build desse ambiente e vai fazer a publicação em um registro, seja uma CR, um ECR, um Artifactory, um Docker Hub. Basicamente, essa pipe, o papel dela é fazer o build da imagem de container e a publicação em um registro qualquer. E uma vez que isso aconteça, a gente vai disparar um segundo repositório, que é um repositório de configuração, vamos dizer assim, e nesse repositório a gente vai ter aqui todo o setup da nossa infraestrutura. Então, supondo que esse cara aqui roda, por exemplo, em um cluster ECS, a gente vai ter todo o código de infraestrutura dentro desse repositório, que vai ser disparado assim que for finalizada essa pipeline. A gente vai trigar, certo? Essa pipeline, vai rodar toda ali também a fase de testes, vai rodar a ferramenta que a gente estiver utilizando de infraestrutura como código para aprovisionamento, geralmente terraform, né? Beleza, uma vez que esse cara foi finalizado com sucesso, a gente tem aqui o nosso ambiente rodando 100% de forma automatizada. Uma informação importante nesse tipo de abordagem é que, percebam, é que, percebam, a gente não tem nenhum tipo de monitoração pós-implementação daquilo que foi feito. Então, supondo que a gente fez o rollout, funcionou tudo certo, passou com sucesso, alguém com acesso entrou aqui no nosso ambiente de produção e fez algum tipo de alteração. Logo, esse ambiente já não está exatamente igual àquilo que a gente tem configurado aqui no nosso ambiente de configuração, por exemplo. Então, nesse tipo de abordagem, é importante que a gente tenha algumas ferramentas para mitigar esse tipo de situação, aí podem ser ferramentas de policy as code por exemplo, de gestão de configuração, mas nesse tipo de abordagem a gente só vai conseguir ter o ambiente, vamos dizer assim, 100% compliance novamente com o que está aqui no nosso repositório de configuração, no caso de a gente ter uma ferramenta como essa ou de rodar um novo deployment. E a gente também tem aqui a segunda abordagem, que seria a abordagem baseada em pool-based. Então, para a parte de CI, vamos dizer assim, a gente permanece com o mesmo comportamento, Para a parte de CI, vamos dizer assim, a gente permanece com o mesmo comportamento, a gente tem um repositório com o nosso código fonte, a gente faz o build da imagem, entrega essa imagem dentro de um container registry e a gente também tem aqui o nosso repositório de configuração. nosso repositório de configuração. Todavia, esse cara não é disparado. Como que funciona essa abordagem? Dentro do nosso cluster, imagina esse retângulo cinza, como se fosse um cluster Kubernetes, a gente vai ter aqui os nossos deployments, ou não, pode ser que seja o primeiro deployment, mas basicamente o estado final que a gente quer é que esse deployment esteja aqui rodando dentro do nosso cluster Kubernetes. E a gente tem um cara importantíssimo que são os Operators. Operators são softwares que a gente consegue adicionar funcionalidades extras ao Kubernetes. Existem diversos tipos de Operators, mas aqui quando a gente fala de um Operator como esse, geralmente a gente está falando de um Argo, certo? O Argo CD, por exemplo, é um cara que conseguiria fazer esse tipo de trabalho. Ele estaria aqui e ele fica constantemente observando quais são as configurações que estão no meu repositório ele consegue até fazer observação se eu tive algum update aqui no meu no meu registro e com base nisso ele consegue fazer o depoimento do do meu também aplicação em si então suponha que aqui a gente tem, sei lá, uma versão 1.0.0, eu já tenho tudo provisionado e aqui no meu repositório de configuração eu estou apontando para uma imagem do tipo latest, por exemplo. Sempre que eu disparar esse cara e eu gerar uma release nova, Sempre que eu disparar esse cara e eu gerar uma release nova, esse cara vai conseguir olhar para essa configuração e falar assim, opa, tive uma modificação aqui diferente do que, tive uma modificação no caso, né? Tipo, eu tenho a versão 1.0.0, subi uma versão 1.0.0, por exemplo. Então, esse cara vai automaticamente pegar essa imagem fazer atualização dessa versão nova aqui esse exemplo que eu dei assim não é uma boa prática né não deixa configurado como leite mas o mesmo vale quando a gente quer fazer algum tipo de alteração de infraestrutura né então a gente consegue fazer as alterações esse repositório de environment e a gente vai fazer observação e já vai refletir e percebam né diferente da primeira abordagem é a gente tem uma observação contínua então se eu vier aqui e fizer qualquer tipo de modificação de forma manual é esse cara ele vai identificar que o meu deployment está out of sync, certo? Porque ele não está batendo mais com as configurações que eu tenho dentro do meu repositório, e ele vai aqui e faz o enforcement. Beleza, mineiro. Mas, cara, na vida real, a gente tem diversos ambientes, né? A gente não tem um único ambiente como a gente mostrou aqui nos últimos dois slides. Então, como que funcionaria isso pensando em múltiplas imagens e pensando também em múltiplos environments, né? Aqui a gente tem um repositório de código de um microserviço payment, e a gente tem um outro microserviço de inventário. Mesma coisa, a gente tem aqui as etapas de CI, e a publicação da imagem, e a gente permanece com um repositório de environment. Nessa abordagem a gente está utilizando uma abordagem do tipo push-based, então sempre que eu tiver uma alteração nesse código, eu vou disparar aqui o meu trigger. E como que vai funcionar a distinção entre ambientes? Uma vez que eu esteja fazendo qualquer tipo de modificação ou seja tipo cara vim aqui e fiz algumas atualizações né nessa etapa essas duas etapas estou modificando uma branch do tipo develop por exemplo eu vou disparar um morekflow que vai fazer o deployment no meu ambiente de develop ou no meu ambiente de staging. E sempre que eu fizer uma alteração em uma branch main, a gente vai disparar a pipeline que vai fazer a atualização no meu ambiente de produção. ambiente de produção. Percebam, é uma abordagem que está fortemente ligada à forma como a gente utiliza o Git. Então, o Git passa a ser a fonte da verdade nesses casos.