github.com/argoproj/argo-cd@v1.8.7/docs/user-guide/best_practices.md (about)

     1  # Best Practices
     2  
     3  ## Separating Config Vs. Source Code Repositories
     4  
     5  Using a separate Git repository to hold your kubernetes manifests, keeping the config separate
     6  from your application source code, is highly recommended for the following reasons:
     7  
     8  1. It provides a clean separation of application code vs. application config. There will be times
     9     when you wish to modify just the manifests without triggering an entire CI build. For example,
    10     you likely do _not_ want to trigger a build if you simply wish to bump the number of replicas in
    11     a Deployment spec.
    12  
    13  2. Cleaner audit log. For auditing purposes, a repo which only holds configuration will have a much
    14     cleaner Git history of what changes were made, without the noise coming from check-ins due to
    15     normal development activity.
    16  
    17  3. Your application may be comprised of services built from multiple Git repositories, but is
    18     deployed as a single unit. Oftentimes, microservices applications are comprised of services
    19     with different versioning schemes, and release cycles (e.g. ELK, Kafka + Zookeeper). It may not
    20     make sense to store the manifests in one of the source code repositories of a single component.
    21  
    22  4. Separation of access. The developers who are developing the application, may not necessarily be 
    23     the same people who can/should push to production environments, either intentionally or
    24     unintentionally. By having separate repos, commit access can be given to the source code repo,
    25     and not the application config repo.
    26  
    27  5. If you are automating your CI pipeline, pushing manifest changes to the same Git repository can
    28     trigger an infinite loop of build jobs and Git commit triggers. Having a separate repo to push
    29     config changes to, prevents this from happening.
    30  
    31  
    32  ## Leaving Room For Imperativeness
    33  
    34  It may be desired to leave room for some imperativeness/automation, and not have everything defined
    35  in your Git manifests. For example, if you want the number of your deployment's replicas to be
    36  managed by [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/),
    37  then you would not want to track `replicas` in Git.
    38  
    39  ```yaml
    40  apiVersion: apps/v1
    41  kind: Deployment
    42  metadata:
    43    name: nginx-deployment
    44  spec:
    45    # do not include replicas in the manifests if you want replicas to be controlled by HPA
    46    # replicas: 1
    47    template:
    48      spec:
    49        containers:
    50        - image: nginx:1.7.9
    51          name: nginx
    52          ports:
    53          - containerPort: 80
    54  ...
    55  ```
    56  
    57  ## Ensuring Manifests At Git Revisions Are Truly Immutable
    58  
    59  When using templating tools like `helm` or `kustomize`, it is possible for manifests to change
    60  their meaning from one day to the next. This is typically caused by changes made to an upstream helm
    61  repository or kustomize base.
    62  
    63  For example, consider the following kustomization.yaml
    64  
    65  ```yaml
    66  bases:
    67  - github.com/argoproj/argo-cd//manifests/cluster-install
    68  ```
    69  
    70  The above kustomization has a remote base to the HEAD revision of the argo-cd repo. Since this
    71  is not a stable target, the manifests for this kustomize application can suddenly change meaning, even without
    72  any changes to your own Git repository.
    73  
    74  A better version would be to use a Git tag or commit SHA. For example:
    75  
    76  ```yaml
    77  bases:
    78  - github.com/argoproj/argo-cd//manifests/cluster-install?ref=v0.11.1
    79  ```