Step 2: Set up a Repository

Before you can load a baseline for your release, you have to set up a place to put it.   In CA SCM, this is called a Repository.   The definition of Repository in the documentation is very simple:

A repository is a collection of items and item paths

You can think of Items as files and item paths as folders.  In truth, an item is  the information about a single Configuration Item.  The file itself, is always a Version of an Item.   So a repository is a collection of Items and their Versions organized with Item Paths.

An administrator can load files into a repository with the admin tool, but the only way a regular user can affect a repository is through Packages in a Life Cycle. What’s really cool is that a Repository can be associated with one or more Life Cycles.   So you might have different kinds of processes that manage change on the same configuration items.   This way, you don’t have to create one MONSTER process to manage everything.  You can design Life Cycles that manage your various processes from Service Desk, to Release Management, to Maintenance, etc.

Steps to Setting up a Repository:

1. Login to CA SCM Administrator and select the Repositories tab
   

   CA SCM Administator Repository Tab

2. Right-click the broker node and select New Repository
   

   Right-Click Broker node

3. Give your Repository a unique name.   Ok, this is a good time talk about a choice you need to make.  Will your repository be used over and over again for many iterations and have a long trail of versions?  Or will it retain only the development iterations on a single release?  In my case, I’m focused on the development of a single release, so my repository name will be the name of my release.
   

   Repository Properties Dialog

4. Click Apply
5. Setup Access to your repository.  Click the Access tab of the Repository Dialog.   Note that there are three Access Types in the drop-down field:  Secure Access, Update Access, and View Access.  I’m not sure what Secure Access is.  I just set it to the Administrator group.  Update Access needs to go to your developers.  View Access needs to go to your developers and any other group that needs to view the code.
6. Click Ok.  Congratulations, you have a place to put your crap.
7. Load your Baseline into the repository.   If you’re using Eclipse and the CA SCM Plugin, it’s important that you load each entire Eclipse project that you are using to work with your software.  Right-click your Repository node and select Load Repository.  This will bring up the Load Repository Dialog
   

   Load Repository Dialog

   Browse out to your local machine to find the files that will make your baseline.  Check Recursive so that you can get all the files and folders in you projects.  Use “*” in the Files field to get all file types.  If you set up some subfolders in your Repository for this project or that, your can specify them in your Repository Path field.

   NOTE:  You can create a repository by duplicating another repository, so the files from your last release are already loaded.

8. Click Load and watch it go!

CRUCIAL STEP

Just because you have a place to put your crap, doesn’t mean you have access to it from your Life Cycle.   The key to CA SCM is Association.  This is what gives the tool it’s flexibility.  You must add your repository to the Baseline of your Life Cycle.

1. Navigate to the Baseline node of your Life Cycle
   

   Baseline Node

2. Right-click node and select Configure Baseline
   
3. Add one or more Repositories from the Available Repository/View List
   

   Configure Baseline Dialog

Woo Hoo!   Now, this is where it gets fun!

 

The Bible on Documentation of Code

Leviticus 19:38

“And to those who have been given the task of writing the code of the Lord, also too shall they be given the labor of documentation. For it was said upon the mountain of the Lord that undocumented code is an abomination unto the eyes of the Lord and it is like a thorn in the foot to those who shall maintain the code by day.  Thus saith the Lord.”

Hezekiah 13:9

“Comments in your code will reveal the thoughts and intents of the program to all who seek the truth”

From the Sermon on the Mount
And Jesus said, “Blessed are those who document their code, for they might inherit the maintenance of their code and will give praise unto the Lord for it’s clarity.”

 

Step 1: Setup a new Life Cycle

CA defines a Life Cycle as:

…the set of all the stages (states) a change or release goes through from identification to completion; it defines a model for a particular development and maintenance process.

Anyone who’s been with this product for a long time will inevitably chuckle to hear the term Life Cycle because it’s the third name for this feature.  The evolution is  Environment–>Project–>Life Cycle.  In the database, you can still see the evolutionary evidence of Environment in the table name HARENVIRONMENT.  You can also see the evidence of the product’s former name:  Harvest. 

