none
deploy workflow concepts RRS feed

  • Question

  • I'm missing a concept regarding deploying workflows. How is the workflow AND supporting assets such as the stages packaged and deployed? I understand how to build and package the workflow into a wsp, but the walkthroughs on the sdk don't mention deploying the other assets, such as the phases, stages, and PDPs. So, if there are three dev servers, as well as test, qa, and production servers, how should the workflow assets be built and deployed to the different environments?

    Thanks,

    Mike 


    Mike G.
    Wednesday, December 29, 2010 1:05 PM

All replies

  • Hi Mike,

    You can deploy the PDPs, Workflow Stages, Phases and EPT's across environments using the Microsoft Project Playbooks 2010 tool. The tool reads the configuration settings as well as serialising the PDP's and other configuration settings into an XML file that can then be reimported into another environment. 

    You can read more on playbooks at http://technet.microsoft.com/en-us/library/gg128952.aspx and download the executable from http://www.microsoft.com/downloads/details.aspx?FamilyId=ad0aadbe-cf2a-4e58-972e-e6334429dd0f&displaylang=en

    Hope this helps,

     

     


    Alex Burton
    www.epmsource.com | Twitter
    Project Server TechCenter | Project Developer Center | Project Server Help | Project Product Page
    Monday, January 3, 2011 5:42 AM
    Moderator
  • Playbooks certainly allows you to copy  PDPs, etc., from one server to another, but is it scriptable? Or, when moving files from test to qa does one just have to hope the right checkboxes are selected? Also, I don't think it allows you to move only specified PDPs? Is that correct? So if the dev team is working on three different workflows, and wants to deploy just the assets for one?

    There is a utility in the project server starter kit (http://code.msdn.microsoft.com/P2010SolutionStarter/) to do this, but that means deploying an app just to handle the deployment of assets. And, many customers are loathe to install additional apps on their servers...

    Thanks,

     


    Mike G.
    Monday, January 3, 2011 1:23 PM
  • Hi Mike,

    You are correct, Playbooks isn't scriptable and is really all about that initial move of all settings from one environment to another, with of course the proviso that you have pre-installed project templates, workspace templates etc.

    I hadn't dug that deep into the solution starter for DM Import / Export. From trying it out tonight, you only need to install an exe on the dev server, which will allows you to export the various DM files, which are selectable, so you can choose a specific EPT, Phase and Stages and pull over the relevant PDP, custom fields etc.

    The tool allow you to save out your selections and reimport them to repeat the setting export. The import process doesn't rely on an executable, instead relying on a feature being scripted out. What you will need to do is install one DLL in the GAC of the server the settings are being restored to. When you activate the feature it will invoke the DLL via a feature receiver and import the exported values automatically. The full source for the script is available in the source package downloadable at the code.msdn.microsoft.com/P2010SolutionStarter site, and could be customised pretty easily if you needed to adapt the scripting for your deployment build processes.

     


    Alex Burton
    www.epmsource.com | Twitter
    Project Server TechCenter | Project Developer Center | Project Server Help | Project Product Page
    Tuesday, January 4, 2011 11:26 AM
    Moderator
  • Thanks,

    In my experience, putting anything in the GAC lengthens a project dramatically, as there would then be a required code review process. So, without that, what should the process look like?

    Perhaps:

    1. Set up all phases, stages, fields, etc., on the production server.

    2. Export the above using playbooks

    3. Set up each developer workstation / test server with a different instance of Project Server for each customer they will be working with.

    4. Import the settings using playbooks into the appropriate instance of Project Server

    5. Build workflow (and/or other deliverables)

    6. Deploy to test / qa / production.

    This means that the workflow assets would be controlled by a different group and would be versioned separately from the workflow itself.

    Am I overlooking something here?

    Thanks,

     


    Mike G.
    Tuesday, January 4, 2011 1:39 PM