Unattended deployments with library refresh / upgrade

Hi All

Just been looking at how you can create a batch file and schedule it to run an unattended deployment of a solution but not seen anything on how you can get the library versions used in the solution to be refreshed / use the latest version of the library?

Is that possible with an unattended deployment? / May be it happens automatically with an unattended deployment?

Thanks

Jas

Find more posts tagged with

BPM

Comments

Jacob_Eastman

Hello Jas,

This is an available option in 9.2. From Section 3.2.3 "Command Line Deployment" of the Administration Guide BPM v9.2:

/forcelibmatch
When the required version of a library cannot be found and a later version exists in the targeted repository
or local library cache, try to pair the project with that version of the library instead.
Use this switch where solutions are deployed to different controlled environments beyond the one used
during the development cycle.
Library versions encoded in projects often reflect the current version of the library in the development
environment. When solutions transition from development to integration, live or other controlled
environments, the incremented version number of the same deployed library in the new environment is
likely to be different to the one encoded in the project. Attempting an initial command line deployment of
the project without first opening it in the Designer and actively pairing it with the equivalent library in the
new environment can lead to failure. This is because the library is not verified as being compatible with the
project.
The /forcelibmatch parameter provides a facility to override this behavior and negate the initial
manual verification and pairing step. Use this parameter in cases where you have a good understanding of
the content of the target environments, as deployments that are carried out in tightly controlled
circumstances or setup of a solution always take place against a new and empty repository.
Use of this parameter causes the encoded project reference to be ignored at deployment time. If an exact
library version match is not available, an attempt is made to pair the project with the latest version of the
library that is found. This does not cause the update of the library version recorded in the project.
Permanent update of the encoded library version still requires opening the project in the Designer, and
determining the correct library to pair with the project.
Note: Use of this parameter overrides checks that ensure deployment of projects with the library against
which they were developed. If you are unsure as to whether the later libraries in the target repository are
compatible with the project, we recommend that you use the Designer to verify compatibility and
deliberately synchronize the project with the correct library version for the new environment.
Deployment failure may still occur if the library that is automatically matched is not truly compatible and is
missing any of the contents referenced by the project. It may also result in a successful deployment but
unexpected runtime behavior if the project is paired with a library having the required referenced objects
but containing an earlier or later version of runtime logic. To avoid both of these potential side effects we
recommend that deployments related to the transitioning of solutions between environments always
redeploy libraries as part of the same scripted operation. This ensures deployment of the libraries before the
projects that reference them, resulting in projects being paired with the correct library even when ignoring
the specific version encoded in the project. See 3.2.4 Deploying Content with Dependencies for further
information.

Aaron Van

I think the first line is a real key in the documentation:

When the required version of a library cannot be found and a later version exists in the targeted repository
or local library cache, try to pair the project with that version of the library instead.

If I updated a library and deployed making it version 2 let's say.

Simply deploying projects with the /forcelibmatch flag does not necessarily update your project with the latest library. Upon re-deploy it will continue to use the old library because the version it was previously using still exists in the repository.

My library has a server side script that encapsulates nearly all logic for service calls and business logic. If I were to make a modification to the logging methods for example, I would then have to go to each project in the Designer and update the library before running the command line deployment.

Already the documentation makes a note warning users about mismatch:

Note: Use of this parameter overrides checks that ensure deployment of projects with the library against
which they were developed. If you are unsure as to whether the later libraries in the target repository are
compatible with the project, we recommend that you use the Designer to verify compatibility and
deliberately synchronize the project with the correct library version for the new environment.

If the developer's trust their users to use /forcelibmatch, it would be nice if there was also a flag such as /forcelibcurrent or something along those lines.

Thoughts?

p.s. This topic doesn't include the issues that arise when your library contains a web service which would have to change across envrionments. That may need a post of it's own.

...aaron