Regardless of what you call it, it’s a damn good thing.  This is what differentiates CA SCM from a version control system.  It is a Software Change Management system.  You cannot change source without a Package (CA SCM’s representation of a software change unit of work or project task), and you cannot have a Package without a Life Cycle.   It’s up to you just how much accountability and control you want for you Life Cycle, but this is a tool that really wants you to operate in a well-defined, well-documented, repeatable process.

You can start from scratch or you can use another Life Cycle as a template.  For the sake of repeatability, I chose to use an existing Life Cycle as a template.  CA SCM comes with a library of very useful templates from which to choose.   I chose the Release Model for this particular software release.

Release Model Life Cycle Template

It has four States:  Development, Test, Release, and View SnapShots.  Each state has a list of pre-built processes.   Also, notice that it has a set of Data Views.  A view is how you isolate change in states.   For example, the Test view shows the state of the code in the Test State.  You will not see code that’s still in the Development State in the Test View.

To make this template an Active Life Cycle:

1. Select “Copy To …” from the context menu for the template
   

   Copy To

2. Name the new Life Cycle.   You should give it the name of the software release you are about to begin.
   

   Copy Project Dialog

3. Click OK!

By default, rights and access within this Life Cycle are controlled by two User Roles:  Dev Manager and Developer.   You must assign team members one of these roles for them to be able to use this Life Cycle.  You can also choose to create your own User Roles for more fine grained and project-specific control.

So, we have a life cycle.  These out-of-the-box templates are  very well-documented, in the Administrator Guide, so I won’t go into the details.  But I will say that this is a fairly sophisticated release management process that can be extended to become a full-blown continuous integration environment.   So what’s next?  Remember our important CM word for CM studs only?  Yes, that’s right, it’s time for a Baseline…

 

Dependency Injection, Interfaces, and Mocking: our new shop standard?

Ok, raise your hand RIGHT NOW if you said “Oh my” after “Dependency Injection, Interfaces, and Mocking”.   If you didn’t, drop what you’re doing and go rent “The Wizard of Oz” because you’re really missing a monumentally important American cultural reference.

I don’t recommend the adoption of new shop standards very often for my team.  Yes, I like us to be nimble and up to speed as much as possible, but I’m not really a bleeding edge kind of guy.   I like standards that solve REAL problems.

Real Problem #1:

How do you write a unit test for a unit that depends on other units that you don’t have yet?

Real Problem #2:

How do you send your application to a super smart friend (who will be able to fix your 2 month old bug in 2 seconds) when the application depends on internal resources such as a database?

Real Problem #3:

What if you’re coding the Service tier, and some other guy is developing the persistence tier and he keeps changing his implementation in a way that causes you to have to change your implementation?

“Ok, David, here’s the new class and here’s how you instantiate it.”

“Great, thanks, Joe.  I just finished  building, testing, and deploying my application.  I’d just LOVE to do it again.”

Ok, so these are real problems that my real team of RAJPs have struggled with over the last year.  If you are not a RAJP (say, a JG (Java Guru) or a JPE (Java Programmer Extraordinaire)) you probably have a super duper array of frameworks and techniques to solve this problem that I will not figure out how to use until my RAJP solution is no longer working for me.

Solution

Step 1: Write all of your DAO classes to an Interface.

Writing to an Interface is the design foundation for all things loosely-coupled.

PickleDAO Interface

Step 2: Implement a Mock and a fully Implemented version of all your  DAO classes (to an Interface of course).  If you have any other DAO alternatives (a web service, a local cache for offline use, or whatever) be sure to implement the same interface.

You probably want to start with the Mock implementation first.  This will get you up and going quicker.

Mock Implementation of the PickleDAO

Notice the use of test data in my mock.

When you finally get around to fleshing out your DAO then you’ll start with something more like this.

Actual Implementation of PickleDAO

Step 3: Inject DAO instances into your Service object based on specific deployment needs.

There are a lot of different ways to accomplish Dependency Injection.  We’re using Spring.

I specify which implementation of PickleDAO to use at runtime in a Spring Configuration file.  For this deployment, I’m instantiating PickleDAOMock

Spring Configuration file to injection the PickleDAO instance

All that remains is a simple injection…I promise it won’t hurt!

PickleService with DAO injection

Now, I can just hear some of the guys on my team whining about how many more source files are required to accomplish this design.  Here’s what it looks like:

