Manage library versions between different environments

BPS_Pid

Hi all,

how you manage the differents library version numbers in different environment (development, test, production)?

Now we mantain a wiki page on which we manually log, for every library, the differents versions on all environments.

For Example:

Library1 Dev version: 54 correspond to Test version: 12 correspond to Production Version: 12

We update this wiki page whenever we deploy another version of the library in test and production env.

Also we use NOTES field to save informations about the related version in other env.

I don't like this approach because is completely manua, but this is the only that i've found.

Is there an official approach or any best practices to follow?

How you are doing this job?

thanks

Max

Find more posts tagged with

BPM

Comments

Tom Waskow

We have settled on a best-practice of always referencing the production-library in all projects (even if the projects themselves are in development or test). We came to this after realizing that a referenced library is essentially copied into a project when the project is deployed. There is no need to reference a library only from the same environment.

In fact, unless a library is under active development we remove it from the development and test environments to avoid confusion.

This assumes of course that the production version of the library is stable. If the library a moving target as well then the versioning does become confusing.

Jerome_Pearce

This is an interesting question, but mainly because it raises another one: Do you ever use different versions of a library for different solutions?

Our approcah is quite simple, and has always worked (ever since libraries were introduced in version 6). We always expect to, and always do, use the latest version of all libraries.

Now, in order to do this, we are forced to ensure that all existing code will still work with any updated functions and components when they are refreshed. It does take a little care and attention to detail, but I have never come across any situation where this cannot be managed. It also follows best-practice for any reusable component design in any kind of development.

BPS_Wfof wrote:

Hi all,

how you manage the differents library version numbers in different environment (development, test, production)?

Now we mantain a wiki page on which we manually log, for every library, the differents versions on all environments.

For Example:

Library1 Dev version: 54 correspond to Test version: 12 correspond to Production Version: 12

We update this wiki page whenever we deploy another version of the library in test and production env.

Also we use NOTES field to save informations about the related version in other env.

I don't like this approach because is completely manua, but this is the only that i've found.

Is there an official approach or any best practices to follow?

How you are doing this job?

thanks

Max

BPS_Pid

For some libraries we could use latest version every time,

but in other cases (eg. libraries of c# scripts), we want to manage different situations:

- in a c# class (included in a library) I remove some methods that are marked as deprecated in previous versions, so the project must include this (latest) version of the library only when they have purged the deprecated calls.

- in a c# class i wrote new public methods that give new funcionalities to the users (users=project that need to use library), so it is not necessary to redeploy all projects (spending many time) only to update the library version (to the latest one), but only the projects that want to use these new methods.

In both two cases we don't want to keep all projects always updated to the latest version.

In Designer I could specify what version of library reference in my project, so I expect this need was thought from Metastorm when they create BPM.

In product documentation there isn't any paragraph dedicated to this argument.

Maybe there was a best practice from Opentext for the manage of library in different env :smileywink:

bye, Max

Jerome_Pearce

You raise valid points. I guess we became used to just using the latest version because in versions 6 & 7 you had no real choice. You could keep using the 'current' version, or update to the latest. You could not specify an exact version. Trying to 'keep' the current version never worked when publishing to different databases anyway, so the latest was always chosen in our practice.

As far as deprecated functions go, we tend to leave them in for a while, until we are confident that removing them is OK. You are right in that you can at least revert to a different version in MBPM 9, which is good.

Paul Lawrence

IMO library management in v9 is a mess.

The library 'version' gets carried with the solution project file regadless of the environment and as I think we all know the version number is not really a version number at all but rather the sequence number of the library deployment into any given environment. So there is no consistency of version number to code across environments.

Another complication is that of the library cache. In my experience even if you are connected to the respository you wish to work against and select to use a particular version in your project (add this version to your project), if that version exists in your library cahce it will be loaded from local cache rather than from the respository. This then adds version control of your local library cache into the mix. For this reason it is wise to clear the cache periodically and for me essential whenever deploying to production environments.

What we could really do with is real versioning for libraries so that no matter what environment we're using the version of the library code is known rather than the sequence number which only serves to confuse which version is actually being used. I don't think that this should be too hard for OT to achieve.

It would also be helpful if there was an option in Designer to clear the library cahce rather than having to delete files through the OS.

I like the idea of always being able to use the latest version but this isn't always an option as it assumes resources are available for regression testing. Reverting to a previous version relies on being able to identify the corresponding versions across environments, with good CM that is always an option but in reality I can't see this being a practical option for the majority of BPM customers.