What are you using for source control/version management in a UNIX environment?

You mean for maintaining webMethods Package versions?

Not really. On Windows platforms we’re using VSS. On the AS/400 we’re using Implementer.

They’re utilities that handle check-out, locking, and promotion of source. They “log” the changes and keep backup copies of previous revisions.

We have a team of 5 developers and are looking for something a little more “robust” than the canned tool that comes with wM.

Hi, JT.

What are some of your SCM team’s concerns? It’s true that the webMethods Platform doesn’t lay nicely into VSS, ClearCase and other packages. Not many integration platforms do.

In devising your strategy, make the webMethods pieces conform to your internal VSS guidelines. If you can achieve that, the VSS team will be able to manage the migration of your integration code/components and that leaves one less responsibility for you.

As more people grow comfortable working with the webMethods Platform, it becomes easier to get things done, IMHO.

Different corporations have different strategies and you can probably take a little bit from everyone to find the best plan. The one item I would hold ground on, though, is the issue of archived packages.

Let the webMethods server create archived packages and deploy those files to the target environment. In the target environment, use the Package Management services to unpack, install and activate the archive. Trying to promote package code java.frag by java.frag is not worth the hassle.

Others will chime in, I am sure. Good luck.

JT,

The strategy we take is very much in line with what Dan has mentioned. We were advised by some WM support people to take this approach as well.

We use the archived package as the “controlled” artifact of development.

We checkout the package from the SCM and then lock the package within the WM developer.

It therefore becomes very important to choose a packaging strategy that strikes a balance between granularity, function, and manageability.

At first - all of the actions required to code / bld/ promote were done manually - certainly error prone.

But - errors of that nature have not bit us too bad. We are gradually building the tools to automate the tasks. As Dan mentioned, there are some very useful flows at your disposal to assist with this automation.

Our environments run on UNIX

The build is “ANT” with some custom tasks and java utiliities to support the bld.

Hope this helps.

Haithem

• further to the last post…

We are using CVS for SCM

Haithem : We used to use CVS before we chucked it in favor of the built in change management and manually signed off forms.

> We checkout the package from the SCM and then lock the
> package within the WM developer.

Can you detail this a little bit more?

Do you do a ‘cvs checkout’ command to create a new version of a package under the /package/ directory of the B2B server. How do you deal with the ‘CVS’ directories created in there? (they get change promoted as well).

Do you use a ‘personal’ B2B server per developer, or just a shared server?

Also, have you found any way to use the branching/merging capabilities of CVS?

Sonam:

Regarding our use of CVS:

We have two scenarios (1) main line development and (2) Branched development.

(1) for main line development - we use a tool called HOP manage groups of files into a “change” unit of work. I don’t think HOP is relevant to this discussion - but it ends up that we work in a “pessimistic” locking model. Therefore - only one developer can access a file at a given time. No merging!

For webMethods packages:

• we first archive the package from the developer
• transfer the file from “replicate/outbound” to a cvs directory
• the “zip” file is then committed to cvs (in our case - using HOP).

(2) For Branched development:

• HOP does not handle this - so we have to use cvs directly

• Branching webMethods “zip” files is a little more manual work - but so far - has worked for us.

• First, we branch and tag the “zip” using cvs (same as any file) within cvs. This results in a version of the zip file from the point we need to branch in our cvs working dir.

• Second - we transfer the zip file from our working dir to replicate inbound in the webMethods server and import the package.

• Third - make the required changes to the package. When development is completed - the package is archived

• Fourth - we transfer the archived package from replicate/outbound to the cvs working dir and commit the change to cvs.

• Fifth - we have to make the same changes “MANUALLY” to the main line code. So this involves going back to cvs - getting the package back to the latest working version. We then use our main-line development model with HOP.

I guess the main point is that we have to manually merge the code from the branched version back into the mainline code so that the next release of the code contains the branched code (fix or new functionality).