Package Tree for my bogus Persistence Layer

But come on, guys!  This is how we make our living…writing code!

Summary

If you design your persistence layer with this pattern,  you will provide optimum flexibility with loose coupling.   This solves all three of the problems that I described above.

Problem #1: When testing units that depend on a DAO that you haven’t fleshed out yet, switch the configuration to inject the Mock DAO.

NOTE:  The Spring folks recommend directly instantiating your Mock objects in your unit test rather than injecting.  I’m not yet experienced enough with unit testing to argue for or against this, so I’ll just leave at that.

Problem #2: Before you send your code off to your super smart friend, reconfigure your Spring config to instantiate a Mock or some other kind of instance that won’t require that resource.

Problem #3: The persistence guy can switch DAO implementations to his heart’s content without the Service guy ever noticing.   Worst case scenario is that the Service guy has to change his Spring config.

Perhaps one day, I’ll get tired of writing my own mocking and will use JMock or something slick like that.   If I do, I’ll be sure to tell you about it.  Until then, I’ll stick with my Regular Average Java Programmer approach.

 

Change Management: Starting with the basics

I was chatting in a crazed and maniacal manner with my coworker, Hobi, about my vision for change management for our team.  Hobi is a helpful guy to me, because he’s very good at forcing me to face the reality of my ignorance when necessary.  He threw me a few basic questions, to which I had to admit ignorance, and then, as I continued pontificating on my glorious plan I watched him slowly check out of the discussion.  He then stopped me in mid sentence and said, “Maybe you need to draw yourself a picture of what you’re trying to do.  See ya.”

Ok, so this is my cue to start with the basics.  The picture will come soon enough.  As my father (and little league baseball coach) always says, “Focus on the fundamentals and everything else will fall into place.”   Alright, so what is the hitting, throwing, catching, and base-running of change management?

In reading about Change Management, I quickly came across some other important related terms.

• Service Request Management (Service Desk)
• Incident Management
• Problem Management
• Release Management
• Configuration Management

Holy Crap!!!  I hear these terms every day, and often hear them used interchangeably!  Oh no!  The only thing that is clear to me is that starting with the basics begins with understanding how to even title this blog!  I don’t know whether I’m trying to learn about Software CHANGE Management or Software CONFIGURATION Management.  Of course, as is so often the case in questions involving a choice, we can defer to the old slippery political side-step:  It’s really both, David.  It’s really both.

Fortunately, where there’s complexity in IT, there’s a standard.  The standard is ITIL:  Information Technology Infrastructure Library.  So, to help us understand how all of these processes work together, I defer to wikipedia .

Here’s your RAJP summary:

Service Request Management (Service Desk)

No brainer.  This is the user’s single point of contact for service regarding your software.  It covers everything, so I won’t bother listing everything.

Incident Management

Something screws up.  You fix it.

Problem Management

Something screws up.  You fix it.  It screws up again.  It’s a problem.  You investigate and fix the root problem that is causing the screw ups.

Change Management

The process you use to make changes to the system.  In the case of software, it’s called Software Change Management.  Commonly, SCM.

Release Management

Ok, so you’ve fixed some problems and you’ve added some new features.  At some point, your users are going to want to actually see these changes.  Release Management is the process of planning, communicating, building, QA, and deployment of a new release of your software.

Configuration Management

Your IT infrastructure is made up of a lot of components.   From the perspective of Configuration Management, every component is a Configuration Item (CI).   Configuration Management is all about tracking  changes on or between these items.  For SCM, your primary CI is your source code files.  So, we’re talking about baselines and source control.

**BONUS WORD**

Ok.  If you really want to talk the talk in SCM you have to use the word “baseline” about 250 times a day.  It’s such a simple sounding word that it can be used to intimidate the hell out the non-CM studs in your organization.  It sounds simple, so people are afraid to ask what it is (like me).  Well dammit!  I finally asked.   A baseline is the approved state of your software for starting changes for your next release.  This is probably going to be the state of your source code at the point of your last release.  So, an important goal of SCM is tracking the changes on every CI for a particular release from a specific BASELINE.  So if 3.1 was your last release, the source from 3.1 will serve as the baseline for your 3.2 release…simple.

