feat: Helm async deploy Devtron Apps

[Ash-exp]

Description

• Currently in Devtron Apps with Helm installation, we are performing the Install/Upgrade in synchronous mode. With this flow, in some cases the API context expires as the Install/ Upgrade may take too long. The common cases for this behaviour are:

  • The deployment charts have per or post hooks/ jobs/ heavy resources to build
  • The cluster connection in kubelink takes longer due to the difference in region.

• In this PR we are performing Helm install/ Upgrade for devtron Apps in asynchronous mode. This feature will flag based. Use ENABLE_ASYNC_INSTALL_DEVTRON_CHART (bool) in config map: devtron-cm to enable/disable this feature. Default value is set to false.

  ENABLE_ASYNC_INSTALL_DEVTRON_CHART: "true"
  

• Other Environment flags are: (config map: devtron-cm)

  1. gRPC Timeout For Devtron App Deployment: DEVTRON_CHART_INSTALL_REQUEST_TIMEOUT (in mins) default 6

     DEVTRON_CHART_INSTALL_REQUEST_TIMEOUT: "7"
     

  2. Nats Configuration: CONSUMER_CONFIG_JSON(json) Default natsMsgProcessingBatchSize is 1.

     CONSUMER_CONFIG_JSON: '{"DEVTRON-CHART-INSTALL-DURABLE":{"natsMsgProcessingBatchSize":2}}'
     

Fixes #4264

How Has This Been Tested?

Test Cases:

• Single Deployment:
  • GitOps: (Auto/Manual) // Sanity
    • With Custom charts (enforce pending-install state)
    • With Devtron Reference charts
    • With last deployed config
    • With last saved config
    • With a specific config
  • Helm: (Auto/Manual)
    • With Custom charts (enforce pending-install state)
    • With Devtron Reference charts
    • With last deployed config
    • With last saved config
    • With a specific config
• Env Flag verification (enable/disable)
• Gitops to Helm conversion
• Hibernate and Restore Deployment
• Deploy externally (Cluster CLI), then deploy from UI
• App Group Bulk Deploy UI: (More than 20 application)
• Bulk Deployment API: /orchestrator/batch/v1beta1 (More than 20 application)
• Bulk Hibernate API: (More than 20 application)

Checklist:

• The title of the PR states what changed and the related issues number (used for the release note).
• Does this PR requires documentation updates?
• I've updated documentation as required by this PR.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have tested it for all user roles.
• I have added all the required unit/api test cases.

Does this PR introduce a user-facing change?

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
5 Code Smells

No Coverage information
0.0% Duplication