DevOps Tutorial

By Scott Rich
 Table of Contents

Part 1: Introduction to Project Versioning with Maven………………………..………Page 2

Part 2: Use Maven Release Plugin to Manage Versions…………………………..……Page 5

Part 3: Artifact Management……………………………………………………………….………Page 7

Part 4: Continuous Integration…………………………………………………………………..Page 10

Part 5: Parallel Deployment…………………………………………………………………...….Page 18

1
Part 1: Introduction to Project Versioning with Maven
In this five part DevOps tutorial, I will explain how to manage your project versioning using
Maven, versioning best practices, and integration versioning into a build process.

For this Dev Ops tutorial, I assume that you have a Tomcat 7 server setup and available. If you
do not have a Tomcat 7 server available for your testing, check out my Lightning Tutorial –
Installing Tomcat 7.

To start things out we need to create a basic webapp project. Open up a command line and
execute the following command. A project will be created using Maven’s webapp archetype.
For more information on archetypes go to:
https://maven.apache.org/guides/introduction/introduction-to-archetypes.html

1. mvn archetype:generate -DgroupId=com.sample -DartifactId=SampleWebApp123

Next we need to make a few modifications to the project’s pom.xml file.

1. Modify the finalName element to match the following line. The ## characters allow Tomcat
to determine both the name of the webapp and the version. This will be used later in this
tutorial to run two versions of our webapp at the same time.

1. <finalName>${project.artifactId}##${project.version}</finalName>

2. Add deploy plugin under the build tag. You will need to change the highlighted sections to
match your configuration.

1. <build>
2. ...
3. <plugins>
4. <plugin>
5. <groupId>org.apache.tomcat.maven</groupId>
6. <artifactId>tomcat7-maven-plugin</artifactId>
7. <version>2.2</version>
8. <configuration>
9. <path>/${project.artifactId}##${project.version}</path>
10. <url>http://quartz:8080/manager/text</url>
11. <username>admin</username>
12. <password>adminadmin</password>
13. <update>true</update>
14. </configuration>

2
 15. </plugin>
16. </plugins>
17. ...
18. </build>

3. Create a properties file at src/main/resources/test.properties with the following content. We

1. version=${project.version}

4. Add filtering of resources. This replaces ${project.version} in the properties file you just
created with the version from the pom.xml. This properties file can then be accessed by the jsp
pages we are about to modify to display the version of this web app. For more information on
resource filtering go to http://maven.apache.org/plugins/maven-resources-
plugin/examples/filter.html

1. <build>
2. ...
3. <resources>
4. <resource>
5. <directory>src/main/resources</directory>
6. <filtering>true</filtering>
7. </resource>
8. </resources>
9. ...
10. </build>

Now we can edit index.jsp to display the version from the properties file. Include the following
code in your src/main/webapp/index.jsp.

1. <%@ page import = "java.util.ResourceBundle" %>

Let’s build and deploy our sample web app.

1. cd SampleWebApp123
2. mvn clean package
3. mvn tomcat7:deploy

3
Check out the results in your browser (again replacing the highlighted text for your
configuration). Go to http://quartz:8080/SampleWebApp123

You should see:

Hello World!

1.0-SNAPSHOT

4
Part 2: Use Maven Release Plugin to Manage Versions
In part 2, I’m going to run you through how to use Apache Maven to manage versions of your
application. This part assumes you still have access to a running Tomcat instance, and a pair of
browsers, but now I am adding a source code management (SCM) system to the mix.

Let’s modify our pom.xml again, this time adding the release plugin.

1. <plugins>
2. …
3. <plugin>
4. <groupId>org.apache.maven.plugins</groupId>
5. <artifactId>maven-release-plugin</artifactId>
6. <version>2.5.1</version>
7. </plugin>
8. …
9. </plugins>

Now we need to connect this project to the SCM, I’m using a GitBlit instance running on the
same instance of Tomcat I’m using for testing. If you don’t have an SCM available for testing,
see my “Lightning Tutorial – Installing GitBlit”. Add the following to your pom.xml file with the
highlighted section matching your configuration.

