pages:

- title: "Build your app"

url: "/packaging-compilation"

url: "/building-docker-images"

- title: "Working with Docker registries"

url: "/working-with-docker-registries"

url: "/microservices"

- title: "Production and Staging deployments"

url: "/environment-deployments"

url: "/preview-environments"

url: "/gitops-deployments"

- title: "Progressive Delivery"

url: "/progressive-delivery"

description: "Learn how to deploy with Codefresh and ArgoCD"

group: ci-cd-guides

toc: true

This guide will explain how you can use GitOps for your own applications.

One of the central ideas around GitOps is the usage of Git for ALL project resources. Even though developers are familiar with using Git for the source code of the application, adopting GitOps means that you need to store in Git every other resource of the application (and not just the source code).

Creating a CI pipeline for GitOps is no different than a [standard pipeline]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/) that [packages your Docker images]({{site.baseurl}}/docs/ci-cd-guides/building-docker-images/), runs [tests]({{site.baseurl}}/docs/testing/unit-tests/), performs [security scans]({{site.baseurl}}/docs/testing/security-scanning/) etc.

Codefresh is using this information to fill the deployment history in the GitOps dashboard.

To create a CD pipeline in Codefresh that is responsible for GitOps deployments you must first disable the auto-sync behavior of ArgoCD. You can disable auto-sync either from the GUI or via the [command line](https://argoproj.github.io/argo-cd/user-guide/auto_sync/):

Once the pipeline has finished running the sync status will updated in your GitOps dashboard to reflect the current state.

After you create an ArgoCD application, you can click on it in the [GitOps environment overview](https://g.codefresh.io/gitops) and see the respective GitOps screen.

max-width="100%"

%}

You can add filters on the deployment history by using the multi-select field on the top left of the screen.

For advanced filtering options, the search field on the top right allows you to view only the subset of deployments that match your custom criteria.

Using the search field allows you to quickly find a specific Git commit in the history of the application (and even rollback the deployment as explained in the next sections).

In the GitOps dashboard you will also see a complete history of all past deployments as recorded in Git. You can select any of the previous version and rollback your application to the respective version.

This rollback behavior is best used as an emergency measure after a failed deployment where you want to bring the cluster back to a previous state in a temporary manner. If you wish to keep the current rollback statue as a permanent status it is best to use the standard `git reset/revert` commands and change the GitOps repository to its desired state.

Usually the Pull Requests that take part in a GitOps workflow are created and approved in a manual way (after code review). You have the option however to fully automate the whole process and rather than opening a Pull Request on both the application repository and the manifest repository, commit automatically the manifest changes inside the pipeline that creates the artifact.