Continuous

Delivery

By Uchit Vyas

contact@attuneuniversity.com www.attuneuniversity.com

Continuous Delivery 1

Table of Content

I. Getting started

II. Version Controlling with Git

III. Git with Eclipse (EGit)

IV. Eclipse SSH Configuration

V. Installing Jenkins

VI. Installing Ruby with RVM

VII. Creating a job in Jenkins

VIII. Configuring the Tools

2 Continuous Delivery

About Author

Uchit Vyas a B.Tech. Graduate in Computer Science with a research

interest in ESB & Cloud and is a certified by Cisco (CCNA), VMware

(VSP) and Red Hat Linux (RHCE) professional. He has an energetic

strength to work on multiple platforms at a time and ability to integrate

open source technologies. He works as a Sr. Consultant and looking

afterAWS – Cloud, Mule ESB, Alfresco, Liferay and deploying Portal,

ECM system. He was previously working with TCS as Assistant System

Engineer.

Over 3+ years of hands on experience on Open Source technologies, he

manages to guide the team and deliver the projects and trainings. He has

provided 13+ trainings on Cloud Computing, Continuous Delivery,

Alfresco and Liferay in couple of months. During past years he moved

over 80% of Attune Infocom business processes to the Cloud with

implementing agile SDLC methodology on Amazon, Rackspace and

private clouds like Eucalyptus, Openstack. His skills are not limited as his

designing and managing Cloud environment/infrastructure, server

architecture. He is also active in shell scripting, auto deployment,

supporting hundreds of Linux and Windows physical & virtual servers

hosting databases, and applications with Continuous delivery using Jenkins

/ Cruise Control with Puppet / Chef scripting.

Continuous Delivery 3

Getting started

Continuous Delivery (CD) is a pattern language used in software

development to automate and improve the process of software delivery.

Techniques such as automated testing, continuous integration and

continuous deployment allow software to be developed to a high standard

and easily packaged and deployed to test environments, resulting in the

ability to rapidly, reliably and repeatedly push out enhancements and bug

fixes to customers at low risk and with minimal manual overhead. The

technique was one of the assumptions of extreme programming but at an

enterprise level has developed into a discipline of its own, with job

descriptions for roles such as "buildmaster" calling for CD skills as

mandatory.

Figure 1 : Continuous Delivery Pattern Continuous delivery treats the commonplace notion of a deployment

pipeline as a set of validations through which a piece of software must pass

4 Continuous Delivery

on its way to release. Code is compiled if necessary and then packaged by a

build server every time a change is committed to a source control

repository, then tested by a number of different techniques (possibly

including manual testing) before it can be marked as releasable.

Figure 2 : Architecture for Continuous Delivery

Developers use to a long cycle time may need to change their mindset

when working in a CD environment. It is important to understand that any

code commit may be released to customers at any point. Patterns such

as feature toggles can be very useful for committing code early which is not

yet ready for use by end users. Other useful techniques for developing code

in isolation such as code branching are not obsolete in a CD world, but

must be adapted to fit the principles of CD - for example, running multiple

long-lived code branches can prove impractical, as a releasable artifact must

be built early in the CD process from a single code branch if it is to pass

through all phases of the pipeline.

Continuous Delivery 5

Continuous Delivery Tools List

I usually shy away from giving a list of tools that we use because people

have their particular tool preferences and are sometimes indignant in

considering others. However, I realize it's helpful for people to understand

the tool landscape when it comes to Continuous Delivery in the Cloud just

so they know where to start looking. After reading my Continuous

Integration book, this is often the most common question I get from

readers.

I want to say up front that I'm not advocating the use of any of these tools,

just that we've used some of the tools or investigated when creating

Continuous Delivery systems. I'm sure some of the tools that we use on a

daily basis won't make it to this list.

The precise toolset a team may choose to use depends upon numerous

factors including project, cost and customer constraints – to name a few.

Therefore, I suggest that you focus more on the type of tool and determine

which one meets their particular needs for their Continuous Delivery

ecosystem. Just because I'm not mentioning a particular tool doesn't mean

I'm not using it or that I don't think it's a good tool; these are meant to be

illustrative. We tend to focus more on freely-available tools because people

can download and use them quickly. There are good reasons to choose

commercial tools. As implied before, you don't need to be using all of these

tools to get significant benefit from Continuous Delivery. Start small and

build it up. I've listed some of the tools in each category for the Java, .NET

and Ruby platforms. Since, we lean heavily toward Cloud tools; you'll see

