Implementing Automated Deployment Through a Jenkins Pipeline

1.5 hours
  • 2 Learning Objectives

About this Hands-on Lab

Jenkins Pipeline is a powerful tool for implementing continuous delivery. In order to fully utilize Jenkins Pipeline, you will need to implement an automated deployment. This learning activity will guide you through the process of deploying code as part of a Jenkins pipeline. After completing this exercise, you will have a basic familarity with what automated deployment using Jenkins Pipeline looks like.

Learning Objectives

Successfully complete this lab by achieving the following learning objectives:

Deploy the App to the Staging Server Via the Jenkins Pipeline
  1. Configure the staging and production servers for the Publish Over SSH plugin.
  2. Add a credential to Jenkins called webserver_login to allow Jenkins to authenticate with the web servers. The user has already been created on the web servers with the username deploy and the password jenkins.
  3. Create a Multibranch Pipeline project called train schedule and set it up to build from your GitHub fork.
  4. Create a stage in the Jenkinsfile to deploy the app to the staging server. For an example, check the DeployToStaging stage in the sample solution Jenkinsfile.
  5. Run the build to deploy to the staging server.
Deploy the App to the Production Server Via the Jenkins Pipeline
  1. Create a stage to deploy to production after awaiting user input. For an example, check the DeployToProduction stage in the sample solution Jenkinsfile.
    1. Run the build.
    2. Approve the deployment to production.

Additional Resources

Your team is working on a train schedule app. A Jenkins pipeline has already been created for the app, but all it does right now is run a continuous integration build. The team has asked you to add automated deployments to a staging server and to add a production server to the pipeline. The team has decided to use the master branch of the Git repository to control deployments, so only changes to the master branch should be deployed.

Objectives

Whenever there is a change to the master branch, the pipeline needs to do the following after the CI build is completed:

  • Deploy the application to a staging server.
  • Wait for approval before deploying to production.
  • Once approval is provided, deploy to production.

In order to complete this learning activity, you will need to:

  • Create a fork of the source code at the GitHub repo. You can find a sample solution Jenkinsfile under the example-solution branch.
  • Deploy the app to the staging server via the Jenkins pipeline.
    • Configure the staging and production servers for the Publish Over SSH plugin.
    • Add a credential to Jenkins called webserver_login to allow Jenkins to authenticate with the web servers. The user has already been created on the web servers with the username deploy and the password jenkins.
    • Create a Multibranch Pipeline project called train-schedule and set it up to build from your GitHub fork.
    • Create a stage in the Jenkinsfile to deploy the app to the staging server.
    • Run the build to deploy to the staging server.
  • Deploy the app to the production server via the Jenkins pipeline.
    • Create a stage to deploy to production after awaiting user input.
    • Run the build.
    • Approve the deployment to production.

A few notes about the lab server setup:

  • A systemd service called train-schedule has already been created on both web servers. The train schedule app can be controlled with systemd using commands like systemctl stop train-schedule and systemctl start train-schedule.
  • The train-schedule service expects the application code to be deployed to /opt/train-schedule.
  • A deployment user has already been created on both web servers. It can write to /opt/train-schedule as well as start and stop the train-schedule service. The username is deploy and the password is jenkins. Jenkins can use these credentials in order to perform the deployment.
  • The Publish Over SSH plugin is already installed on the Jenkins server.
  • The Jenkins server listens on port 8080. Train Schedule, once it is deployed, will listen on port 3000.

What are Hands-on Labs

Hands-on Labs are real environments created by industry experts to help you learn. These environments help you gain knowledge and experience, practice without compromising your system, test without risk, destroy without fear, and let you learn from your mistakes. Hands-on Labs: practice your skills before delivering in the real world.

Get Started
Who’s going to be learning?

How many seats do you need?

  • $499 USD per seat per year
  • Billed Annually
  • Renews in 12 months

Ready to accelerate learning?

For over 25 licenses, a member of our sales team will walk you through a custom tailored solution for your business.


$2,495.00

Checkout
Sign In
Welcome Back!

Psst…this one if you’ve been moved to ACG!