Docs menu
MENU

Setting Jenkins Jobs

Once the background for our DevOps workflow implementation (i.e., different hardware sets assigned to every team, configured Jenkins continuous integration server and a number of scripts for the deployment behavior management) is prepared, we are good to proceed with the Jenkins Jobs setting.

1

Each of the jobs will be devoted to a particular operation, required to be run at the corresponding stage of a project’s lifecycle. Here is the suggested processes chain:

Create Environment > Build and Deploy > Dev Tests > Migrate to QA > QA Tests > Migrate to Production

We’ll add all these jobs one by one. A couple of the initial steps are similar for all of them:

1. Click on the New item option at the left-hand menu.

2

2. In the appeared form, specify the Item name and select the appropriate project type using the corresponding radio button (these settings will be described in detail for each of the jobs below):

3

Then click OK to proceed to configuration of the appropriate item:

Tip: Subsequently, after all of these jobs are prepared, you can check whether each of them works as intended and, eventually, automate the whole workflow through building the jobs' chain.

Create Environment

Create Environment - Freestyle project, that creates a new environment according to the specified install script.

Find the Build section, expand the Add build step list and select the Execute shell option there. Then enter the following commands into the appeared field:

1
2

echo "run build $(date)" >> /opt/tomcat/demo/build.log
/bin/bash /opt/tomcat/demo/install.sh {dev_user}@example.com {password}

where:

  • /opt/tomcat/demo/ - path to the scripts folder, created scripts guide (this is the one we use as an example, while you should substitute it with your own path in case it differs)
    Note: The same path will be used for all the rest of the jobs, thus we’ll skip this point in the following instruction sections - please, do not forget to specify it within all the corresponding commands.
  • {dev_user}@example.com - login (email address) of your development team account
  • {password} - the corresponding user’s password

4

Note: If your account name contains any special characters, they should be substituted using the URL encoding.

Save to create the job.

Build and Deploy

Build and Deploy - Maven project, that will build your source code and deploy an app by means of the already added Maven node.

Find the Source Code Management section, choose the VCS type of your project (we are using Git repo with a simple HelloWorld app for this tutorial) and specify the Repository URL in the expanded field.

5

A bit lower, in the Build Environment section, tick the Set environment variables through a file option and type the path to the corresponding file you’ve created for this purpose (at the last step of the configuration instruction for a Jenkins scripts preparation).

6

Then, scroll down to Post Steps and click on the Add post build step expandable list, where you need to choose the Invoke top-level Maven targets option.

7

Among the proposed variants within the Maven Version list, select the one you’ve created during Jenkins configurations (named Maven in our case), and fill in the Goals field with the following command:

1

clean install jelastic:deploy

Tip: This is done because the pom.xml file of our project already includes the Maven plugin, designed to automatically deploy the already built .war file to our environment. You can either use the linked guide to adjust your own project’s deployment in the same way or, if you’d like to test the automation itself, just fork our repo and modify the following strings inside the main Maven config file (i.e., the mentioned above pom.xml) according to your data:

  • {dev_user}@example.com - login (email address) of the dev user’s account
  • {password} - password for the user, specified above
  • {cloud_domain} - domain name of your platform

Click Save to finish.

Dev Tests

Dev Tests - Freestyle project, that is intended to run the first set of tests, still at the development stage.

Select the Execute shell option within the Build section and state the following commands:

1
2

echo "run tests $(date)" >> /opt/tomcat/demo/build.log
/bin/bash /opt/tomcat/demo/runtest.sh

8

Save to add this job.

Migrate to QA

Migrate to QA - Freestyle project, that will convey the ownership of your environment to the QA team and physically move it to the dedicated set of hardware for them.

Scroll to the Build section, again choose the Execute shell option and enter the following commands in the appeared field:

1
2
3

echo "run build $(date)" >> /opt/tomcat/demo/build.log
/bin/bash /opt/tomcat/demo/transfer.sh {dev_user}@example.com {password} {qa_user}@example.com
/bin/bash /opt/tomcat/demo/migrate.sh {qa_user}@example.com {password} {destination_hn_group}

where:

  • {dev_user}@example.com - login (email address) of your development team account
  • {qa_user}@example.com - same for the QA team account
  • {password} - the corresponding user’s (specified prior to this) password
  • {destination_hn_group} - an unique name of the hardware set, the migration should be performed to (can be seen at your admin panel’s Cluster > Regions section)

9

Save to finish.

QA Tests

QA Tests - Freestyle project, used for running the automated app check-up at the testing stage.

Tip: In our case, this job’s configuration is completely similar to the Dev Tests one. However, during the real development process, these sets of tests may vary - in this case you’ll need to specify another dedicated bash script here.

10

Migrate to Production

Migrate to Production - Freestyle project, similar to the Migrate to QA one, that will transfer the environment ownership from QA to the production team and physically migrate it to the corresponding hardware set.

11

What’s next?