that we opt for the SaaS-based tools, when applicable. Let me know if your

6 Continuous Delivery

preferred tool didn't make the list. Ok, there's my disclaimer. On with the

list:

Application Containers – JBoss, Tomcat, IIS, Mongrel. NOTE: there are so

many app containers; I'm not going to try to list all of them.

Build Tools –

Ant, AntContrib, NAnt, MSBuild, Buildr, Gant, Gradle, make, Maven, Rak

e

Code Review - Crucible

Code Insight – Fisheye

Continuous Integration – Bamboo, Jenkins, AntHill

Pro, Go, TeamCity, TFS 2010

Cloud IaaS - AWS EC2, AWS S3 , Windows Azure

Cloud PaaS – Google App Engine, AWS Elastic Beanstalk, Heroku

Database – Hibernate, MySQL, Liquibase, Oracle, PostgreSQL, SQL

Server, SimpleDB, SQL Azure, Ant, MongoDB

Database Change Management – dbdeploy, Liquibase

Data Center Configuration Automation – Capistrano, Cobbler, BMC

Bladelogic, CFEngine, IBM Tivoli Provisioning

Manager, Puppet, Chef, Bcfg2, AWS Cloud Formation, Windows Azure

AppFabric NOTE: There are many names and overlap for this tool "category".

Dependency Management – Ivy, Archiva, Nexus, Artifactory, Bundler

Deployment Automation – Java Secure

Channel, ControlTier, Altiris, Capistrano, Fabric, Func

Information Sharing – Confluence, Google Apps

Installer – InstallShield, IzPack

Integrated Development Environment (IDE) – Eclipse, IDEA, Visual

Studio

Continuous Delivery 7

Issue Tracking - Greenhopper, JIRA

Multi-Type – rPath

Passwords – PassPack, PasswordSafe

Protected Configuration – ESCAPE, ConfigGen

Project Management – JIRA, Pivotal Tracker, SmartSheet

Provisioning - JEOS, BoxGrinder, CLIP, Eucalyptus, AppLogic

Reporting/Documentation –

Doxygen, Grand, GraphViz, JavaDoc, NDoc, SchemaSpy, UmlGraph

Static Analysis -

CheckStyle, Clover, Cobertura, FindBugs, FxCop, JavaNCSS, JDepend, P

MD, Sonar, Simian

Systems Monitoring – CloudKick, Nagios, Zabbix, Zenoss

Testing –

AntUnit, Cucumber, DbUnit, webrat, easyb, Fitnesse, JMeter, JUnit, NBeh

ave, SoapUI, Selenium, RSpec,SauceLabs

Version-Control System – SVN/Subversion, git, Perforce

8 Continuous Delivery

Version Controlling with Git

There are many options for version control, but the Rails community has

largely standardized on Git, a distributed version control system originally

developed by Linus Torvalds to host the Linux kernel. Git is a large subject,

and we‘ll only be scratching the surface in this book, but there are many

good free resources online; I especially recommend Pro Git by Scott

Chacon (Apress, 2009). Putting your source code under version control

with Git is strongly recommended, not only because it‘s nearly a universal

practice in the Rails world, but also because it will allow you to share your

code more easily and deploy your application right here in the first

chapter.

Installing Git

Let‘s get into using some Git. First things first—you have to install it. You

can get it a number of ways; the two major ones are to install it from

source or to install an existing package for your platform.

Installing from Source

If you can, it‘s generally useful to install Git from source, because you‘ll get

the most recent version. Each version of Git tends to include useful UI

enhancements, so getting the latest version is often the best route if you

feel comfortable compiling software from source. It is also the case that

many Linux distributions contain very old packages; so unless you‘re on a

very up-to-date distro or are using backports, installing from source may be

the best bet.

To install Git, you need to have the following libraries that Git depends on:

curl, zlib, openssl, expat, and libiconv. For example, if you‘re on a system

Continuous Delivery 9

that has yum (such as Fedora) or apt-get (such as a Debian based system),

you can use one of these commands to install all of the dependencies:

$ yum install curl-devel expat-devel gettext-devel \

openssl-devel zlib-devel

$ apt-get install libcurl4-gnutls-dev libexpat1-dev gettext \

libz-dev libssl-dev

When you have all the necessary dependencies, you can go ahead and grab

the latest snapshot from the Git web site: http://git-scm.com/download

Then, compile and install:

$ tar -zxf git-1.7.2.2.tar.gz

$ cd git-1.7.2.2

$ make prefix=/usr/local all

$ sudo make prefix=/usr/local install

