today we’ll continue talking about delivery automation of the project in the confines of our blog series about devops approach implementation at jelastic (in case you’ve just joined us, you will need to get acquainted with the first part of this guide – it will give you an insight on what we are up to). in a few words, our goal is to achieve complete automation of an app’s life cycle management during all of its stages and, as a result, being able to fully concentrate on the process of development of new project features, instead of bothering with controlling its further deployments, testing, moving to suitable hardware, etc.

previously, we’ve prepared a background for this task (different hardware sets assigned to every team, configured jenkins continuous integration server and a number of scripts for the deployment behavior management) and now we have everything necessary to proceed. thus, let’s move on and configure the required jenkins jobs for subsequently combining all of them into a single continuous flow.

create jenkins jobs

we’ll start with configuring a set of jobs, which represents the core of our automation. each of them will be devoted for a particular operation, required to be run at the corresponding stage of a project’s lifecycle. as a reminder – 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. herewith, a couple of the initial steps are similar for all of them:

then click ok to proceed to configuration of the appropriate item.

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:

echo “run build $(date)” >> /opt/tomcat/demo/ build.log

/bin/bash /opt/tomcat/demo/ install.sh {dev_user}@example.com {password}

where

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

note: that 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.

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 container within the previous guide ).

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.

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:

clean install jelastic:deploy

note: this is done because the pom.xml file of our project already includes the jelastic 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 jelastic 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:

echo “run tests $(date)” >> /opt/tomcat/demo/ build.log

/bin/bash /opt/tomcat/demo/ runtest.sh

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:

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 jca > cluster > regions section)

save to finish.

qa tests

qa tests – freestyle project , used for running the automated app check-up at the testing stage.

note : 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.

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.

great! everything is prepared now, thus we can check whether our scheme works fine.

сonsecutive manual check-up

let’s see how each of our added jenkins jobs acts. for that, we’ll run them one by one according to the below mentioned flow:

create environment > build and deploy > dev tests > migrate to qa > qa tests > migrate to production

to execute a particular item, click on the triangle icon next to it and select the build now option within the shown context menu:

the progress of processing each job can be tracked either through the jenkins output ( console output option at a particular build’s context menu) or by using the appropriate log files within your jenkins container.

and below you’ll find the list of expected results upon using our scripts:

create environment

wait until the process is finished and check your dev user account.

as you can see, the new environment was successfully created alongside the already running jenkins project.

build and deploy

at this stage maven node builds the .war file based on the sources,  provided with the vcs repo link.

note: that on the very first start the required dependencies are downloaded, thus this deployment can take some time.

as a result, your project will be successfully built and deployed to the environment.

dev tests

in our example, this job just emulates some activity for the proper workflow representation, but when running the real tests, their results can be seen via the console output section (which is accessible through the special menu for the still being handled or the last finished operation).

our qa tests results are similar to these ones and could be tracked in just the same way, thus we’ll skip this step below.

migrate to qa

wait until the process is finished and log into your qa team account.

you’ll see your environment appeared at its dashboard, being automatically transferred from the dev user’s account (with no manual confirmation required thanks to the script used) and simultaneously physically relocated to the test hardware (according to the region label, circled in the image above).

migrate to production

the final step is delivery of the polished, comprehensively tested and ready-to-use project to the customers.

similar to the previous migration operation, it is done in two steps: transferring the ownership and moving the project to the corresponding production hardware.

once we’ve ensured that all of the steps were successfully executed without any errors, the whole process can be further improved through chaining all of the jobs in a single automated workflow. and to make it even more convenient, we’ll use a special jobs’ initiation trigger, that is executed upon every project commit action – this will help to completely exclude the delays dependant on humans and speed up the passing of each new release cycle.

devops approach automation

as we’ve denoted above, the continuous integration assumes the complete process automation without any manual steps involved. in our case, this will result in creating of a new environment upon every significant change made to your project and with the concomitant checking, that it works as expected and is instantly delivered to the target audience.

so, in order to achieve such a tight integration of the operations, that all together constitutes the devops pipeline, let’s combine our jobs into one sequence.

in the appeared field, state the next element of our chain (i.e. build and deploy in this case).

create environment > build and deploy > dev tests > migrate to qa > qa tests > migrate to production

for that, firstly you’ll need to get the url of the create environment job scheduler – right-click on the corresponding icon and choose the copy link address option.

here, you need to:

• paste the copied link to the payload url field
• choose the application/x-www-form-urlencoded option within the content type drop-down list
• remove the secret (if stated)
• select the let me select individual events item at the events’ section and tick the commit comment line

finish with the add webhook button below.

at last, everything is set up and maximally optimized! now, just commit any change to your project and enjoy the fully automated procedure of the new build processing, that starts from the environment creation and finishes with the already working new application at the production stage.

stay tuned with jelastic in order not to miss the next part of the devops article series, where we are going to uncover how to achieve even more automation and implement all of the steps above in just a few clicks! and if you’d like to become one of our valuable partners and benefit from the approach described, start by evaluating our demo platform or just register for a free two-week trial period , choosing among dozens of jelastic installations available world-wide.