We do follow the same procedure which Haithem mentioned,PVCS methodology for webMethods packages and sent to build.

It works…

Thank you Haithem and Ram.

Haithem -
you mentioned that in “main line development” you used HOP to “manage groups of files into a “change” unit of work.”

What is HOP’s advantage over the WM “locking” tool (in WM developer) used to ‘lock’ Flows during development?

Sonam:

(Please find below - another long winded answer - I hope it makes sense - its hard to put all this stuff into words in a clear fashion!)

If you have some time - I’d be interested to know how you manage your versioning and promotion of code.

Why HOP and CVS vs webMethods locking?

HOP does provide us with some value when it comes to versioning.

First - we had HOP and CVS already managing the web-app portion of our app, so our development team was already in that frame of mind.

Second - the change unit concept managed by HOP allows you to group many files into one change unit to achieve a particular goal.

In our testing and QA process, we promote code from dev through several levels of testing - based on HOP changes. If tests fail - then you back out the offending HOP change from the environment in question.

So in the webMethods world - a change unit might encompass code from several different packages. If you need to back out to a certain point in development- HOP gives you the ability to do that.

The combination of webMethods developer locking, and archiving (and versioning) of packages can all be done manually (on a package by package basis).

CVS and HOP for us, make this a little less manual.

Haithem

Hello Haithem -

Our change process right now is purely manual. Here’s our simple 3-step change procedure document:

WM B2B Change Release Procedure

Purpose of this document

This document describes how WM B2B changes are promoted from a source server to a target server. The source server is typically a development server (‘Development’) and the target server is typically a test or production server.

Procedure on Source Server

1. On the Change Request Form, note each updated package on B2B Development server that is to be released to test or to live. Note all TN changes to be made as well. Obtain signoff from Application Development Manager for change promotion:

2. On Development, for each package you want to release, go to:
   Packages > Publishing > Create Release >
   …and create the release for that package.
   While you are creating the release, make sure the version of the source package has been incremented.
   [ You can change the version number of a package in WM Developer. You can get the old version number by checking the old package on target server. Let us assume the old version of the package was 1.21. ]
   Now adjust the “release name” – this is the name of the physical ZIP file created so it has to be unique. Set it to <pkgname_1_22>.
   Everything else is as per defaults. Press the ‘create release’ button. You’ll now get a message like:
   Packages > Publishing
   Package CorporateExpressCommon_1_22 is released

3. If it’s a new package, add the Test server as a subscriber:
   Packages > Publishing > Add Subscriber
   Use “b2btest” for the test server name

4. Send all packages to the test server

Procedure on the Target Server

5. Install the inbound releases:
   Packages > Management > Install Inbound Releases
   You will get a message back like the following:
   CExCBLv30r2_Generic package installed and activated.

6. Once all packages have been installed on the target server, it’s recommended that you go to:
   Packages > Management
   and make sure there are no load errors

7. Also make TN changes if any.

Post Install Verification

8. Run the CECM tool to make sure all B2B package changes have been change promoted. If appropriate, carry out a manual check for TN changes.

We had begun to use CVS - but then switched to the simpler method above. Here, we are basicalluy using the B2B development server as our package repository. For backing out new changes, we have to manually track the change request forms (it happens rarely enough for this work well though).

The unitary change promotion concept is something lacking in CVS. I’ve been looking at subversion, and it offers some pretty interesting functionality.

I see you use HOP for building together a unitary set of changes - is HOP open source?

Hi Sonam,

For the promotion of Packages, I did the same way and it worked fine for me.

For patch relases I am having problems.
Ex : A full release for package is created in DEV and it is published to the TEST server.

Now , if I added any new Service in DEV for that package then created a patch release with only that service details.
I am trying to publish this patch release to TEST, the entire package in TEST is replaced with patch release details. (I lost full package in TEST and can see only patch release details)

Have you ever come across these kind of problems.

Thanks in advance
Ravi

Looks like you have not created your patch release correctly. Did you select the radio button for “Release Type - Patch”?

