Application Promotion in Devtron

In the constantly evolving landscape of building and deploying applications, continuous integration (CI) and continuous deployment (CD) pipelines have played a crucial role in ensuring that software is built, tested, and deployed reliably. Traditional pipelines included building the application’s executable binary files and deploying them to a VM.

However, the entire DevOps landscape transforms fundamentally as organizations move towards a cloud-native system, with Kubernetes at the forefront. While Kubernetes addresses many of the challenges with scaling applications, it also introduces its own set of complexities and challenges. With the addition of GitOps, the entire CI and CD landscape becomes even more complex.

Moreover, within cloud-native environments, the application usually needs to be deployed across multiple environments, such as dev, QA, UAT, and production. GitOps tools such as ArgoCD can sync the cluster's state with the state defined within the Git repository. However, they fail to promote the application across multiple environments. 

Devtron has introduced a new feature that allows you to progressively promote your applications across different environments seamlessly while ensuring that all the necessary checks have passed. Before diving more into the intricacies of how Devtron can help you promote applications, let’s understand the need for application promotion.

What is Application Promotion?

Application promotion is the process of progressively deploying an application through the different environments of the software deployment pipeline, such as the development, QA, staging, and production environments. This progression of the application through multiple environments helps ensure that the application runs smoothly and that the features and changes are thoroughly validated through multiple environments. The application can progress to the next environment after meeting certain requirements such as passing test cases.

In a cloud-native application, multiple microservices need to be deployed in a scalable and flexible way. Promoting the application across multiple environments can help simplify the delivery of these microservices while keeping CI/CD as the base. It can also fill the gaps between the CI and CD pipelines to accelerate the software delivery process. The promotion process can be customized to fit your particular use cases.

By promoting the application across all these different environments, you can reduce the risk of facing any potential errors in the application, or misconfigurations, and safeguard against downtime, hence increasing the production stability. This is all possible as the application is deployed and validated across multiple environments before it can ever reach the production environment. Ultimately it helps improve deployment reliability and efficiency by making the deployment more predictable and maintaining a consistent state across environments.

By adopting the application promotion process, several benefits are experienced across the entire CI/CD and GitOps pipelines. Some of these benefits include:

• Improved flexibility and control over deployment pipelines
• Vigorous testing of the application across different environments to ensure that the release to production is stable
• Adopting application promotion helps manage the complexities of multi-environment deployments.
• Enforces standardized practices across the deployment process
• Allows teams to quickly identify bottlenecks and optimize the deployment process.

Limitations of traditional CI/CD

The traditional approach to CI/CD pipelines was straightforward: building, testing, and then deploying the application to the production environment. However, with modern approaches to application deployment, this linear process falls short, as the application has numerous different microservices that have separate build pipelines. The entire application cannot be tested properly until all the microservers are present and running. 

To test the application properly, the services must be deployed to a testing environment, which should be handled by the CD pipeline. Once the application tests pass in the testing environment, certain tests need to be performed to ensure that the application can work under load, for which dummy traffic has to be emulated. After the tests across all these different environments have succeeded, the application is then finally deployed to the production environment. 

The traditional CI/CD process falls short, as the idea was simply to follow a streamlined approach without considering that the application will have to be deployed and validated across multiple different environments.

Moreover, to compensate for the gaps of traditional CI/CD, the CI tools are being overused, even outside the scope of the CI pipelines. Instead of simply handling build talks, CI systems are being used for deployment and promoting the applications to other environments using custom scripting. As the CI tools are not designed to be deployment systems, they fall short in multiple areas for deployment.

While traditional CI and CD mechanisms have worked for legacy systems, they do fall short in several ways when it comes to modern cloud-native systems. Some of the key challenges that one might face include:

• Traditional CI and CD pipelines were built for a linear build, test, and deploy approach for deploying applications. This introduced challenges when you wish to deploy to multiple environments and progressively promote the application
• The CI pipeline is often overused well beyond the scope of Continuous Integration. Organizations write custom scripts to deploy the application as well as progressively promote it across the environments. 
• Managing versions for the different microservices and environmental configurations becomes a challenge, as each environment has its own unique configurations.
• The traditional process also relies heavily on integrating external tools for monitoring and triggering rollbacks, which leads to a tool sprawl, further increasing the deployment complexities.

