# JFrog Internal Generic Helm Chart

## Testing new changes and features
On saas-configuration staging environment, there is a jdemo.yaml under jfrogdeployment folder.

Run the local changes before pushing to master.

```
$ jfrog_application chart_deploy jdemo
```

## Enabling and Using the Canary Request Job Analysis Template

The canary request job analysis template allows you to gradually increase the number of users exposed to a new canary version by updating router with a valid canary header.

### How to Enable

**Configure your rollout strategy to gradually increase canary traffic:**

    ```yaml
    rolloutStrategy:
      canary:
        steps:
          - setAccountWeight:
              weight: 20
              type: enterprise_trial
          - pause:
              duration: 10m
          - setAccountWeight:
              weight: 40
              type: enterprise_trial
          - pause:
              duration: 10m
          - setAccountWeight:
              weight: 100
              type: enterprise_trial
          - pause:
              duration: 10m
    ```
   
Each `setAccountWeight` step in your canary rollout strategy defines how much customers (by percentage) is routed to the canary version for a specific account type and region. Here’s what happens at each step:

- **Helm Rendering:**  
  The `setAccountWeight` step calls a helper in `_helpers.tpl` during Helm rendering. This helper generates the canary request job template using the provided `weight` and `type`.
  > Advanced:  
  > You can also optionally specify `interval` and `timeout` for each step.
  > - `timeout` (the wait time for the canary header change)
  > - `interval` (the interval at which the job checks the status of the canary header change)

- **Additional Arguments:**  
  When `saas-deployer` executes the `helm upgrade` command, it injects two additional arguments:
  - `region` (the deployment region)
  - `mt-service` (the microservice name)  
  These are used in `_helpers.tpl` to generate the correct canary request job.

- **Job Creation:**  
  At each `setAccountWeight` step, a new canary request job is created with the specified parameters. This job updates canary manager service and in the end the router service is updated with the correct canary header.

- **Pause:**  
  This step shows that the user can inject more steps between weight changes if needed.
  After each weight change, a `pause` step allows time for monitoring and analysis before proceeding to the next increment.

This mechanism ensures a controlled and observable rollout, gradually increasing canary exposure and collecting data at each stage.

### Canary Manager Configuration Keys

The following keys are used to configure the canary request job and are required for integration with the canary manager service. These values are injected automatically by the `saas-deployer` service during the Helm upgrade process. **Users should not set these values manually in their own values files.**

- **canaryServiceName**: The name of the microservice being deployed.
- **canaryRegion**: The deployment region for the canary rollout.
- **canaryManagerEndpoint**: The endpoint URL of the canary manager service.
- **canaryManagerUsername**: The username used to authenticate with the canary manager service.
- **canaryManagerPassword**: The password used to authenticate with the canary manager service.
- **canaryRequestJobImage**: The container image used for the canary request job.
- **rolloutStrategy.canary.canaryByHeader.canaryByHeaderValue**: Canary header value taken from the cell config.