Think this is all there is to ITIL?  Well, you’re wrong, buddy.  Dead wrong.  But this a good place to start.  So I’ll leave it at that.

 

Time to join the party: Change Management and Continuous Integration…with CA SCM?

I, like many RAJPs out there, suffer from all kinds of inferiority complexes.  I see other developers doing things like “Unit Testing” and sending there applications to something called  “QA” and I think  “Hey!  Why wasn’t I invited to this party?  I want to play with the big boys, too!”    Well, I’m trying to get into this unit testing habit…slowly.  And we now have a QA specialist on our team.  And although we do something resembling version control, I’m seeing that there’s another party going on that I never bothered to attend.  Sure, I may stand on the wall and move a little to the music from time to time, but I’ve never truly jumped out onto the dance floor and busted out the white-man’s overbite while pumping both fists into the air in front of me like a true Change Management/Continuous Integration stud!

So, I’m serious about getting serious with CM and CI, but I have a lot to learn.  I’ve been involved with a product called CA SCM (CA Software Change Manager…formerly Harvest) for over 7 years now I’m still standing on the wall with it.   Well, now I’m ready to boogey, but how?

During a super training class on Hibernate, our instructor, Brian Sam-Bodden (author of Enterprise Java Development on a Budget and Beginning POJOs:  Spring, Hibernate, JBoss, and Tapestry), turned our team onto the idea of Continuous Integration.  He laid out a beautiful picture with 3 Sun Solaris servers, Cruise Control, SVN, Maven, MyEclipse, and Glassfish.  All open-source (which I like).  I took the plan to my CA SCM admin and he said, “That’s pretty cool, but did you know CA SCM can do all that?”

Can you believe this guy? GEEZ!  What a buzz kill!  What a killjoy!  He just rained all over our little CM/CI parade.

See, we think  of CA SCM as like our old junker that we drive on back roads so that no one will see.  We don’t wash it.   It still plays cassette tapes.  It’s backseat floorboards are littered with perfectly preserved McDonald’s french fries from the previous millennium.  Why would we want to do something new and cool with it?  I politely nodded to the kindly old admin and said, “Thanks, buddy.  We’ll take that into consideration.”  (By the way, our admin would take offense to being called kindly OR old…buy just roll with it.  It makes a better story.)

Sure, we want to go to the party, but not with an old proprietary geezer like CA SCM!  But then I went to Las Vegas for the CA World Conference and spent a week with CA SCM r12…and that old geezer can rock with the best of them.  In fact, I’m willing to jump out onto the dance floor and bust out the white-man’s overbite while pumping both fists into the air in front of me…like a CM/CI stud!

Me a the CA World conference after one too many sessions on Change Management

I will spend the next month or two blogging the challenges and triumphs of using CA SCM r12 with Sun Solaris, Glassfish, MyEclipse, and Ant (or possibly Maven or possibly OpenMake Meister) to ahieve CM and CI on our next project.  Can CA SCM stand up to the likes of SVN/Cruise Control?  Will I lose all of my open source friends in the process?  I’ll be sure to let you know.

Get your back up off the wall, RAJPs!  Let’s end this year with a bang!

 

Thoughts, Struggles, and Excitement with Unit Testing

I few weeks ago, while attending the Central OKC Java Users Group, the presenter asked for a show of hands for how many people had actually used EJB 2.0.  In a crowd of over 50 java programmers.  If anyone raised their hand, I didn’t see it.  You mean to tell me that I suffered guilt and shame over not using EJBs for years for nothing?  You mean to tell me that I was suffering under the delusion that I was the only java programmer who thought that EJB 2.0 seemed cumbersome and of little value given the effort?  Geezaloo!  I thought EVERYBODY was using EJBs…at least until POJO frameworks gained popularity.  Just goes to show you, don’t drink the Kool-aid unless you see it mixed and poured with your own eyes!

Enter Automated Unit Testing.   For years now, I’ve read about automated unit testing with JUnit.  I’ve read articles about it.  Done tutorials where I test a method that takes two integers and adds them together.  I’ve suffered guilt and shame for not doing automated unit testing.   I’ve also suffered in trying support my own buggy code.  And when I’ve tried to write unit tests for real-world scenarios, I’ve struggled to figure it out.  I asked a veteran java programmer if automated unit testing was mixed from the same batch of Kool-Aid that EJB 2.0 was mixed.  She assured me that it wasn’t.   And now I know that she is right.   Automated unit testing is not only achievable, but CRUCIAL!  (I say this with a whole 2 weeks of JUnit under my belt)