I suggest you check the ISAdministratorsGuide documentation, “Managing Packages” section. Also note the little comment about sending the manifest.v3 file in any patch release, make sure you understand this issue.

Hi Ravi - It looks like Martin has answered your question. As for myself, I’ve never released a patch - only full releases that overwrite the target server’s entire package. I think WM recommends this as well.

Just curious - why do you find it useful to release a patch instead of a full package release?

Sonam,

…is HOP open source?

Yes it is. URL below.

[url]https://sourceforge.net/projects/hopper/[/url]

Martin/Sonam,
Thanks for your quick response.

Martin - I selected the patch radio button and took all precautions for manifest.v3, still it did not work and it will not work in future also because just today I came to know that it is a bug in 6.0 and the behaviour has been carried from 4.6 version. This bug has been fixed in 6.0.1, it worked fine in 6.0.1

Sonam,
The reason I am going for patch release is , for ex:
If I added a simple service or modified an existing service, I just need to promote only those additions or modifications. I dont have to create full release with all package details to update these simple things in the subscription server eventhough there is nothing wrong in it. And as the patch release occupies very small amount of memory , The Integration Server performance will be good too.

Thanks,
Ravi.

Ravi - Just though I’d point out that the patch release process only takes up a smaller amount of memory during those few seconds when that patch is being imported on the target server. At all other times, your Integration Server performance will be the same as an IS that has full-package releases.

Thanks Haithem - I’ll check HOP out.

Hi Sonam/Ravi,

In the PATCH release to the target server, I need only to test the code which I have changed as against full testing for entire package.

Did anybody succeeded in controlling the versions of Patches? Appreciate any help…

RK

Haithem (and everyone else)

You mentioned using ANT scripts to move code from version control to a
target environment. I am familiar with many of the wM concepts around
package releases, but I was hoping to understand how ANT plugs into wM.

-We are doing shared development on a UNIX box and managing version control
at the package level (note we plan to link the file directory at the
package/ns directory in order to provide service and document level version
control…next release).

-For this release we plan to manually create package releases and move the
package from the outbound directory to ClearCase.

(this next part is the undefined part that I am looking for some insight)

-The automated build process will be ran by ANT scripts that grab the
package.zip files from ClearCase according to a label (note this is just a
base ClearCase term)…then the ANT scripts will ‘move’ the package.zip
files to the target environment, AND completely rebuild the wM environment.
One of my biggest questions is HOW ANT performs the ‘install inbound
release’ functionality that you need to do when you do this process
manually.

Please let me know if you have any advice or insight to this issue.
Thanks-------TD

Hi all,

We run our Integration Server on a Solaris machine and we are looking for a way to version control our webMethods resources. For ease of use we decided to use VSS for SCM and the Reflection FTP Client (primarily due to these tools’ GUIs). The resources are stored in VSS on a network drive and checked out to a developer’s workstation which acts as a staging area. The Reflection FTP tool is then used to drag and drop the resources to the Solaris server where the IS can access them.

I’d like to know if anyone else has used a similar setup and, if so, what their comments about it are. Also, at what level was the label set (package, folder, etc) and is there a labeling scheme that makes better sense for the webMethods environment?

Thanks in advance,
Tom

RE Thomas Derhake’s POST
(apologies for the late response! You probably have the answer by now…)

YOUR QUESTION:
One of my biggest questions is HOW ANT performs the ‘install inbound
release’ functionality that you need to do when you do this process
manually.

ONE POSSIBLE SOLUTION:
To automate the build - you can use ANT to invoke the flows in the pub.packages folder.

RE: Tom’s post:

So far - our experience is strictly managing packages. This has worked quite well - and I believe was recommended by WM.

If you go the package route - just take some time and think about the granularity of code you want to capture in each package. Too fine grained makes it a hassle to find anything and may be detrimental to reuse - but too coarse grained makes the packages quite bloated with functionality and makes team development a real hassle.