Using sync policies

By default, Argo CD detects when an application's manifests are out of sync, but doesn't sync automatically. This is a good default. In some cases, more tests need to run in dedicated environments before pushing changes to production. In other cases, a human must be in the loop. However, in many other cases, it's OK to automatically deploy changes to the cluster immediately and without human intervention. The fact that Argo CD follows GitOps also makes it very easy to sync back to any previous version (including the last one).

For Delinkcious, I chose auto sync because it is a demo project and the consequences of deploying a bad version are negligible. This can be done in the UI or from the CLI:

argocd app set <APPNAME> --sync-policy automated

The auto sync policy doesn't guarantee that the application will always be in sync. There are limitations that govern the auto sync process, which are as follows:

• Applications in error state will not attempt automated sync.
• Argo CD will attempt only a single auto sync for a specific commit SHA and parameters.
• If auto sync failed for whatever reason, it will not attempt it again.
• You can't roll back an application with auto sync.

In all of these cases, you either have to make a change to the manifests to trigger another auto sync or sync manually. To roll back (or, in general, sync to a previous version), you must turn auto sync off.

Argo CD offers another policy for pruning resources on deployment. When an existing resource no longer exists in Git, Argo CD will not delete it by default. This is a safety mechanism that's used to avoid destroying critical resources if someone makes a mistake while editing Kubernetes manifests. However, if you know what you're doing (for example, for stateless applications), you can turn on automatic pruning:

argocd app set <APPNAME> --auto-prune