Using Nerrvana – deployment & Jenkins (part 1)

Using Nerrvana - deployment & Jenkins (part 1)

What is a web application deployment – Jenkins installation and configuration – preparing Jenkins for deployment

Part 1 – Using Nerrvana – our setup
Part 2 – Using Nerrvana – SVN hooks to Jenkins
Part 3 – Using Nerrvana – deployment & Jenkins (part 1) – this post
Part 4 – Using Nerrvana – deployment & Jenkins (part 2)

Let’s talk about deployment. In the most general case, it is a transformation of the source code retrieved from a version control system into a running application. We do not use Jenkins to update our live sites and services yet, but we assume that the deployment for testing is not very different from deployment for upgrade or install. In the latter case, you need to take care of users, informing them in advance about the service downtime, and to give attention to security – access rights to files, the possibility of a rollback automatically in case of failure. These problems do not interest us at the moment anyway. We need to get the application running on an internal server which can be accessed by Selenium tests. Each application will have a slightly different deployment, and we will describe how we deploy, with some simplifications. In the last post of this mini-series, we will show our real configuration, but for now this information will be excessive.

We will need Ant so if it is not installed – install it (yum install ant). Now we can install Jenkins. Jenkins documentation will help us do so.

jen_host#yum install java-1.6.0-openjdk
jen_host#sudo wget -O /etc/yum.repos.d/jenkins.repo
jen_host#sudo rpm --import
jen_host#yum install Jenkins
jen_host#chkconfig jenkins on
jen_host#service jenkins start

So, our web application – Answers is written in PHP. This is not a web service but application you buy, install and use.

The first thing which affects the deployment process is exactly related to the fact that this is not a web service. We have no pre-configured settings file. Instead, we have Settings.class.template.php, which is used by the installer to create the actual file Settings.class.php. In the future, we may write a Selenium script that will install the application acting in a similar way to users who will install Answers. It will produce a configuration file and test install script as well. Oh, what a life it will be! But we do not have it now and we need to somehow create the missing Settings.class.php before testing. For this purpose we created the bash script with ‘sed’ commands inside to make changes in the template and produce a real configuration file. Of course, we could create Settings.class.php for testing and put it in SVN. But then if we add a new parameter in the template configuration, we can forget to add it into the configuration file for tests. I don’t even need to mention the consequences.

The second specific to the deployment feature of our application is the fact that it is designed to be embedded or plugged in to your main product or service. This means it doesn’t have its own login and logout pages. The session is created by the main application, integrating Answers with it. We have created these pages in order to be able to run Selenium tests and put them under project’s version control with all other files related to continuous integration. In the process of deploying an application, we need to move these files to the root folder of the Apache virtual host, a place where tests expect them to be.

By the way, after we began to use Jenkins as CI server and Nerrvana to run Selenium tests, we changed the structure of the version control repository for our projects.

Project structure with dedicated parts for CI and Selenium tests

Fig. 1 Project structure with dedicated parts for CI and Selenium tests

I’ll give the names to two hosts that we will be using to make the post shorter and clearer. jen_host – is where we have Jenkins and depl_host – is where we deploy our web application for Selenium testing.

Thus, our deployment process will include the following steps:

  • get source code from version control after a commit triggered Jenkins build on jen_host
  • create application configuration file on jen_host
  • move login and logout files to the right place on jen_host
  • clean virtual host from the files left from the previous build on depl_host
  • copy prepared for testing Answers package from jen_host tothe virtual host root folder on depl_host
  • recreate the database (after all, its structure could change too) on depl_host

I deliberately left out some nuances to make the overall picture clear right now. Now, knowing what needs to be done, we can configure our two hosts.

I will not describe in detail what is set on depl_host. It has Apache, PHP and MySQL installed.

Now we will make sure that our “jenkins” user could easily get from jen_host to depl_host via ssh. Jenkins already has a private key, which is in /var/lib/jenkins/identity.key. Public key is sent by Jenkins in HTTP headers, but we failed to connect with it, and we have generated another pair.

Jenkins public key is in HTTP headers

Jenkins public key is in HTTP headers

Login to jen_host and generate keys (I did not enter a passphrase).

jen_host#cd /tmp
jen_host#ssh-keygen -f jenkey
jen_host#mv jenkey /var/lib/jenkins/
jen_host#chown jenkins:jenkins jenkey

Now go to depl_host, create user ‘jenkins’ and add him a public key that we have left in the / tmp directory on jen_host.

depl_host#useradd -G apache jenkins
depl_host#cd /home/jenkins
depl_host#mkdir .ssh
depl_host#touch .ssh/authorized_keys
depl_host#chmod 755 .ssh
depl_host#chmod 644 .ssh/authorized_keys
depl_host#chown jenkins:jenkins authorised_keys

Copy the contents of the file we left in /tmp on jen_host to /home/jenkins/.ssh/authorized_keys file. Now we can go back to jen_host and test our config with:

jen_host#ssh jenkins@depl_host -i /var/lib/jenkins/jenkey

Go http://jen_host:8080/manage. Here we will be interested in installing plug-ins and general Jenkins settings.

We need the ‘Publish Over SSH’ plug-in. Go to page http://jen_host:8080/pluginManager/available, select the tab ‘Available’, enter in the search field (top right corner) ‘ssh’ and do not hit enter, wait for Ajax to bring you results. Select the checkbox of the plug-in we are installing and, if you have a large display, drop the eye down where two buttons are – ‘Install without restart’ or ‘Download now and install after restart’.

Do not miss buttons on a big screen

Do not miss buttons on a big screen

Now it is time to configure the global Jenkins settings – page http://jen_host:8080/configure. Do not be afraid of the size of the form. All we need to do is to add the parameters the SSH server of our depl_host. In the section ‘SSH’ press the button ‘Add’. If you have used the passphrase – enter it. Next, specify the IP address or hostname of our depl_host, test the connection, and save the configuration by clicking ‘Save’ or ‘Apply’ at the bottom of the page.

Jenkins ssh config

Jenkins ssh config ( – depl_host)

Now we are ready to create our project in Jenkins. In the next post we’ll create the portion that reacts to commit, and deploys the application for testing.

Print this post | Home


  1. Alexander says:

    Когда будет продолжение?
    Очень надо, ибо разворачиваю сейчас нечто подобное.

  2. Igor says:

    Сегодня следующая часть. Следующая за ним тожее будет скоро (там о тестировании в Nerrvana из Jenkins). Затем финальный пост с реальными конфигурационными файлами.

  3. Alexander says:

    Ok, спасибо, жду с нетерпением!