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

Tagged:

Comments

  • 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.

     

     

  • 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