<story><title>Kargo, a multi-stage application lifecycle orchestrator</title><url>https://akuity.io/blog/introducing-kargo/</url></story><parent_chain><item><author>wg0</author><text>I don&amp;#x27;t understand one thing about GitOps.&lt;p&gt;Imagine 10 apps deployed. All are actively deployed let&amp;#x27;s say few times a day.&lt;p&gt;You want to go back 10 days for App  A. But in doing so you would have reverted whole state and all apps as they were 10 days ago.&lt;p&gt;Only way is to cherry pick particular commit and revert it.&lt;p&gt;No? I mean how git can be useful in rolling back singel components back and forth?</text></item><item><author>rjzzleep</author><text>I&amp;#x27;ve used Flux, Flux2 and Argo for GitOps, and they all had their quirks. In general it seems that most CloudNative projects were kinda set in their own vision with very opinionated devs and a lot of corner cases that are not accounted for and won&amp;#x27;t be accounted for.&lt;p&gt;I have a little bit of hope that this one is going to be different with the lessons they got from Argo, but I&amp;#x27;m not holding my breath.&lt;p&gt;Ps. when I first saw Argo, I thought this is it. The solution to all my problems.</text></item></parent_chain><comment><author>avianlyric</author><text>Personally I like to treat the Git in GitOps as an implementation detail. The underlying principle of GitOps is that your entire environments setup and config is written in code, and version controlled. So you can in theory pick any version of your entire env, throw it at blank slate, and reliably get the environment specified by that git hash.&lt;p&gt;Then there’s the whole constant reconciliation of your version controlled env specification, and the actual env, and how you automatically resolve differences. With the most important principle being that the version controlled code&amp;#x2F;config is absolute truth and something needs to figure out how to bend the world to match.&lt;p&gt;But importantly in all of this, Git isn’t that important. Version control is important, infrastructure as code is important, but Git isn’t. Arguably Git isn’t a great tool for GitOps due to issues like the ones you mention. But the huge ecosystem around Git makes the pain worth it.&lt;p&gt;I would argue the “correct” solution to your problem is a tool that automatically creates the correct cherrypicks and reverts for you based on a request to rollback application X.&lt;p&gt;Treat git as a dumb version control system, and broadly ignore “good practice”, because at lot of those good practices are designed for software development, not infrastructure development. We need to develop new working practices, built on top of Git fundamental components, rather than trying to rationalise existing working practices against the new problems that appear in GitOps.</text></comment>
<story><title>Kargo, a multi-stage application lifecycle orchestrator</title><url>https://akuity.io/blog/introducing-kargo/</url></story><parent_chain><item><author>wg0</author><text>I don&amp;#x27;t understand one thing about GitOps.&lt;p&gt;Imagine 10 apps deployed. All are actively deployed let&amp;#x27;s say few times a day.&lt;p&gt;You want to go back 10 days for App  A. But in doing so you would have reverted whole state and all apps as they were 10 days ago.&lt;p&gt;Only way is to cherry pick particular commit and revert it.&lt;p&gt;No? I mean how git can be useful in rolling back singel components back and forth?</text></item><item><author>rjzzleep</author><text>I&amp;#x27;ve used Flux, Flux2 and Argo for GitOps, and they all had their quirks. In general it seems that most CloudNative projects were kinda set in their own vision with very opinionated devs and a lot of corner cases that are not accounted for and won&amp;#x27;t be accounted for.&lt;p&gt;I have a little bit of hope that this one is going to be different with the lessons they got from Argo, but I&amp;#x27;m not holding my breath.&lt;p&gt;Ps. when I first saw Argo, I thought this is it. The solution to all my problems.</text></item></parent_chain><comment><author>benterix</author><text>If you use GitOps to manage apps, you better isolate them somehow, for example put each app in a different directory. In this case, a revert for App A wouldn&amp;#x27;t cause problems for B and C.&lt;p&gt;But frankly, GitOps works best with stateless apps. Managing stateful apps is possible but you need to take care of state yourself.</text></comment>