Skip to main content
In this article, we explain how to deploy an application to production effectively. This guide builds on previous stages, including: For the main branch deployment, we introduce an approval stage that requires admin confirmation before initiating the AWS Lambda deployment. The diagram below illustrates our deployment approach—from a feature branch through continuous deployment, to a pull request with continuous delivery, and finally to the main branch with a serverless deployment.
The image illustrates a deployment approach, showing a flow from a feature branch through continuous deployment, a pull request with continuous delivery, and finally to the main branch with serverless deployment.
After an admin approves the stage, the deployment to Lambda begins, followed by an update to the Lambda configuration and execution of tests on AWS Lambda functions. These stages are only executed when changes or new pushes are made to the main branch. Below is how to update your Jenkinsfile to include an approval stage that is only accessible by an admin. While working on your feature branch, locate the section just after the AWS S3 upload stage where an input stage exists. Originally, the Jenkinsfile staged steps similar to: 
stage('Integration Testing - AWS EC2') {
}

stage('K8S - Update Image Tag') {
}

stage('K8S - Raise PR') {
}

stage('App Deployed?') {
}

stage('DAST - OWASP ZAP') {
}

stage('Upload - AWS S3') {
}

post {
    always {
    }
}
We now add the new deployment stage after the S3 upload. Replace the previous input stage with the following production deployment stage: 
stage('Deploy to Prod?') {
    when {
        branch 'main'
    }
    steps {
        timeout(time: 1, unit: 'DAYS') {
            input message: 'Deploy to Production?', ok: 'YES! Let us try this on Production', submitter: 'admin'
        }
    }
}
  • The when condition ensures this stage only runs on the main branch.
  • A one-day timeout provides ample time for the admin to approve.
  • The input step presents a confirmation message with a custom OK button.
  • The submitter parameter restricts approval to those belonging to the admin group.
For added security, you can restrict the stage to a specific user or group by modifying the submitter field, as shown in the snippet below generated by Jenkins’ Declarative Directive Generator: 
input {
  message 'give some message'
  submitter 'admin'
}
After committing these changes to your feature branch, a new pipeline will be triggered. Since the branch is not main, the deploy-to-production stage is skipped. Once you merge these changes into the main branch via your pull request, a new build for the main branch will trigger. The image below shows the code repository interface with commit messages, including the updated Jenkinsfile with the new “Deploy to Prod?” stage:
The image shows a code repository interface with a list of files and their commit messages, including a highlighted option to "Deploy to Prod?" for a Jenkinsfile.
Upon merging, the main branch build initiates and runs the prescribed stages. It is important to note that several stages (such as AWS EC2 deployment, integration testing, Kubernetes update, ArgoCD deployment, and AWS S3 upload) are skipped because they are intended for feature or pull request branches. Instead, the pipeline pauses at the deploy-to-production stage awaiting admin approval. You can monitor the pipeline using the Blue Ocean UI:
The image shows a Jenkins dashboard displaying a list of pipeline activities for the "solar-system" project, including details like commit IDs, branches, messages, durations, and completion times.
When the pipeline reaches the deploy stage, Jenkins displays a prompt for production deployment approval:
The image shows a Jenkins pipeline interface for a project named "solar-system" with various stages like installing dependencies, unit testing, and deploying to AWS. It includes a prompt asking whether to deploy to production, with options to proceed or abort.
For demonstration purposes, the pipeline was manually stopped before complete execution. In a real-world scenario, if status checks are enabled and a build fails (for example, due to a manually stopped stage), merging will be prevented until a successful status is reported. After merging, reviewing the pull request interface shows that all changes are present. Despite potential build issues indicated by status checks due to the halted build, merging may still proceed if status checks are not enforced.
The image shows a pull request interface with reported errors and options to create a merge commit. It indicates issues with the build and mentions that the pull request can be merged automatically.
Once merged into the main branch, a build with run ID “1” is initiated. As the deployment reaches the deploy-to-production stage, it waits for input approval. In our configuration, only an admin user (e.g., Siddharth) can provide this approval. To illustrate the security mechanism:
  1. When logged in as an admin, the deploy-to-production stage accepts the input and the build proceeds.
  2. If a non-admin user (e.g., EMA from the developer group) attempts to approve the stage, Jenkins denies the action. Developer group permissions are set to overall read-only based on the matrix-based security configuration.
Below is a screenshot of the Jenkins security configuration demonstrating that the developer group has limited permissions compared to the admin group:
The image shows a Jenkins security configuration screen with a matrix-based security setup, displaying permissions for different user groups such as admin, developer, manager, and QA. Each group has specific permissions checked across various categories like Overall, Agent, Job, Run, View, SCM, and Metrics.
Additionally, the following image shows the Jenkins pipeline interface under the “Gitea-Organization” project, once again emphasizing that the production deployment stage is paused awaiting admin input:
The image shows a Jenkins pipeline interface for a project named "solar-system" under "Gitea-Organization," displaying various stages of deployment with a prompt to deploy to production.
Once an admin confirms the approval, the pipeline continues. In this demo setup, no stages follow the deploy-to-production stage. In a production-ready environment, additional stages—such as AWS Lambda deployment and subsequent Lambda testing—would typically follow. For demonstration purposes, we are directly editing the Jenkinsfile in the main branch. The next session will cover deploying the application to AWS Lambda using Jenkins. Thank you for reading this guide on deploying to production with Jenkins. Happy deploying!

Watch Video

Practice Lab