Presentation - Hudson/Jenkins: Beginner to Expert

Here is the presentation I gave at COJUG

• "Hudson/Jenkins: Beginner to Expert" - slide deck lives on SkyDrive


• Corresponding demo - lives on github

Abstract:
Come learn appropriate practices for Continuous Integration in an Agile age. Jenkins (a.k.a. Hudson) is a flexible CI solution. I'll walk us through its simple setup, show some of the plug-ins, and then dive into leveraging Jenkins for a multi-application, enterprise solution. I think you'll see that Jenkins can not only perform the CI duties of build with unit tests, but can also serve as a dashboard for numerous deployment and automated tasks.

.

Read More »

Migrating from Git to Svn and Svn to Git

The following steps will migrate to and from GIT while maintaining all commit history.

svn2git# First, create a new GIT Repo
# Then, do the following
git svn init <svnUrl>/<svnRepoName>
cd <svnRepoName>
git svn fetch
git svn rebase
git remote add new <user>@<gitRepo>
git push new master

git2svn# First, create a new SVN Repo (with at least 1 file in it)
# Then, do the following
git svn clone <svnUrl>/<svnRepoName>
cd <svnRepoName>
git remote add old <gitRepo>
git fetch old
git checkout -b old_master old/master
git rebase --onto master --root
git svn dcommit

Read More »

SVN Migrate folder to new repository root

Since I've been asked about Subversion's "svnsync" command more than once, here is a copy of my post on stackoverflow.

The svnsync option worked for me with subversion 1.5.3.
Here is a Windows batch script to accomplish this:

SET OLD_REPO_URL=https://old-project-repo/my-project
SET NEW_REPO_URL=C:/Repositories/new-project-repo
SET NEW_REPO_FILE_PATH=C:\Repositories\new-project-repo

svnadmin create %NEW_REPO_FILE_PATH%
echo exit 0 > %NEW_REPO_FILE_PATH%\hooks\pre-revprop-change.bat

svnsync init file:///%NEW_REPO_URL% %OLD_REPO_URL%
svnsync sync file:///%NEW_REPO_URL%

Note: You will not be able to browse the new repository until the sync is finished.

Read More »

Presentation - Hudson/Jenkins: Beginner to Expert

Here is a presentation I am giving at The Columbus Polyglot Programmers Meetup Group

• "Hudson/Jenkins: Beginner to Expert" - slide deck lives on SkyDrive


• Corresponding demo - lives on github

Abstract:
Learn appropriate practices for Continuous Integration in an Agile age. Hudson (forked as Jenkins) is a flexible CI solution. This presentation walks us through its simple setup, show some of the plug-ins, and then dives into leveraging Hudson for a multi-application, enterprise solution. I think you'll see that Hudson can not only perform the CI duties of build with unit tests, but can also serve as a dashboard for numerous deployment and automated tasks.

.

Read More »

Release Naming Strategy

This is my preferred Release Naming Strategy. Not a big deal if you disagree, at least you have a template so you can document your strategy.

Externally:
<major>.<minor>.<patch>
ex. 1.03.8

Internally:
<major>.<minor>.<patch>-<hudson-build-number>
ex. 1.03.8-27

<major> - Introduces major new functionality and often involves marketing. Resets the minor number to 00 and patch number to 0.
ex. 2.00.0 (May be referred to as the “2.0” release.)

<minor> - Indicates an addition of some features. Always two digits with pre-fixing zero for numbers less than ten. Releases should sort numerically, not alphabetically. This allows for a buffer of incremental minor releases before incrementing the major number which has different perception to the end user. Resets the patch number to 0.
ex. 1.09.0, 1.10.0, 1.11.0 (May refer to 1.11.0 as the “1.11” release.)

<patch> - Indicate a fix (ie. fixing a bug, improving performance, or an internal change without impacting functionality such as logging). Goes up by one every time a patch is officially added to the version. Use a single digit here because you should not have as many as 10 unplanned patches prior to a minor release.
ex. 1.03.1, 1.03.2, 1.03.3 and so on

Release Notes Template with Example

Read More »

Eclipse Shared Plugins Directory

Did you know there is a way to point your local install of eclipse out to a shared directory containing the plugins? There is ... by way of a links folder. Now, there are a few other blogs out there if you google "eclipse plugins links folder", but hopefully you'll find mine as a good summary.Prerequisite:You must have your workspaces outside the eclipse home directory. This is not only best practice because it decouples your custom project from the eclipse installation, but it will also alleviate any pain point with my caveat below. (i.e.
. . c:\workspaces\HelloWorld

