Releasing

Our standard for releasing applications/resources into a kubernetes cluster is to use Argo CD. On top of this we also use Application Sets to define groupings of applications to be released.

Environments

Each environment should have their own dedicated Argo-cd with our setup. This helps mitigate the risk of allowing an argo deploy to a cluster it should not have access to. An environment does not only have to be a single cluster but can include as many clusters as it necessary.

Application Sets

To enable deployments as simply as possible for applications to the clusters we have opted to standardise around application sets for deploying applications. Withing application sets we can use multiple "generators" to configure what is deployed to which cluster and from where is the helm sourced. The specific application set generators that we have standardised around are

• Git or SCM Provider generators

• Cluster generator

• Pull Request generator

Each of these generators have been chosen for their specific functionality.

Git or SCM Provider Generators

These generators are used to determine where to fetch the helm templates from. If the customer uses a monorepo setup for their helm charts, then we use the Git generator to track new folders containing a Chart.yaml and values.yaml in a specific sub folder. An example of how this looks is the following

└── <app-set-name>
    ├── dev
    │   ├── <app-name-1>
    │   │   ├── Chart.yaml
    │   │   └── values.yaml
    ├── mgmt
    │   ├── <mgmt-app-name>
    │   │   ├── Chart.yaml
    │   │   └── values.yaml
    ├── prod
    │   ├── <app-name-1>
    │   │   ├── Chart.yaml
    │   │   └── values.yaml
    └── stage
        └── <app-name-1>
            ├── Chart.yaml
            └── values.yaml

When customers prefer to have the helm charts for their applications reside in the same repository as the application, then we use a SCM Provider generator. This will then look to a standardised path within the repository to detect a folder based on the environment is present. In this method the folder structure is simplified as there is no need for the <app-set-name> or <app-name> directories as this can already be understood from different methods. Repositories can be whitelisted or blacklisted into the SCM Provider checks using labels on the repository or the presence of a directory/file in the repository.

Using either method it is best practice and highly recommended to have a unique helm chart per environment. This allows each environment to be upgraded independantly of each other. This can be very important when making changes to the base helm chart so that it isn't realeased to an environment past where it should be by accident.

Cluster Generator

The Cluster generator is used when the application should be deployed to multiple clusters. One such use case for this feature is when deploying an application that is regionally replication to multiple regions in a cloud environment for availability and scalability.

If complex decision tree's are required for choosing clusters an application version is deployed to, then using the Cluster Decision Resource Generator would be required. This can greatly increase the complexity of deployments and as such the Cluster Decision Resource Generator should be used with caution.

Pull Request Generator

Pull Request generator usage fits well with the style of deploying an application to a "test" environment on the creation of a pull request. This is very useful when making helm chart updates to an application so that it is possible to test the helm charts withing the scope of the pull request. It also fits well with the style of building a test environment for a pull request.

When using this feature, it is possible (and usually desired) to limit which pull requests get deployed using a label on the pull request.

Private Helm Repos

Private OCI helm repositories and more traditional private helm repositories where the base charts of the applications are stored, are supported. Depending on the repository it will vary on which authentication method must be used.

User Login

The ability for users to login to Argo CD can be controlled by an OIDC application or a SAML application as an example. Access levels for users in groups can also be configured an controlled using RBAC. It is not recommended to use local users on the Argo CD instance so that permissions can be easily grouped across "teams".

For a detailed list of configuration options regarding which providers are supported, see the User Management section of the Argo CD documentation.