Date post: | 30-Nov-2015 |
Category: |
Documents |
Upload: | ejespino1127 |
View: | 53 times |
Download: | 5 times |
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 [email protected]
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 [email protected]:<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 [email protected]: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:
[email protected]: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.