GitOps ¨¦ uma t¨¦cnica de implanta??o de aplica??es usando o padr?o . Um operador mant¨¦m a aplica??o implantada sincronizada com a configura??o, geralmente um reposit¨®rio Git. Quando escrevemos pela ¨²ltima vez sobre GitOps, a comunidade ainda n?o havia chegado a um acordo sobre uma defini??o do termo. Na ¨¦poca, est¨¢vamos preocupadas com interpreta??es comuns da t¨¦cnica que inclu¨ªam abordagens como branch por ambiente para configura??o, o que pode levar a . Al¨¦m disso, a mensagem sobre GitOps como uma alternativa ¨¤ entrega cont¨ªnua era confusa. Desde ent?o, os quatro especificam o escopo e a natureza da t¨¦cnica. Quando voc¨º retira a expectativa exagerada e a confus?o, GitOps ¨¦ uma t¨¦cnica ¨²til que aproveita a funcionalidade de um cluster Kubernetes e cria oportunidades para separa??o de conceitos entre a configura??o de uma aplica??o e a implementa??o do processo de implanta??o. Algumas de nossas equipes implementaram o GitOps como parte da estrutura??o do seu processo de entrega cont¨ªnua e tiveram experi¨ºncias positivas, raz?o pela qual recomendamos avali¨¢-lo.
Sugerimos certo cuidado ao abordar GitOps , especialmente em rela??o ¨¤s estrat¨¦gias de branching. GitOps pode ser visto como uma forma de implementar infraestrutura como c¨®digo que envolve a sincroniza??o cont¨ªnua e aplica??o de c¨®digo de infraestrutura do Git em v¨¢rios ambientes. Quando usado com uma infraestrutura de "branch por ambiente", as altera??es s?o promovidas de um ambiente para o outro por meio de merges do c¨®digo. Embora tratar o c¨®digo como a ¨²nica fonte de verdade seja nitidamente uma abordagem correta, estamos vendo branches por ambiente levarem a desvios de ambientes e, eventualmente, configura??es espec¨ªficas do ambiente conforme os merges de c¨®digo se tornam problem¨¢ticos ou at¨¦ mesmo param completamente. Isso ¨¦ muito semelhante ao que vimos no passado com branches de longa dura??o com GitFlow.
