Deploy to Production

In this article, we explain how to deploy an application to production effectively. This guide builds on previous stages, including:

• Deployed an AWS EC2 VM
• Conducted integration testing
• Created a pull request
• Deployed the application to Kubernetes using GitOps with Argo CD
• Executed OWASP ZAP security tests

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.

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'
        }
    }
}

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:

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:

When the pipeline reaches the deploy stage, Jenkins displays a prompt for production deployment approval:

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.

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:

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:

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!