I’ve been limping along for years testing the unit only to the extent that my functional testing happens to use this unit or that.  If something blows up, then I drop a breakpoint and take a look.  I’m here to tell you, friends,  that this is not sufficient testing.   Just in the two weeks I’ve been writing JUnit tests for my code, I’ve uncovered half-a-dozen bugs in a class that had already been functionally tested.   These are bugs that had never seen the light of day because the presentation layer could not yet present the unit with enough scenarios.    And now, I’m beginning to actually engage in what was previously believed (by me) to be a purely mythical activity that only organizations like NASA engaged in:  Test Driven Development.   Test and Code, Test and Code, Test and code…whoa!   And I’m writing the best code of my life…code that considers all possible scenarios.

One of the toughest challenges I’ve faced so far is when the class that I’m testing depends on outside resources.  I’ll take some time later to blog about how I’ve used Spring and Mock Object patterns to simulate outside resources.

 

Coming up for blog air…

I’ve been hard at it for a number of weeks.  I’m sorry to say that I’ve made very little contribution to this blog because of it, but I’ve seen the error of my ways and I’m willing to make amends.   Consider this post a promise to write about the following topics:

• Unit Testing a JHSDK (Java Harvest SDK) application
• Thoughts, Struggles, and Excitement with Unit Testing
• ICE ICE BABY!  Marveling at IceFaces 1.7

 

Deploying JHSDK in a Java EE environment

Introduction

Deploying a web application that uses the JHSDK is not as simple as throwing a jar file in your lib directory. The JHSDK is a little different than other java libraries on three counts:

1. it is a java wrapper for a C++ library. Allfusion Software Change Manager 7.x is a C++ application. The upcoming v12 release is a java application, so this C++ layer will go away. But for now, we’re stuck with it.
2. it is a bridge for communicating with another enterprise system. Harvest is a non-web, n-tier system for managing change on software and documents. It has a proprietary front controller that brokers requests from various Harvest clients.
   
3. it’s classes are not serializable, which presents problems when using it in Java EE environment

So, for your Java EE application to use JHSDK it must

1. know where the C++ libraries reside
2. run in an environment that has a Harvest client installed
3. use serializable wrappers for the JHSDK classes that you need to persist

CA provides detailed documentation for setting up the environment in their Installation Guide. If you’re not accustomed to installing a Harvest client, this can be somewhat challenging. I found it very easy to deploy my web application to my local windows installation of Glassfish because I already have a working Harvest client installed; however, I worked for nearly three weeks with my Sun admin, Harvest admin, and CA Support to configure our development Solaris environment. We had never used a Harvest client on Solaris before, and you know how UNIX environments are: SOME ASSEMBLY REQUIRED.

Windows Deployment

This is an account of my deployment to a Java EE platform on Windows

OS: Windows XP SP2

Application Server: Sun Java System Application Server 9.0 Update 1 (glassfish v2 ur1)

Harvest: AllFusion Harvest Change Manager 7.0

I didn’t have to set up the Harvest Client because it was already done, so I won’t comment on that.

In Windows, there are two files that Glassfish needs to know about: jhsdk.jar and JHSDK.dll. Both of these files need to be your Glassfish’s path.

You can put them in

GLASSFISH_HOME\lib

or

GLASSFISH_HOME\domains\domain1\lib

If you deploy the jhsdk.jar file without the JHSDK.dll file, then you will receive the following error:

java.lang.UnsatisfiedLinkError: no JHSDK in java.library.path

At this point in the development process, my application provides a list of versions for a particular Harvest Package. The JCaVersion class does not implement java.io.Serialiable, so I was not able to bind it to my JSF component. So I wrote my own version of JCaVersion. I looped through my array of JCaVersions (which is returned from JCaPackage getVersionList()), and built an array of MyVersion instances with the same data. Then I could bind my array of MyVersion instances to my JSF component.