1. <project>
2. …
3. <scm>
4. <developerConnection>scm:git:http://admin@quartz:8080/gitblit/r/sample1
23.git</developerConnection>
5. </scm>
6. …
7. </project>

Next we will add credentials to your SCM server. Add property for project.scm.id, which will
reference this id in maven’s settings.xml in $MAVEN_HOME\conf. Add the following to your
pom.xml under the project tag:

1. <project>
2. …
3. <properties>
4. <project.scm.id>quartz</project.scm.id>
5. </properties>
6. …
7. </project>

5
Add the following to $MAVEN_HOME\conf\settings.xml under the servers tag:

1. <servers>
2. …
3. <server>
4. <id>quartz</id>
5. <username>admin</username>
6. <password>admin</password>
7. </server>
8. …
9. <servers>

The Maven Release Plugin is designed to store your released artifact, so we need to tell it
where to put this artifact. Add the following repository to your pom.xml, with an available
directory on your system.

1. <project>
2. …
3. <repository>
4. <id>localDeploy</id>
5. <url>file:///dev/repositories/releases</url>
6. </repository>
7. …
8. </project>

git init

git add *

git commit –m “initial commit”

git remote add origin ssh://admin@10.0.4.186:29418/test.git

git push -u origin master

Let’s do a release

mvn release:prepare release:perform

Answer each of the questions asked during the execution of this command with the default by
just pressing the “enter” key.

You will now find a war file under