Steps:
1. On a shared drive, create the folder structure of:

. . eclipse\features

. . . . . . .\plugins

The folder must be called eclipse with subfolders matching exactly 'features' and 'plugins'. These folders should be empty initially. I put this entire structure under a root folder called "eclipse-plugins" so I can recognize it. Mine looks like this:

. . \\myShare\eclipse-plugins\eclipse\features

. . . . . . . . . . . . . . . . . . . . . . . . . .\plugins

2. Determine the net new plugins that you installed on top of the default ones from eclipse by sorting both the plugins directory and the features directory by "date modified". All the install provided ones come with the same timestamp. Move all the net new ones out to the shared location (i.e. plugins to the shared plugins directory and the corresponding features to the shared features directory.) Typically, each plugin has a corresponding feature to go with it. Be sure to grab both.

3. Create a new folder called "links" and place in your local eclipse home directory. (i.e.
. . c:\eclipse\features
. . . . . . . . .\links
. . . . . . . . .\plugins

4. Inside links, create a new plain text file called plugins.link. (Technically, it can be called anything.link) In it put the line:

path=\\\\myShare\\eclipse-plugins

The path should not have a trailing slash and must point to the directory which has the eclipse folder.
(Yes, Windows needs to escape the backslashes. On Linux just do /myShare/eclipse-plugins.)

5. Download a fresh zip install of the eclipse version you wish to use. Add to this zip file your links folder with plugins.link file and re-zip it up. Put this file out on a shared drive and distribute to your team as the team's standard install. (Now, you've pre-packaged it with the links reference ready to go!)

6. Finally, launch eclipse. It will first load the plugins from your local eclipse home directory, then it notices the links/plugins.link file and proceeds to load any plugins from that path as well.

Things to note:

You only need the net difference between the share and the install. You don't want to put all the default ones out on the share.

Caveat:

It seems that once you start eclipse pointed to a share it caches what plugins it recognized. This means that if a plugin is deleted on the share, your eclipse might still try to load it the next time you start. I've tried starting eclipse with the command "eclipse -clean", but it doesn't seem to matter. However, it's not a big deal because now your eclipse home is nothing more than the install zip file (with your links folder) extracted. To pick up any shared plugin changes, simply delete your eclipse home directory and re-unzip the eclipse install. (You have your workspace elsewhere and any installed plugins elswhere so there is nothing you care to save in this directory anymore.) Start her up again and it will cleanly load all the plugins from the shared drive.

Sharing other eclipse settings:

I recommend making settings changes at the project level, not eclipse global level. Thus it puts the configuration in the .project file which can then be checked in with your project in SVN and checked out by others so they are ready to go. Else, if you use the eclipse global settings, at least put the settings files out in SVN and direct your team to do this one time setup each time they perform an eclipse install.

Oh and I need to give credit to a great post on the subject here: http://www.venukb.com/2006/08/20/install-eclipse-plugins-the-easy-way/

Read More »

10 Things You Could Automate with Hudson CI

Here is a presentation I recently gave on the topic.

Read More »

Gant Helper

Using Gant for build scripts is pretty cool because it is a lightweight facade over Ant. You can do anything you can do in Ant by converting the syntax, but also mix in Groovy code. Using Groovy to script means better reuse of code and shorter build scripts. To learn more about Gant, read this page: http://gant.codehaus.org/

For those of you familiar with Gant, I have created a few helper closures at the top of my script that you may find useful.

includeTool << env = { variable -> return System.getenv()[variable] }
prop = { propKey -> return ant.project.properties[propKey] }
log = { target -> println "\n[${target.name}] ${target.description}" }
run = { command -> def out = ""; execute.shell(command, outProcessing:{out+=it+"\n"}); return out}
"env" - shortcut to reading environment variables. Example:

buildNumber = env('BUILD_NUMBER')
"prop" - shortcut to reading properties that were loaded into ant. Example:

appName = prop.'application.name' //If you know Groovy, you know it could also be: prop('application.name')
"log" - By default, Gant won't print the targets as they are executed. You get the Ant task prints, but this is helpful when you use "depends" and want to follow the script. Just use "log(it)" or "log it" at the top of each target in you script. Example:

target(compile: 'Compile everything') {
log(it)
ant.groovyc( ... )
}
Prints:

[compile] Compile everything
[groovyc] Compiling 1 source file
It can also be used for methods by manually passing the "it" object:
def junit() {
log([name:'junit', description:'Runs all JUnit Tests'])
}
"run" - executes a shell command and also returns the output. Example:

def svnlogOut = run("svn info")
println svnlogOut

Read More »