Finally, I deployed my WAR file and I was ready to go. I was so excited. WOW! That was easy! I’ll just deploy it on the Solaris box and I’ll be ready for show and tell. And……PRESTO!!! 3 weeks, 5 support emails to CA Support, a chat fight with my Sun admin, 50 meetings with my Harvest Admin later, it’s working!

Solaris Deployment

OS: Solaris 9

Application Server: Sun Java System Application Server 9.0 Update 1 (glassfish v2 ur1)

Harvest: AllFusion Harvest Change Manager 7.0

The first issue that arose was that the client was not fully installed on the Solaris box. Our app server and the Harvest server happen to be installed on the same machine, so the client should have been installed and available already. The key command-line utilities were there, and the HSDK and JHSDK are supposed to come with the command-line utilities, but they didn’t. So, we reinstalled the command-line utilities, and that set up all the files and directories we were needing.

Once we had the client installed, we needed to configure an environment for using the JHSDK. CA’s installation guide is pretty explicit, but I had trouble using it…perhaps because I’m not really that skilled with Solaris. Here’s what my env looks like:

JAVA_HOME=/usr/java
HARVESTHOME=/xxx/ca/harvest
CACRYPTINI=/opt/CA/CAcrypto/cacrypt.ini
CACRYPTDIR=/opt/CA/CAcrypto
DVHOME=/xxx/ca/pec/graphics/sun4_solaris
RTARCH=sun4_solaris
RTARCH_UC=SUN4_SOLARIS
RTHOME=/xxx/ca/pec
_app=/xxx/ca/pec/app-defaults
export JAVA_HOME HARVESTHOME CACRYPTDIR CACRYPTINI
export DVHOME RTARCH RTARCH_UC RTHOME _app
LD_LIBRARY_PATH=${CACRYPTDIR}:${RTHOME}/lib/sun4_solaris:${RTHOME}/graphics/sun4_solaris/lib:/usr/lib
LD_LIBRARY_PATH=${HARVESTHOME}/lib:${HARVESTHOME}/HSDK/lib:${HARVESTHOME}/JHSDK/lib:$LD_LIBRARY_PATH
PATH=${RTHOME}/bin:${HARVESTHOME}/bin:$PATH
export LD_LIBRARY_PATH PATH

I recommend following CA’s advice to test your environment with the sample JHSDK application as detailed in the Installation Guide. This will tell you whether or not you were successful.

The next step is to configure Glassfish. This is where it gets weird. Even though we’ve setup all this path info in the environment, we have to do it again in Glassfish. My guess as to why? The Java EE environment needs to know the paths to the native libs so the when the JHSDK classes are called, then can know where to find their C++ peers. The user environment needs to know the paths so that when when one of the native C++ classes is called, it knows where they are and where Harvest is. Again, that’s my best guess. If I learn different, or if you know different please tell me and I will give an update.

So here’s what my Native Library Path Suffix in Glassfish looks like:

xxx/ca/harvest/lib:/xxx/ca/harvest/HSDK/lib:/xxx/ca/harvest/JHSDK/lib:/opt/CA/CAcrypto:/xxx/ca/pec/lib/sun4_solaris:/xxx/ca/pec/graphics/sun4_solaris/lib:/usr/lib

Here’s what my Classpath Suffix looks like:

usr/java/jre/lib:/usr/java/lib:/xxx/ca/harvest/lib:/xxx/ca/harvest/HSDK/lib:/xxx/ca/harvest/JHSDK/lib:/xxx/ca/harvest/JHSDK/lib/jhsdk.jar

Look for future posts here on my use of JHSDK in my Java EE application. The journey has only begun…

 

Update on Enterprise Java Harvest SDK

Ok.  This stuff is NOT easy.  No problems on Windows platform, but Solaris is a whole ‘nother ballgame!  I don’t really want to publish anything until it is working.  I’ll give you a nice guide to JHSDK in the enterprise environment when all my issues are resolved.  CA Support has been helping me get through this, and I expect to have a breakthrough any day now.

The primary issues revolve around configuring my Glassfish environment to recognize all the C++ libraries that accompany the java toolkit.

Sun?!!!  If CA can’t get me through this then you’re next!  I will be knocking on your door to get some help even I have to PAY for it!