6
Part 3: Artifact Management
Now that your build pipeline consistently versions your Maven project, you need a place to
store your artifacts which are being produced at the end of this pipeline. These artifacts need
to be stored much the same way your source code is stored in your SCM. This ensures access
to previously released versions of your product. An Artifact Repository is designed to store
your war/jar/ear/etc, and distribute it to fellow developers via Maven, Ivy, or the like, share
your artifact with your deployment tools, and generally ensure an immutable history of your
released products. An Artifact Repository has many more uses beyond storing the released war
files for you project, but that is beyond the scope of this article. For more information on
artifact repositories Sonatype, the makers of Nexus, have a nice introduction here
(http://blog.sonatype.com/2009/04/what-is-a-repository/#.VTfSdPnF8Ro)

First we need to install an Artifact Repository, my choice for this is Sonatype Nexus. I have
written a tutorial on how to install and configure Sonatype Nexus on CentOS 7, or you can
follow the Sonatype instructions on their website.

It’s time to change our pom.xml yet again. The distributionManagement section of the pom
needs to be updated and pointed to our Nexus server.

1. <distributionManagement>
2. <repository>
3. <id>nexus</id>
4. <url>http://quartz:8081/nexus/content/repositories/releases/</url>
5. </repository>
6. </distributionManagement>

Add the credentials of a user which has deploy permissions on the Nexus server. Modify your
$MAVEN_HOME/conf/settings.xml file and add the following within the server’s tag. I have
used the default Nexus username/password for the deployment user.

1. <server>
2. <id>nexus</id>
3. <username>deployment</username>
4. <password>deployment123</password>
5. </server>

7
Now we can perform a release of our war, and it will be stored in Nexus’s release repository.
This will allow other developers and system administrators’ access to the war to use as a
dependency, or to deploy to a production server.

mvn release:prepare release:perform

In order to download the new artifact “SampleWebApp123-3.01.war” open a browser and go to

Select “Repositories” in the left menu

8
You can now download any release you have made.

9
Part 4: Continuous Integration
At this point in time I assume you have Jenkins installed and ready to use. If this is not the case,
you can follow Jenkins Tutorial – Install Jenkins in order to get everything setup.

For those of you who are not familiar with Continuous Integration, the idea is fully build and
test every time a change to the source code is pushed to the Source Code Management (SCM)
server. This allows for very early detection of integration problems, and defects.

Let us start by making Jenkins check out our source code, and build it using Maven.

Go to the web interface for your Jenkins install. Mine is at http://quartz:8080/jenkins/. You
should see the following in the middle of the page. Click the “create new jobs” link.

Provide “SampleWebApp123” as the item name and select “Maven Project”.

10
Now we need to setup the connection between Jenkins and Git, however Jenkins does not
support Git out of the box so we are going to install a plugin. Go back to the Jenkins homepage
http://quartz:8080/jenkins/ and click on Manage Jenkins

Select Manage Plugins

11
Click on Available and search for “Git”:

Scroll down to find the “Git Plugin”, check the checkbox and click “Install without restart”.

Go back to the Jenkins Homepage http://quartz:8080/jenkins and click on the name of your
project:

12
Click configure on the left side

At this point you need to have git and maven installed on your development server. If they are
not installed, installation is as simple as:

$ sudo yum install git

$ sudo yum install maven

Fill in the appropriate values in the “Source Code Management” portion of the configuration,
and click save. If the repository URL is on the same machine, and the hostname is not set by
DNS, then you might have to add your hostname to the first line of the file /etc/hosts file such
as “127.0.0.1 localhost localhost.localdomain quartz”

It is best to use the http access to your git repository, setting up ssh access requires configuring
your keys which is beyond the scope of this article.

13
Scroll to the maven configuration section and fill out as this shows, or as matches your system,
and save the configuration.

You can now perform a build of your project by returning to the Jenkins homepage and clicking
the “Schedule a build” icon as shown below.

14
Next we need to install the Maven Release Plug-in Plug-in. Install this plugin the same way the
Git plugin was installed.

In order to save the Git and Nexus credentials, we need to add the Config File Provider Plugin the
same way the Git and Maven Release Plug-ins were installed. Then go to “Manage Jenkins” 
“Managed files”  “Add a new Config” and select “Maven settings.xml”

15
Add credentials for Git and Nexus as shown below:

Now that the credentials are stored in the config file, configure the Jenkins job to use this file.
Go to the “Build Environment” section and check the “Provide Configuration files” box and
select the file you just created.

16
Now you can use Jenkins to perform a release and store it in Nexus. Click on “Perform Maven
Release” in the job menu

Now you can enter the version number you wish to release.

At this point in time you have a complete build pipeline to produce consistent releases. Each
commit will be built, tested, and stored in Nexus.

17
Part 5: Parallel Deployment
Now that we have a consistent build pipeline, we will look at how to perform a Tomcat
deployment without users experiencing any downtime. In this part, I am going to walk you
through using Maven to perform the build and deployment, and then later on this can be
integrated into the pipeline to start down the path towards Continuous Deployment.

Part 5 assumes that you have Tomcat 7 running as described in my Lightning Tutorial –
Installing Tomcat 7.

The server which I am using for this tutorial is named “quartz”. Anywhere you see this name,
you will need to change it to match your hostname.

Before we start, open a web browser and go to http://quartz:8080/SampleWebApp123

You will see something similar to:

Hello World!
1.0-SNAPSHOT

Keep this browser open and edit the version in your pom.xml, to be 2.0-SNAPSHOT as shown
below.

<version>2.0-SNAPSHOT</version>

We can now deploy a new version of this sample web app to the same instance of Tomcat.

mvn clean package

mvn tomcat7:deploy

In a NEW browser, or in incognito mode if that is available in your browser go to

You will see:

Hello World!
2.0-SNAPSHOT

18
Refresh the first browser you will still see a version of 1.0-SNAPSHOT. You can see that Tomcat
has two versions of your web app running at the same time, Apache calls this “parallel
deployment” and you can find more information here https://tomcat.apache.org/tomcat-7.0-
doc/config/context.html#Parallel_deployment . Once your session for version 1.0-SNAPSHOT
expires, you will be directed to the 2.0-SNAPSHOT version. You have now deployed a web
application to Tomcat with zero downtime.

So long as versions of your web application are compatible with version of external resources
such as a database, this will work. If, however, you remove a column from your database, this
method will fail. To work around this many development groups frequently add database
columns, but only remove columns no longer needed a few times a year.

That is the end of Intertech’s DevOps Tutorial. We hope you can utilize this tutorial for your
own implementation. If you need help with a project, check out Intertech’s DevOps Consulting
services.

If you want to do more learning from an instructor, see Intertech’s list of DevOps training
courses.

19