Deployments can be rolled back manually. After a deployment is completed, you can manually rollback to a previously deployed image by retaining the same configuration or changing the configuration.
As an example, You have deployed four different releases as follows:
| Image | Configuration | Release |
|---|---|---|
If you want to roll back from V3 image to V2 image, then you have the following options:
| Configuration Option | Image | Configuration |
|---|---|---|
Select Rollback in your deployed pipeline.
On the Rollback page, select a configuration to deploy from the list:
Once you select the previously deployed image and the configuration, review the difference between Last Deployed Configuration and the selected configuration.
Click Deploy.
The selected previously deployed image will be deployed.
Note:
There will be no difference in the configuration if you select Last deployed config from the list.
When you select Config deployed with selected image and if the configuration is missing in the selected previously deployed image, it will show as Config Not Available. In such cases, you can select either Last saved config or Last deployed config.
| Configurations | Description |
|---|---|
Last saved config
Deploy the image with the latest saved configuration.
Last deployed config
Deploy the image with the last deployed configuration. As an example: The configuration C3.
Config deployed with selected image
Deploy the configuration which was deployed with the selected image. As an example: The configuration C2.
V1
C1
R1
V2
C2
R2
V3
C2
R3
V3
C3
R4
V3
C4 (saved but not deployed)
-
Config deployed with selected image
V2
C2
Last deployed config
V2
C3
Last saved config
V2
C4
Typically in a CI pipeline, you build container images, and the number of images gradually increases over a period of time. Devtron's image labels and comments feature helps you to mark and recall specific images from the repository by allowing you to add special instructions or notes to them.
For example:
You can label an image as non-prod to indicate that it is meant for 'Dev' or 'QA' environments, but not for production.
Add hotfix image only label to indicate a one-time patch on production.
Comments like This image is buggy and shouldn't be used for deployment to caution other users from deploying an unwanted image.
Such labels and comments will be visible only within Devtron, and will not propagate to your container registry (say Docker Hub), unlike custom image tag pattern. You may use it to simplify the management and selection of container images for deployment.
Tagging labels and comments are supported only for images in workflows with at least one production deployment pipeline. In Devtron, you can go to Global Configurations → Clusters & Environments to identify a production environment by checking the 'Prod' label.
Users need to have Build & deploy permission or above (along with access to the environment and application) to add labels and comments.
You can add labels and comments from the following pages:
From Deployment History (only after deployment)
From App Details (only after deployment)
You can add multiple labels to an image. but each label can be used only once 'per image, per application'. You may use it in an image of other application though. Refer Deleting Labels if you commit a mistake while adding labels.
Users need to have Build & deploy permission or above (along with access to the environment and application) to perform soft deletion of labels.
This action marks the label as invalid but doesn't delete the label. Therefore, you can recover it again but you cannot reuse it for other image (unless it's a different application).
Click the edit option.
Use the (-) icon to strike off the label. This icon is available on the left-side of a label.
Click Save.
This action deletes the label permanently and makes it available for reuse in same/other image of the given application.
Click the edit option.
Use the (x) icon to permanently remove the label. This icon is available on the right-side of a label.
Click Save.
Users need to have Build & deploy permission or above (along with access to the environment and application) to remove comments.
If you wish to permanently remove a comment, do the following:
Click the edit option.
Empty the content of an existing comment.
Click Save.
If you use Application Groups to deploy in bulk, image labels (if added) will be available as filters for you to quickly locate the container image.
This will be helpful in scenarios (say release package) where you wish to deploy multiple applications at once, and you have already labelled the intended images of the respective applications.
Each time you push a change to your application through GitHub, your application goes through a process to be built and deployed.
There are two main steps for building and deploying applications:
You can also rollback the deployment. Refer for detail.
After the CI pipeline is complete, you can trigger the CD pipeline.
Go to the Build & Deploy tab of your application and click Select Image in the CD pipeline.
Select an image to deploy and then click Deploy to trigger the CD pipeline.
However, if an image is already deployed, you can identify it by the tag Active on <Environment name>.
When manual approval is enabled for the deployment pipeline configured in the workflow, you are expected to request for an image approval before each deployment. Alternatively, you can deploy images that have already been approved once.
If no approved images are available or the current image is already deployed, you won't see any images for deployment when clicking Select Image.
Users need to have Build & deploy permission or above (along with access to the environment and application) to request for an image approval.
To request an image approval, follow these steps:
Navigate to the Build & Deploy page, and click the Approval for deployment icon.
Click the Request Approval button present on the image for which you want to request an approval and click Submit Request.
In case you have configured SES or SMTP on Devtron, you can directly choose the approver(s) from the list of approvers as shown below.
The users you selected will receive an approval request via email. Any user with 'Image approver' permission alongwith access to the given application and given environment would be able to approve the image.
In case you wish to cancel the image approval request, you can do so from the Approval pending tab as shown in the below image.
If you've received an approval but no longer want the image to be deployable, you can let the approval expire.
By default, super-admin users are considered as the default approvers. Users who build the image and/or request for its approval, cannot self-approve it even if they have super-admin privileges.
Users with Approver permission (for the specific application and environment) can also approve a deployment. This permission can be granted to users from User Permissions present in Global Configurations.
In case SES or SMTP was configured in Devtron, and the user chose the approvers while raising an image approval request, the approvers would receive an email notification as shown below:
To approve an image approval request, follow these steps:
Go to the Build & Deploy page and click the Approval for deployment button.
Switch to the Approval pending tab. Here, you will get a list of images that are awaiting approval.
Click Approve followed by Approve Request button.
Users need to have Build & deploy permission or above (along with access to the respective environment and application) to select and deploy an approved image.
In case the super-admin has set the minimum number of approval to more than 1 (in workflow), you must wait for all approvals before deploying the image. In other words, partially approved image will not be eligible for deployment.
To deploy an approved image, follow these steps:
Navigate to the Build & Deploy tab and click Select Image.
You will find all the approved images listed under the Approved images section. From the list, you can select the desired image and deploy it to your environment.
You can view the status of current deployment in the App Details tab.
The status initially appears as Progressing for approximately 1-2 minutes, and then gradually transitions to Healthy state based on the deployment strategy.
Here, our CD pipeline trigger was successful and the deployment is in Healthy state.
To further diagnose the deployments, click here
To trigger the CI pipeline, first you need to select a Git commit. To select a Git commit, click the Select Material button present on the CI pipeline.
Once clicked, a list will appear showing various commits made in the repository, it includes details such as the author name, commit date, time, etc. Choose the desired commit for which you want to trigger the pipeline, and then click Start Build to initiate the CI pipeline.
CI Pipelines with automatic trigger enabled are triggered immediately when a new commit is made to the git branch. If the trigger for a build pipeline is set to manual, it will not be automatically triggered and requires a manual trigger.
CI builds can be time-consuming for large repositories, especially for enterprises. However, Devtron's partial cloning feature significantly increases cloning speed, reducing the time it takes to clone your source code and leading to faster build times.
Advantages
Smaller image sizes
Reduced resource usage and costs
Faster software releases
Improved productivity
Get in touch with us if you are looking for a way to improve the efficiency of your software development process.
The Refresh icon updates the Git Commits section in the CI Pipeline by fetching the latest commits from the repository. Clicking on the refresh icon ensures that you have the most recent commit available.
The Ignore Cache option ignores the previous build cache and creates a fresh build. If selected, will take a longer build time than usual.
If you wish to pass runtime parameters for a build job, you can provide key-value pairs before triggering the build. Thereafter, you can access those passed values by referencing the corresponding keys in the environment variable dictionary.
Steps
Go to the Parameters tab available on the screen where you select the commit.
Click + Add parameter.
Enter your key-value pair as shown below.
Similarly, you may add more than one key-value pair by using the + Add Parameter button.
Click Start Build.
Click the CI Pipeline or navigate to the Build History to get the CI pipeline details such as build logs, source code details, artifacts, and vulnerability scan reports.
To access the logs of the CI Pipeline, simply click Logs.
To view specific details of the Git commit you've selected for the build, click on Source. This will provide you with information like the commit ID, author, and commit message associated with that particular commit.
By selecting the Artifacts option, you can download reports related to the tasks performed in the Pre-CI and Post-CI stages. This will allow you to access and retrieve the generated reports, if any, related to these stages. Additionally, you have the option to add tags or comments to the image directly from this section.
Users need to have or above (along with access to the environment and application) to pass build parameters.
In case you trigger builds in bulk, you can consider passing build parameters in .
To check for any vulnerabilities in the build image, click on Security. Please note that vulnerabilities will only be visible if you have enabled the Scan for vulnerabilities option in the advanced options of the CI pipeline before building the image. For more information about this feature, please refer to this .