Challenges with Application Promotion

Promoting an application across multiple different environments has several different challenges associated with it. As we have discussed earlier, many CI systems that are not designed for deployments, are being overused to deploy and promote the application to different environments. This process can be quite error-prone as custom scripts have to be used. The custom scripts may not satisfy all the required conditions and test cases. Additionally, there is no way to trigger a rollback if the deployment has bugs or any error occurs.

As the number of environments scales, the complexity increases as well. There are many environments which the application will have to be promoted through. Some phases may even require you to deploy the application to two environments parallelly. Additionally, there needs to be some governance around these promotions. The application should not be deployed to an environment without explicit approval from the relevant stakeholders.

There also needs to be a proper audit log to track the deployments that have been triggered on each environment, along with their configurations. Managing the configurations across the different environments is also a challenge as the configurations of production are going to be different compared to configurations of environments such as dev or staging.

To sum it up, some of the key challenges that organizations face while trying to promote the applications across different environments include:

• The lack of quick rollback mechanisms for triggering rollbacks in case of application failures in any of the environments.
• Setting up approval gates for multiple environments requires integrating external tools and frameworks which leads to additional tool overhead and added complexity.
• As the number of environments increases, the complexity of promoting the application increases as well. Existing deployment systems fall short when deploying and promoting the application across the environments.
• The lack of a proper audit log makes it difficult to figure out which team triggered a deployment and the configurations that the application is deployed with.
• During the promotion process, every environment has its own configurations. Maintaining unique configurations for each environment and updating as needed can become challenging. Moreover, you may want to prevent updating the configurations from being updated without proper approval.

Application Promotion in Devtron

Devtron is an open-source Kubernetes management platform that helps abstract the entire CI/CD process. It can help create the build (CI) and deployment (CD) pipelines and seamlessly connect them. Devtron can also allow you to create multiple deployment environments and deploy your applications to different environments either sequentially or parallelly.

In the above image, you can see that the web app is being built and first being deployed to the utils environment and parallelly, it is also deployed to the devtron-demo environment. If all the checks in the utils environment pass, the application will get promoted to the staging environment and subsequently to the production environment. Devtron also allows you to apply an approval policy to the different deployments. In case of any failures, Devtron allows for an easy one-click rollback.

Devtron also stores an entire audit log of the deployments that have been triggered across the different environments. You can see all the deployments that have been triggered along with their status, environment-specific configurations, and more. In the below image, you can see the latest deployment for the prod environment. Similarly, you can filter through the different environments that are configured for this particular application.

Managing the configurations for all the different environments can easily become overwhelming and you might end up using the wrong configurations in a specific environment. Devtron streamlines the configuration process and let’s you define the configuration for each environment. You can also lock the configurations, and without approval from the authorized stakeholders, the configurations for the environment cannot be changed.

Many times, organizations might have different teams for handling deployments to different environments. In this case, the environment access has to be restricted to the specific team members. Devtron has robust RBAC capabilities will will let you fine-grain the level of access operations teams have to specific environments. You can set up the RBAC permissions, for each individual environment. Instead of having to apply the same permissions for every single user, you can create a permission group that lets you assign the same set of permissions for all users in a particular team. Please check out the following blog to learn about Devtron’s robust RBAC framework.

Conclusion

Application Promotion can help mitigate any deployment errors well before the application reaches production environments. During the entire deployment process, the application is vigorously tested across multiple different environments to ensure that it functions properly without any errors. 

With Devtron, you can create enterprise grade CI and CD pipelines that follow the GitOps principles and allow you to progressively promote the application across multiple environments. To ensure that only authorized individuals can trigger the deployment or change the environment specific configurations, Devtron also has robust approval policies and RBAC.  Additonally, Devtron provides an entire audit log for viewing the deployment history, along with the configurations across all the environments in the pipeline.