Version 1

    5.3.1 Background

    It’s possible that a user of the Overlord:DTG application may simply want to govern their application deployments while using alternative tools to manage Business Problem definitions and Solution architectures.  In this case, users can skip the higher level capabilities and go straight to deployment lifecycle related tasks.

    5.3.2 Participants

     

    • Debbie [Developer]
    • Tim [Tester]

    5.3.3 System Narrative

    Debbie uses external development tools to create an application (e.g. a JAX-WS web application or a Switchyard application).  The application is packaged in an application-specific format (e.g. WAR, EAR, JAR, etc...).

     

    Debbie adds the application-specific package to Overlord:DTG as a new Deployment Unit.  She does this either manually through the UI or via integration with a build system such as Maven.

     

    Adding the Deployment Unit to Overlord:DTG will fire an event that will trigger the creation of a workflow to manage the Deployment Unit’s lifecycle.

     

    Debbie logs into the system and navigates to the Deployment Unit Management page.  She is able to list all Deployment Units she has permission to view, along with the current status of each (in-development, in-test, in-production, retired).  This page allows Debbie to filter the list to quickly find the Deployment Unit she is interested in.

     

    Debbie clicks on the View Deployment Unit Details link and is taken to the Deployment Unit Details page.  This page shows details about the Deployment Unit, including but not limited to:

     

    • All meta-data such as name, description, version, etc
    • The Deployment Unit’s current deployment status
    • A list of all automatically discovered artifacts found in the Deployment Unit (e.g. WSDL ServiceComponents, BPMN2/BPEL CompositionComponents, XSD InformationTypes, etc...)
    • The Deployment Unit’s version history
    • All user activity related to the Deployment Unit

     

    Debbie is presented with the following list of actions (depending on permissions):

     

    • Update meta-data (name, description, etc...)
    • Delete
    • Download
    • Add Documentation

     

     

    As documented in Section 4.1.4, Debbie and Tim progress the Deployment Unit through its full lifecycle, resulting in a release to production.