Application Groups
Introduction
Application groups in Devtron streamline the deployment of microservices by enabling you to build and deploy multiple applications simultaneously. This feature is particularly beneficial when your microservices are interdependent, as a change in one service often triggers the need to redeploy others.
Note
Only one application group would exist for each environment. You cannot group applications belonging to different environments.
Accessing Application Groups
From the left sidebar, go to Application Groups
Figure 1: Application Group (Beta) You will see a list of environments. Select the environment to view the application group.
Figure 2: List of Environments The application group would contain the applications meant for deployment in the chosen environment.
Figure 3: Sample Application Group
As you can see, it has similar options as available under Applications:
Overview
Build & Deploy
Build history
Deployment history
Configurations
Note
Users need to have View only permission or above (along with access to the environment and applications) to view all the applications within a group.
First, we will walk you through the key features of Application Groups, followed by additional features that will help you perform bulk actions.
Key Features
Building Application Images
The Build & Deploy tab of your application group enables you to trigger the CI builds of one or more applications in bulk.
Select the applications using the checkboxes and click the Build Image button present at the bottom.
Figure 4: Build Option The
Build image
screen opens. Select the application and the commit for which you want to trigger the CI build.Figure 5: Selecting Commit
Tip
Adding image labels can help you quickly locate the container image from the list of images shown in Application Groups.
Similar to application, you can also pass build parameters in application groups before triggering the build.
Go to the Parameters tab.
Figure 6: Parameters Tab Click + Add parameter.
Figure 7: Adding a Parameter Enter your key-value pair as shown below.
Figure 8: Entering Key-Value Pair You may follow the above steps for other applications too, and then click Start Build.
Figure 9: Choosing Commit for Other Application Figure 10: Passing Build Parameters and Triggering Build
The builds will initiate, following which, you can close the
Build image
screen.Figure 11: Triggered Deployment
Note
Users need to have Build and deploy permission or above (along with access to the environment and applications) to trigger the build
Changing Configurations
The Configurations tab of your application group allows you to configure the following:
As shown below, you can handle the configurations of more than one application from a single screen.