After this is done, you can also get Git via Git itself for updates:

$ git clone git://git.kernel.org/pub/scm/git/git.git

First-time system setup

After installing Git, you should perform a set of one-time setup steps.

These are system setups, meaning you only have to do them once per

computer:

$ git config --global user.name "Your Name"

$ git config --global user.email your.email@example.com

10 Continuous Delivery

I also like to use co in place of the more verbose checkout command,

which we can arrange as follows:

$ git config --global alias.co checkout

This tutorial will usually use the full checkout command, which works for

systems that don‘t haveco configured, but in real life I nearly always use git

co.

As a final setup step, you can optionally set the editor Git will use for

commit messages. If you use a graphical editor such as Sublime Text,

TextMate, gVim, or MacVim, you need to use a flag to make sure that the

editor stays attached to the shell instead of detaching immediately:

$ git config --global core.editor "subl -w"

Replace "subl -w" with "mate -w" for TextMate, "gvim -f" for gVim, or "mvim

-f" for MacVim.

First-time repository setup

Now we come to some steps that are necessary each time you create a

new repository. First navigate to the root directory of the first app and

initialize a new repository:

$ git init

Initialized empty Git repository in /Users/mhartl/rails_projects/first_app/.git/

The next step is to add the project files to the repository. There‘s a minor

complication, though: by default Git tracks the changes of all the files, but

there are some files we don‘t want to track. For example, Rails creates log

files to record the behavior of the application; these files change frequently,

Continuous Delivery 11

and we don‘t want our version control system to have to update them

constantly. Git has a simple mechanism to ignore such files: simply include

a file called .gitignore in the application root directory with some rules

telling Git which files to ignore.

We see that the rails command creates a default .gitignore file in the

application root directory.

# See http://help.github.com/ignore-files/ for more about ignoring files.

#

# If you find yourself ignoring temporary files generated by your text

editor

# Or operating system, you probably want to add a global ignore instead:

# git config --global core.excludesfile ~/.gitignore_global

# Ignore bundler config

/.bundle

# Ignore the default SQLite database.

