Deploy to different environments in BPM v9.x

Zhao_Xiao-ou
Zhao_Xiao-ou
in AppWorks #1

Hi folks,

 

There are normally 2 or 3 environments in BPM environment set up: Dev, QA and Production boxes. Does anyone know how to manage deployment to different environments without need of changing connections (say a solution has 3 or 4 connections, connection strings would be different (database server name, database name, userid/password), or there are configurable settings somewhere in the designer that can be saved, and when designer loads the solution, it automatically populate correct connections based on its environment.

 

Thanks

Tagged:

Comments

  • Jerome_Pearce
    Jerome_Pearce
    #2

    There is no simple way. I have documented several problems with maintaining links to serveral repositories from one instance of the Designer.

     

    We have made a simple rule that every instance of the Designer should only ever deploy to one repository. If there is a simple way to avoid the problems we have both encountered and predict will occur, I would love to hear them, but so far nobody has been able to tell us.

     

    /awd/forums/questions/3408662#r3408671

     

    Regarding the connections themselves, however, we try to keep these in libraries and deploy different libraries in different environments. You can also update the connection details manually in the repository, but that is, to us, a potential cause for undocumented changes and confusion.

  • Aaron Van
    Aaron Van
    #3

    The Repository drop down in the IDE only serves to mock it's users.

     

    We have a 4 environment setup and this lack of configuration for builds is difficult to say the least.

    Jerome, are you saying you open 4 instances (in my case) running on some VM just as your deployment box?

     

    The ' web.config ' found in the connections advanced tab is in the xml encoded, aptly named connections.connection file.

    I'm going under a wild assumption that when deployed this is stored in some db table since that's how metastorm stores all other objects.

     

    I suppose there is potential to create as many connections.connection files as you have environments and swap those out for your builds. This all hinges on each one of your projects having multiple connection files. This is where Jerome's suggestion of placing all your common connections in a library really helps.

     

    We currently run a blended system with Metastorm as the workflow, mvc/razor as the frontend, and a few other tiers sprinkled in. Whenever we need to deploy to a specific environment we do the following:

     

    1. Deploy our code for all tiers but workflow using transform scripts to modify the *.config files.
    2. Open Metastorm library project.
    3. Modify/Update connections for web services.
    4. Change repository to point to correct environment.
    5. Deploy.
    6. Open Metastorm workflow project.
    7. Change repository to point to correct environment.
    8. Update library in project.
    9. Deploy.
    10.  Cry.

    If there is an actual enterprise solution to this I would love to hear it.

  • Jerome_Pearce
    Jerome_Pearce
    #4

    Aaron V wrote:

    The Repository drop down in the IDE only serves to mock it's users.

    Hah! I like that one.

     

    As far as a full solution to the problem goes, we always deploy to different environments from the engine server itself. This ensures that the designer version is the same as the engine version, and that the connection details are correct, and the correct libraries are being employed.

     

    It is a bit of a pain, but we very rarely need to deploy to UAT & Production. In many of our customers' environments we never actually access these environments and just provide instructions in any case.;

     

    As for the different environments we have to develop in, and there are many, particularly with different versions of the product, we just set up different VMs for each. Generally each of our developers sets up or copies the VM for a particular project, and we manage all code through central cloud-based source control,

Categories

image
OpenText CE Products
AppWorks
Gateway & Platform