Note
Users need to have Admin role or above (along with access to the environment and applications) to change their configuration. Please note, you might not be able to change the values of locked keys in deployment template. Refer Lock Deployment Configuration to know more.
Deploying Applications
The Build & Deploy tab of your application group helps you deploy one or more applications in bulk.
Select the applications using the checkboxes.
Figure 13: Deploy Option You can also trigger Pre-deployment stage or Post-deployment stage for your applications in bulk.
To trigger Pre-deployment stage, click the droupup next to Deploy and select Trigger Pre-deployment stage.
To trigger Post-deployment stage, click the droupup next to Deploy and select Trigger Post-deployment stage.
Figure 14: Triggering Pre/Post Stages
Note
The dropup appears only if your workflow has Pre-deployment stage or Post-deployment stage configured for the selected environment.
If both stages are configured, the dropup will display options for triggering Pre-deployment and Post-deployment stages.
If only one stage is configured, the dropup will show the option for triggering that specific stage.
After selecting the applications, click the Deploy button present at the bottom.
Figure 15: Clicking 'Deploy' Select the desired container image that you want to deploy for respective application.
Figure 16: Selecting Image Repeat the step for other applications too.
Figure 17: Deploying Apps If you wish, you can deploy all applications in an Application Group using a single deployment strategy, select the preferred deployment strategy for all the applications and click Deploy. By default, all applications will be deployed using their respective default strategies.
Figure 18: Selecting Deployment Strategy Deployment feasibility page will open, in case for any application, the selected deployment strategy is not configured, you can select one of the configured strategies for that application. If you do not select a configured deployment strategy, deployment will be skipped for that particular application.
Figure 19: Deployment Feasibility The deployment will be initiated, following which, you can close the screen as shown below.
Figure 20: Triggered Deployment Once the deployment is successful, the pipelines will show
Succeeded
.Figure 21: Successful Deployment
Note
Users need to have Build and deploy permission or above (along with access to the environment and applications) to initiate the deployment
Managing Traffic
While deployment, Devtron allows you to manage your Canary and Blue-Green deployments by providing visibility and easy controls to manage how new versions (releases) are shared with users.
To do so, follow the below steps:
Go to Overview and click Manage Traffic.
Figure 22: Selecting Managing Traffic Select the required applications, a side window will appear displaying all the eligible rollouts.
You can take the following actions based on the deployment strategy of the application
For Canary Deployments, you can either choose to initiate the next step or to initiate the full rollout.
Figure 23: Selecting Action for Canary Deployments For Blue Green deployments, you can either choose to Swap Traffic, or you can choose Skip & Promote Full.
Swap Traffic: This will swap the traffic from the current deployment to the application latest deployment.
Figure 24: Selecting 'Swap Traffic' Skip & Promote Full: While deploying, this will directly deploy the whole traffic to application latest deployment.
Figure 25: Selecting 'Skip & Promote Full'
Click Initiate Eligible Rollouts to implement the actions.
Figure 26a: Clicking 'Initiate Eligible Rollouts' Figure 26b: Rollout Status
Additional Features
This feature aims at helping the user clone existing CI/CD pipelines for new target environments in multiple applications. The configurations present in the given CI/CD pipeline also get copied to the cloned pipelines (refer the below table).
Clones the source’s workflow CI as it is
Cloned, including Pre-CD and Post-CD scripts/plugins
Cloned, including Deployment Template (DT), ConfigMap (CM), and Secret
Not cloned
Cloned if at pipeline level,ignored if global
Not cloned (handled globally)
Cloned (handled at pipeline level)
Not cloned (handled globally)
Not cloned
Not cloned
Cloned at pipeline level, ignored if global
Not cloned
Not cloned
Not cloned
Not cloned
Use Case: Let's say you have 'n' number of apps deployed to a development environment named dev-env
. Later, a few testers joined your team, thus necessitating the addition of a testing environment (test-env
) with those same apps deployed. Manually creating the pipelines and configuring them for test-env
environment in each app might be impractical. Therefore, we recommend you to use the cloning feature.
Methods of Cloning
This feature gives you two methods of cloning:
New Workflow: Creates a new workflow and clones the source CI and CD pipeline. Gives you the flexibility to tweak the cloned CI (e.g., changing code branch for build) too.
Figure 27: New Workflow Source Workflow: Uses the same workflow and clones only the source CD pipeline, thus keeping the original CI pipeline unchanged.
Figure 28: Source Workflow
Steps to Clone Pipelines
Go to Application Groups and click the source environment from the list.
Figure 29: Source Environment Selection Select the applications whose pipelines you wish to clone.
A floating widget will appear at the bottom. Click the
â‹®
menu and then click Clone Pipeline Config.Alternatively, you may access Clone Pipeline Config from the
â‹®
menu next to the application name.
Figure 30: Choosing Applications From the dropdown, select the target environment for which pipelines should be created for selected applications.
Figure 31: Selecting Target Environment Select the workflow where you wish to create deployment pipeline: New Workflow or Workflow as source environment. Refer Methods of Cloning to know which option will fulfill your requirement.
Figure 32: Creating CD Pipeline in Workflow Click Clone in new workflow or Clone in source workflow (depending on the option you selected in the previous step).
Figure 33: Initiating Clone
Note
The cloning process will skip if a CD pipeline (for the target environment) already exists in the chosen application's workflow. You can view this in the clone status generated after the above process.
Hibernating and Unhibernating Apps
Who Can Perform This Action?
Users need to have Build & deploy permission or above (along with access to the environment and application) to hibernate or unhibernate applications.
Since every application comes with an option to hibernate, the same is true for application groups. Using application group, you can hibernate one or more applications belonging to the same environment if you do not want them to consume resources (replica count will be set to 0).
In other words, you can hibernate running applications or unhibernate hibernated applications as per your requirement.
Hibernation Process
In the Overview page of your application group, use the checkboxes to choose the applications you wish to hibernate.
A floating widget will appear at the bottom. Click the Hibernate button.
Alternatively, you may access Hibernate from the
â‹®
menu next to the application name.
Figure 34: Selecting Apps to Hibernate Confirm the hibernation by clicking Hibernate.
Figure 35: Confirming Hibernation Hibernation will initiate as shown below. You may close the window.
Figure 36: Initiation Status of Hibernation
Your applications pods would be scaled down and would stop incurring costs.
Note
The hibernation process will show the status as
Skipped
for the applications which are already hibernated.The hibernation process will show the status as
Failed
for the applications which have no deployment history.
Unhibernation Process
In the Overview page of your application group, use the checkboxes to choose the applications you wish to unhibernate.
A floating widget will appear at the bottom. Click the Unhibernate button.
Alternatively, you may access Unhibernate from the
â‹®
menu next to the application name.
Figure 37: Selecting Hibernated Apps to Unhibernate Confirm the unhibernation by clicking Unhibernate.
Figure 38: Confirming Unhibernation Unhibernation will initiate as shown below. You may close the window.
Figure 39: Initiation Status of Unhibernation
Your applications would be up and running in some time.
Note
The unhibernation process will show the status as
Skipped
for the applications which are already running.The unhibernation process will show the status as
Failed
for the applications which have no deployment history.
Restart Workloads
Who Can Perform This Action?
Users need to have Build & deploy permission or above (along with access to the environment and application) to restart workloads in bulk.
Restarting workloads might be necessary if you want your new code or configuration to come into effect, or you are experiencing issues like crashing of pods.
Using application group, you can select the workloads (i.e., Pod, Deployment, ReplicaSet, etc.) of specific applications and restart them.
In the Overview page of your application group, use the checkboxes to choose the applications you wish to restart.
A floating widget will appear, click the Restart Workloads button.
Alternatively, you may access Restart Workload from the
â‹®
menu next to the application name.
Figure 40: Selecting Apps to Restart Next to the application, click the workload dropdown to view all the individual workloads of an application. Choose only the ones you wish to restart.
Figure 41: Choosing Workloads Moreover, you can easily select, deselect, or choose multiple workloads as shown below.
Figure 42: Selecting and Unselecting Workloads Click Restart Workloads.
Figure 43: Restarting Workloads
Restarting workloads might take time depending on the number of applications.
Filtering Applications
Assume you have multiple applications (maybe 10, 50, 100, or more) showing up in an application group. If you want to limit your operations (build/deploy/other) to a specific set of applications, the filter feature will help you narrow down the list. Thus, you will see only those applications you select from the filter (be it on the Overview page, Build & Deploy page, and so on.)
Click the filter next to the application group as shown below.
Figure 44: Filter Option The filter will show all the applications present in the group. Click to select the relevant ones.
Figure 45: All Apps The filter narrows down the list of applications as shown below.
Figure 46: Filtered Apps (Optional) If required, you can save the filter for future use by clicking Save selection as filter.
Figure 47: Saving a Filter Add a name and description to the filter to help you know its purpose, and click Save.
Figure 48: Naming a Filter
Now when you access the application group, your saved filter will be visible on top.