/db/*.sqlite3

# Ignore all logfiles and tempfiles.

/log/*.log

/tmp

This causes Git to ignore files such as log files, Rails temporary (tmp) files,

and SQLite databases. (For example, to ignore log files, which live in

the log/ directory, we use log/*.log to ignore all files that end in .log.) Most

12 Continuous Delivery

of these ignored files change frequently and automatically, so including

them under version control is inconvenient; moreover, when collaborating

with others they can cause frustrating and irrelevant conflicts.

The .gitignore file is probably sufficient for this tutorial. This

augmented .gitignore arranges to ignore Rails documentation files, Vim and

Emacs swap files, and (for OS X users) the weird.DS_Store directories

created by the Mac Finder application. If you want to use this broader set

of ignored files, open up .gitignore in your favorite text editor and fill it

with the contents.

An augmented .gitignore file.

# Ignore bundler config

/.bundle

# Ignore the default SQLite database.

/db/*.sqlite3

# Ignore all logfiles and tempfiles.

/log/*.log

/tmp

# Ignore other unneeded files.

doc/

*.swp

*~

.project

.DS_Store

Continuous Delivery 13

.idea

Adding and Committing

Finally, we‘ll add the files in your new Rails project to Git and then commit

the results. You can add all the files (apart from those that match the

ignore patterns in .gitignore) as follows:

$ git add .

Here the dot ‗.‘ represents the current directory, and Git is smart enough to

add the files recursively, so it automatically includes all the subdirectories.

This command adds the project files to a staging area, which contains

pending changes to your project; you can see which files are in the staging

area using the status command.

$ git status

# On branch master

#

# Initial commit

#

# Changes to be committed:

# (use "git rm --cached <file>..." to unstage)

#

# new file: README.rdoc

# new file: Rakefile

(The results are long, so I‘ve used vertical dots to indicate omitted output.)

14 Continuous Delivery

To tell Git you want to keep the changes, use the commit command:

$ git commit -m "Initial commit"

[master (root-commit) df0a62f] Initial commit

42 files changed, 8461 insertions(+), 0 deletions(-)

create mode 100644 README.rdoc

create mode 100644 Rakefile

The -m flag lets you add a message for the commit; if you omit -m, Git will

open the editor you set and have you enter the message there.

It is important to note that Git commits are local, recorded only on the

machine on which the commits occur. This is in contrast to the popular

open-source version control system called Subversion, in which a commit

necessarily makes changes on a remote repository. Git divides a

Subversion-style commit into its two logical pieces: a local recording of the

changes (git commit) and a push of the changes up to a remote repository

(git push). By the way, you can see a list of your commit messages using

the log command:

$ git log

commit df0a62f3f091e53ffa799309b3e32c27b0b38eb4

Initial commit

To exit git log, you may have to type q to quit.

What good does Git do you?

It‘s probably not entirely clear at this point why putting your source under

version control does you any good, so let me give just one example. (We‘ll

Continuous Delivery 15

see many others in the chapters ahead.) Suppose you‘ve made some

accidental changes, such as deleting the critical app/controllers/directory:

$ ls app/controllers/

application_controller.rb

$ rm -rf app/controllers/

$ ls app/controllers/

ls: app/controllers/: No such file or directory

Here we‘re using the Unix ls command to list the contents of

the app/controllers/ directory and the rm command to remove it. The -

rf flag means ―recursive force‖, which recursively removes all files,

directories, subdirectories, and so on, without asking for explicit

confirmation of each deletion.

Let‘s check the status to see what‘s up:

$ git status

# On branch master

# Changed but not updated:

# (use "git add/rm <file>..." to update what will be committed)

# (use "git checkout -- <file>..." to discard changes in working directory)

#

# deleted: app/controllers/application_controller.rb

#

no changes added to commit (use "git add" and/or "git commit -a")

16 Continuous Delivery

We see here that a file has been deleted, but the changes are only on the

―working tree‖; they haven‘t been committed yet. This means we can still

undo the changes easily by having Git check out the previous commit with

the checkout command (and a -f flag to force overwriting the current

changes):

$ git checkout -f

$ git status

# On branch master

nothing to commit (working directory clean)

$ ls app/controllers/

application_controller.rb

The missing directory and file are back. That‘s a relief!

GitHub

Now that you‘ve put your project under version control with Git, it‘s time

to push your code up to GitHub, a social code site optimized for hosting

and sharing Git repositories. Putting a copy of your Git repository at

GitHub serves two purposes: it‘s a full backup of your code (including the

full history of commits), and it makes any future collaboration much easier.

This step is optional, but being a GitHub member will open the door to

participating in a wide variety of open-source projects.

Continuous Delivery 17

Figure 3 : Creating the first app repository at GitHub

GitHub has a variety of paid plans, but for open-source code their services

are free, so sign up for a free GitHub account if you don‘t have one already.

(You might have to follow the GitHub tutorial on creating SSH keys first.)

After signing up, click on the link to create a repository and fill in the

information. (Take care not to initialize the repository with

a README file, as rails new create one of those automatically.) After

submitting the form, push up your first application as follows:

$ git remote add origin git@github.com:<username>/first_app.git

$ git push -u origin master

These commands tell Git that you want to add GitHub as the origin for

your main (master) branch and then push your repository up to GitHub.

(Don‘t worry about what the -u flag does; if you‘re curious, do a web

search for ―git set upstream‖.) Of course, you should

18 Continuous Delivery

replace <username> with your actual username. For example, the

command I ran for the rails tutorial user was

$ git remote add origin git@github.com:railstutorial/first_app.git

The result is a page at GitHub for the first application repository, with file

browsing, full commits history, and lots of other goodies.

Figure 4 : A GitHub repository page

GitHub also has native applications to augment the command-line

interface, so if you‘re more comfortable with GUI apps you might want to

check out GitHub for Windows or GitHub for Mac. (GitHub for Linux is

still just Git, it seems.)

Branch, edit, commit, merge

In our case, since the project is a Rails application generated using

the rails command, the README file is the one that comes with Rails.

Because of the .rdoc extension on the file, GitHub ensures that it is

formatted nicely, but the contents aren‘t helpful at all, so in this section

we‘ll make our first edit by changing the README to describe our project

Continuous Delivery 19

rather than the Rails framework itself. In the process, we‘ll see a first

example of the branch, edit, commit, merge workflow that I recommend

using with Git.

Figure 5 : The initial (rather useless) README file for our project at GitHub

Branch

Git is incredibly good at making branches, which are effectively copies of a

repository where we can make (possibly experimental) changes without

modifying the parent files. In most cases, the parent repository is

the master branch, and we can create a new topic branch by

using checkout with the-b flag:

$ git checkout -b modify-README

Switched to a new branch 'modify-README'

$ git branch

master

20 Continuous Delivery

* modify-README

Here the second command, git branch, just lists all the local branches, and

the asterisk *identifies which branch we‘re currently on. Note that git

checkout -b modify-README both creates a new branch and switches to

it, as indicated by the asterisk in front of the modify-README branch. (If

you set up the co alias, you can use git co -b modify-README instead.)

The full value of branching only becomes clear when working on a project

with multiple developers, but branches are helpful even for a single-

developer tutorial such as this one. In particular, the master branch is

insulated from any changes we make to the topic branch, so even if

we really screw things up we can always abandon the changes by checking

out the master branch and deleting the topic branch. We‘ll see how to do

this at the end of the section.

By the way, for a change as small as this one I wouldn‘t normally bother

with a new branch, but it‘s never too early to start practicing good habits.

Edit

After creating the topic branch, we‘ll edit it to make it a little more

descriptive. I prefer the Markdown markup language to the default RDoc

for this purpose, and if you use the file extension.md then GitHub will

automatically format it nicely for you. So, first we‘ll use Git‘s version of the

Unix mv (―move‖) command to change the name, and then fill it in with

the contents:

$ git mv README.rdoc README.md

$ subl README.md

Continuous Delivery 21

Commit

With the changes made, we can take a look at the status of our branch:

$ git status

# On branch modify-README

# Changes to be committed:

# (use "git reset HEAD <file>..." to unstage)

#

# renamed: README.rdoc -> README.md

#

# Changed but not updated:

# (use "git add <file>..." to update what will be committed)

# (use "git checkout -- <file>..." to discard changes in working directory)

#

# modified: README.md

#

At this point, we could use git add . but Git provides the -a flag as a

shortcut for the (very common) case of committing all modifications to

existing files (or files created using git mv, which don‘t count as new files

to Git):

$ git commit -a -m "Improve the README file"

2 files changed, 5 insertions(+), 243 deletions(-)

delete mode 100644 README.rdoc

create mode 100644 README.md

22 Continuous Delivery

Be careful about using the -a flag improperly; if you have added any new

files to the project since the last commit, you still have to tell Git about

them using git add first.

Note that we write the commit message in the present tense. Git models

commits as a series of patches, and in this context it makes sense to

describe what each commit does, rather than what it did. Moreover, this

usage matches up with the commit messages generated by Git commands

themselves. See the GitHub post Shiny new commit styles for more

information.

Merge

Now that we‘ve finished making our changes, we‘re ready to merge the

results back into our master branch:

$ git checkout master

Switched to branch 'master'

$ git merge modify-README

Updating 34f06b7..2c92bef

Fast forward

README.rdoc | 243 --------------------------------------------------

README.md | 5 +

2 files changed, 5 insertions(+), 243 deletions(-)

delete mode 100644 README.rdoc

create mode 100644 README.md

Continuous Delivery 23

Note that the Git output frequently includes things like 34f06b7, which are

related to Git‘s internal representation of repositories. Your exact results

will differ in these details, but otherwise should essentially match the

output shown above.

After you‘ve merged in the changes, you can tidy up your branches by

deleting the topic branch using git branch -d if you‘re done with it:

$ git branch -d modify-README

Deleted branch modify-README (was 2c92bef).

This step is optional, and in fact it‘s quite common to leave the topic

branch intact. This way you can switch back and forth between the topic

and master branches, merging in changes every time you reach a natural

stopping point.

As mentioned above, it‘s also possible to abandon your topic branch

changes, in this case with git branch -D:

# For illustration only; don't do this unless you mess up a branch

$ git checkout -b topic-branch

$ <really screw up the branch>

$ git add .

$ git commit -a -m "Major screw up"

$ git checkout master

$ git branch -D topic-branch

24 Continuous Delivery

Unlike the -d flag, the -D flag will delete the branch even though we

haven‘t merged in the changes.

Push

Now that we‘ve updated the README, we can push the changes up to

GitHub to see the result. Since we have already done one push, on most

systems we can omit origin master, and simply run git push:

$ git push

As promised, GitHub nicely formats the new file using Markdown.

Figure 6 : Formated file by Github

Git with Eclipse (EGit)

Create a new Java project HelloWorld in eclipse.

Figure 7 : Java project creation

Select the project, click File > Team > Share Project

Continuous Delivery 25

Select repository type Git and click Next

Figure 8 : Repository plug-in selection

To configure the Git repository select the new project HelloWorld

Figure 9 : Configuring Git repository

Click Create Repository to initialize a new Git repository for

the HelloWorld project. If your project already resides in the

26 Continuous Delivery

working tree of an exisiting Git repository the repository is chosen

automatically.

Figure 10 : Configuring Project

Click Finish to close the wizard.

The decorator text "[master]" behind the project shows that this project is

tracked in a repository on the master branch and the question mark

decorators show that the .classpath and .project and the .settings files are

not yet under version control.

Figure 11 : Files before version control

Continuous Delivery 27

Click Team > Add on the project node. (This menu item may

read Add to Index on recent versions of Egit)

The + decorators show that now the project's files have been added to

version control

Mark the "bin" folder as "ignored by Git", either by right-clicking on it and

selecting Team > Ignore or by creating a file .gitignore in the project folder

with the following content

/bin

This excludes the bin folder from Git's list of tracked files.

Add .gitignore to version control (Team > Add):

Figure 12 : Files after Version Control

You may have to set your Package Explorer filters in order to

see .gitignore displayed in the Package Explorer. To access filters, select the

down arrow at right of Package Explorer tab to display View Menu.

28 Continuous Delivery

Figure 13 : Accessing Filters

Select Filters... from the View Menu and you will be presented with the

Java Element Filters dialog. Unselect the top entry to display files that

begin with . (period) such as .gitignore.

Figure 14 : Filters Menu

Click Team > Commit in the project context menu

Enter a commit message explaining your change; the first line

(followed by an empty line) will become the short log for this

commit. By default the author and committer are taken from

the .gitconfig file in your home directory.

You may click Add Signed-off-by to add a Signed-off-by: tag.

Continuous Delivery 29

If you are committing the change of another author you may alter the

author field to give the name and email address of the author.

Click Commit to commit your first change.

Figure 15 : Commit stage

Note that the decorators of the committed files changed.

Figure 16 : Commited files

When creating new projects and repositories, you will be given the option

to make them private:

30 Continuous Delivery

Figure 17 : Gitorious Repository

On the next screen you can see the URLs you may use to access your fresh

new repository:

Figure 18 : Configuring SSH

Click SSH to choose the SSH protocol. It can be used for read and

write access

Click HTTP to choose the HTTP protocol. It can also be used for

read and write access.

Click Git Read-Only to choose the anonymous git protocol for

cloning. It's the most efficient protocol git supports. Since the git

Continuous Delivery 31

protocol doesn't support authentication it's usually used to provide

efficient read-only access to public repositories.

Eclipse SSH Configuration

Open the Eclipse Preferences and ensure that your SSH2 home is

configured correctly (usually this is ~/.ssh) and contains your SSH2 keys

Figure 19 : Key management and SSH

If you don't have SSH keys yet you may generate them on the second

tab Key Management of this dialog, use a good pass phrase to protect

your private key,

Upload your public SSH key to your GitHub account settings.

Push Upstream

Click Team > Remote > Push... and copy and paste the SSH URL of

your new github repository

32 Continuous Delivery

If you are behind a firewall which doesn't allow SSH traffic use the github

HTTPS URL instead and provide your github user and password instead of

using the uploaded public SSH key. To store your credentials into the

Eclipse secure store click Store in Secure Store.

Note: many HTTP proxies are configured to block HTTP URLs

containing a user name, since disclosing a user name in an HTTP URL is

considered a security risk. In that case remove the username from the

HTTP URL and only provide it in the user field. It will be sent as an

HTTP header.

Figure 20 : Pushing upstrem

Click Next and on first connection accept GitHub's host key.

Enter your SSH key's passphrase and click OK.

Continuous Delivery 33

On the next wizard page click Add all branches spec to map your local

branch names 1:1 to the same branch names in the destination repository.

Figure 21 : Refs selection to push

Click Next. The push confirmation dialog will show a preview of the

changes that will be pushed to the destination repository.

34 Continuous Delivery

Figure 22 : Preview page for upstream pushing

Click Finish to confirm that you want to push these changes.

The next dialog reports the result of the push operation.

Figure 23 : Result page

Continuous Delivery 35

Point your browser at your GitHub repository to see that your new

repository content has arrived.

Installing Jenkins

Installing Jenkins is a breeze, as debian packages have been set up,

$ wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo

apt-key add -

$ sudo vi /etc/apt/sources.list.d/jenkins.list

Add "deb http://pkg.jenkins-ci.org/debian binary/"

$ sudo apt-get update

$ sudo apt-get install jenkins

This automatically creates an account called jenkins. We will need to login

as this user later so set a password for jenkins with:

sudo passwd jenkins

You should now be able to view the Jenkins dashboard at

http://your.server:8080/

Now that Jenkins is installed, we want to get a headless display configured

for our browser based tests. First up hit Manage Jenkins > Manage Plugins

> Available and install the Hudson Xvnc plugin (this works with Jenkins

despite its name). Schedule Jenkins to restart to pick up the plug-in. With

Jenkins configured we need to ensure the required software is installed on

the server:

$ sudo apt-get install vnc4server

36 Continuous Delivery

vncserver requires a password to be set before it can be used, this needs to

be set before Jenkins can make use of the vncserver. For this we need to

switch to the jenkins user and set a password.

$ sudo -Hiu jenkins

$ vncserver

Enter a password, and verify it

$ vncserver -kill :1 # or whichever display the vncserver output

mentioned.

When Jenkins runs it doesn‘t need to know this password, but if you want

to watch a running job you can connect to the running vnc session with

that password and watch the tests in real time.

Installing Ruby with RVM

The job I want to run is a set of acceptance tests written in Cucumber with

automation done using Capybara (Selenium-Webdriver under the hood).

So it‘s a Ruby job, and all good Ruby jobs use RVM.

$ sudo apt-get install curl bison build-essential zlib1g-dev libssl-dev

libreadline5-dev libxml2-dev git-core

$ sudo -Hiu jenkins

$ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

Or

\curl -L https://get.rvm.io | bash -s stable --ruby

Continuous Delivery 37

Once RVM is configured, run rvm notes to find the full list of

dependencies you need to install for your required version of Ruby.

$ source ~/.rvm/scripts/rvm

$ rvm notes

$ sudo apt-get install build-essential bison openssl libreadline6

libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev

libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-

dev ncurses-dev

Note that I didn‘t give the jenkins user sudo rights, so I installed all

packages through my usual admin account on the server.

RVM can be configured to allow the automatic installation of Ruby

versions and gemsets by adding the following to ~/.rvmrc for the jenkins

user:

rvm_install_on_use_flag=1

rvm_project_rvmrc=1

rvm_gemset_create_on_use_flag=1

Installing Firefox sudo apt-get install firefox

This is the default browser that selenium will select.

At this point the Jenkins server should be fully configured to run headless

jobs, so let‘s dive in and create one. Create a new freestyle job. Notice there

is a new option available under the ‗Build Environment‘ section call ‗Run

Xvnc during build‘, check this to have the plugin automatically do its magic.

38 Continuous Delivery

For my example, I didn‘t bother with checking projects out source control,

I simply created a project in the /tmp directory. You‘ll want to enable the

appropriate SCM plugin and configure a checkout. Under the build section

add an Execute shell step with the following:

#!/bin/bash -e

cd /tmp/selenium-test

source "$HOME/.rvm/scripts/rvm"

[[ -s ".rvmrc" ]] && source .rvmrc

bundle install

cucumber

The -e flag in #!/bin/bash -e ensures the script stops after any errors. You

will notice that the script sources the .rvmrc file directly for the project, this

ensures the correct version of Ruby is used with a gemset appropriate for

your project. My .rvmrc looked something like:

rvm --create use ruby-1.9.2@selenium-test

Calling bundle install automatically installs bundler, reads the Gemfile.lock

and installs all required gems. Finally cucumber kicks off the actual

cucumber scenarios, and fingers crossed, they should pass with flying

colours.

As the headless display is running in vncserver, you can connect to the vnc

session and watch the tests run in real time. Just use your regular VNC

client and connect to your.server:59xx where xx is the display number

output on the Jenkins console for the running job. You will need to enter

the password you set the first time you ran vncserver.

Continuous Delivery 39

If you are getting error regarding VNC SERVER,

login as the hudson user

run the command "vncserver" once (for example "vncserver")

answer the password prompt (to create a VNC desktop password),

then

kill that VNC session (for example "vncserver -kill :1")

ON jenkins Console Output:

Terminating xvnc.

$ vncserver -kill :33

Killing Xvnc4 process ID 6873

Finished: SUCCESS

Creating a job in Jenkins

First of all when we click on the following link http://localhost:8080/

You will be asked for username and password credentials. So please enter

your credentials in those appropriate text-boxes.

Now, you should see a screen like the one shown in Figure, ―The Jenkins

start page‖.

You are now ready to take your first steps with Jenkins!

40 Continuous Delivery

Figure 24 : Jenkins job creation page

Configuring the Tools

Before we get started, we do need to do a little configuration. More

precisely, we need to tell Jenkins about the build tools and JDK versions

we will be using for our builds.

Click on the Manage Jenkins link on the home page (see Figure, ―The

Jenkins start page‖). This will take you to the Manage Jenkins page, the

central one-stop-shop for your entire Jenkins configuration. From this

screen, you can configure your Jenkins server, install and upgrade plug-ins,

keep track of system load, manage distributed build servers, and more! For

now, however, we‘ll keep it simple. Just click on the Configuring System

link at the top of the list (see Figure, ―The Manage Jenkins screen‖).

Continuous Delivery 41

Figure 25 : The Manage Jenkins screen

This will take you to Jenkins‘s main configuration screen (see Figure ,

―The Configure Jenkins screen‖).

From here you can configure everything from security configuration and

build tools to email servers, version control systems and integration with

third-party software.

The screen contains a lot of information, but most of the fields contain

sensible default values, so you can safely ignore them for now.

42 Continuous Delivery

Figure 26 : Configure Jenkins screen

For now, you will just need to configure the tools required to build our

sample project. The application we will be building is a Java application,

built using Maven.

Figure 27 : Setting up your first build job in Jenkins

Once you click on OK, Jenkins will display the project configuration screen.

Continuous Delivery 43

In general manner use free style project while creating new job.

For Windows here is what we need:

Tomcat or another web container

Ensure the default ports are changed, for my examples I used 8082

for tomcat

You have a Java project checked into github.com

A github account (see github.com)

Remember to setup the SSH keys

Jenkins (see http://jenkins-ci.org/)

Download the lastest war file

github client software

http://help.github.com/ for linux

Start Jenkins java -jar jenkins.war

Visit http://localhost:8080/ to access Jenkins

Install Jenkins as a service

Instructions is here:

https://wiki.jenkins-

ci.org/display/JENKINS/Installing+Jenkins+as+a+linux+service

Jenkins Service installed:

Jenkins running on http://localhost:8080/

44 Continuous Delivery

Add github support to Jenkins

Manage Jenkins

Under the github section provide the path to git.exe

Git Plugin section:

Global Config user.name Value {Your git username}

Global Config user.email Value {email address}

SSH keys

Generate ssh keys which guided by github.

Add them to github.com

Setup email notifications, using gmail

In the E-mail Notification section, add the following

SMTP Server:smtp.gmail.com

Sender e-mail address:{username}@gmail.com

Click Use SMTP Authentication

Username:{username}@gmail.com

Password:{gmail pass}

Click Use SSL

SMTP Port 465

Confirm by using the Test configuration by sending test e-mail

option

Adding plugins to Jenkins

Manage Jenkins\Manage Plugins\Available and Add the following plugins:

Continuous Delivery 45

"Deploy to container Plugin"

"Jenkins GIT plugin"

"GitHub plugin"

Create a Dynamic Java Project and

Creating a New Job

Click New Job

Provide a job name

Use a Build a free-style software project

configuring the Job Options

Under the Source code Management section

pulling code from gitbub

Click the git button

Enter you repository url, something like:

git@github.com:uchit/demo.git

Github project name like: https://github.com/uchit/demo/ which is given

to gitgub readonly board

Calling Ant

In the build section, click the Add Build Step button, select Invoke Ant

Provide the Targets to run in a commas separated list or just remain blank

in this target.

46 Continuous Delivery

Post-build actions

select Deploy war/ear to a container

Give parameters like in 1st: **/*.war or full path

In second give tomcat 7x or whatever we use.

Deploying to Tomcat, automatically

In the Post-build actions section

Check Deploy war/ear to container

WAR/EAR files:**/*.war

Container: Tomcat 7.x

Manager user name: tomcat

Manager password: {password}

Tomcat url: http:localhost:8081

Sending email notification on failure

Check Email-notifications

Enter your email address

Check Send e-mail for every unstable build

Building your project

From the Jenkins dashboard, click on the project name

Click Build Now on the left hand side

Select the Build from the Build history section

Select Console output to view the build information

Things to watch out:

Ant paths, since they will be running under the jobs directory try not

to hard code any absolute paths

Continuous Delivery 47

SSH keys with github

Ports ensure Web Container and Jenkins isn‘t using the same port.

Here Are Sample screenshots for references:

Figure 28 : Repository configuration

Figure 29 : Build Configuration

48 Continuous Delivery

Figure 30 : Post Build Configuration

Figure 31 : Container Configuration

Continuous Delivery 49

Figure 32 : Git URL for configuration in Jenkins

In this repository I have put whole Liferay plug-in folder. If you get

redeployment error in tomcat, just restart your tomcat.