Permissions
1. Creating a filter
Users can create a filter if they have Admin/Manager access on all selected applications.
Case 1: User has Admin/Manager access on all selected applications
User will be able to create a filter with all selected applications.
Case 2: User does not have Admin/Manager access on all selected applications
User will not be able to create a filter.
Case 3: User selected 4 applications but has Admin/Manager access for only 2 of them
User should be able to create filter with these 2 applications.
2. Editing a saved filter
Users can edit a saved filter if they have Admin/Manager access on all applications in the saved filter.
3. Deleting a saved filter
Users can delete a saved filter if they have Admin/Manager access on all applications in the saved filter.
Changing Branch
Who Can Perform This Action?
Users need to have Admin role or above (along with access to the environment and applications) to update their branch.
Assume you have a few applications whose build pipelines fetch from the main
branch of your code repository. However, you decided to maintain a master
branch, and you want all the upcoming CI builds to consider the master
branch as the source. Devtron provides you the option to change the branch at both levels, individual application as well as application group.
In the Build & Deploy tab of your application group, select the intended applications and click the Change Branch button present at the bottom.
Figure 50: Changing Branch Enter the new branch name. If your build pipeline has
Branch Regex
as the Source Type, you must ensure your new branch name matches the regex (regular expression) provided in that build pipeline. Once done, click Update Branch.Figure 51: Updating Branch Name
Changing Image Source
Who Can Perform This Action?
Users need to have Admin role or above (along with access to the environment and applications) to update their branch.
The Change Image Source feature in Devtron lets you update the container image source for an application’s workflow without modifying it.
In the Build & Deploy tab of your application group, select the preferred workflows and click the Change Image Source button present at the bottom.
Figure 52: Clicking 'Change Image Source' Select the preferred Workflow template, and enter the required details as per the workflow template. Currently, Change Image Source feature for Application Groups is only supported for Build from Source Code and Sync with Environment.
Build from Source Code
After selecting Build from Source Code, a feasibility check will run. You can click Create Build Pipeline only if the application's feasibility shows
Can change
.Note: Application for which the feasibility shows
Cannot change
will be skipped due to following reasons:Multi git material found at the source, not allowed to change the source
No cd pipeline found for the selected app and env combination
Invalid request, trying to create self loop, cannot create sync-cd source pipeline with source environment in same workflow
Figure 53a: Selecting 'Build From Source' Figure 53b: Feasibility Window A pop-up window will open, enter the Source Type and Branch under Select code source.
Figure 54: Entering Required Details Click Create Pipeline. A modal window will appear showing the status of the image source change.
Figure 55: Clicking 'Create Pipeline'
Sync with Environment
After selecting Sync with Environment, a modal window will open.
Figure 56: Selecting Sync With Environment Select the environment from which you want to sync your workflow, and then click Next.
Figure 57: Selecting Environment A feasibility check will run. You can click Change Image Source only if the application's feasibility is marked as
Can change
.Note: Application for which the feasibility shows
Cannot change
will be skipped due to following reasons:Multi git material found at the source, not allowed to change the source
No cd pipeline found for the selected app and env combination
Invalid request, trying to create self loop, cannot create sync-cd source pipeline with source environment in same workflow
Figure 58: Feasibility Window Click Change Image Source. A modal window will appear showing the operation status.
Figure 59: Clicking 'Change Image Source'
The image source is applied to all selected workflows where the feasibility check passed.
Last updated
Was this helpful?