Automation Scenarios

This document provides high-level scenario descriptions and links to elaborated scenarios that have been identified by the working group as possible scenarios to be used in driving V1 Automation (Build/Deploy) scenarios

Core scenarios

CLM and Linked Data

This set of scenarios revolves around basic lifecycle traceability between Collaborative Lifecycle Management tools as well as the general concept of Linked Data to integrate OSLC Automation providers with other Linked Data tools. In general, these scenarios are present to ensure that appropriate Resource Definitions are present for linking across tools as well as that appropriate relationship properties exist within these Resource Definitions to properly describe the relationship.

The following scenarios were generated during an earlier iteration of the OSLC Automation Workgroup and largely define various CLM scenarios

• AutomationScenariosMylyn
• AutomationScenariosIBM

Manual automation execution

This set of scenarios is centered around a user sitting in front of an OSLC Automation-enabled tool. The user wishes to select an appropriate Automation Resource Definition and "execute" it. Subsequently, they will want to be able to monitor and view and results of this "execution".

• AutomationExecutionScenario
• AutomatedTestExecutionScenario (an application of the above scenario in the Test or Quality Management domain)

For discussion: The lifecycle of an execution of an Automation. The scenario title and initial description is somewhat misleading. It is helpful to think of the execution in terms of a user sitting at a tool, but consideration also must be given to OSLC RESTful client GETing Automation Plans, POSTing/GETing Automation Requests and both automation workers and clients POSTing/GETing Automation Results.

Where is execution status recorded? What are the linkages between Plans, Requests and Results? What is the scenario for both providers and consumers of Results to read and write them?

Product Build automation execution

This section contains scenarios related to automated builds performing construction of product artifacts from source code and also execution of code scans and tests.

• AutomatedBuildScenario

Defining workflows across OSLC Automation providers

This set of scenarios is centered around a user sitting in front of a "workflow definition tool" that supports OSLC Automation providers. The user is composing a workflow consisting of one or more "calls" to one or more Automation Plans provided by one or more OSLC Automation providers. This workflow is intended for execution at a later point and time (contrasted with the manual automation execution scenario(s) above).

• Scenarios TBD

Partial scenarios

These scenarios are unlikely to stand on their own. They are likely to be included as parts of other scenarios, but they are called out here explicitly so that they get individual focus, as they are likely to have specific challenges that need to be worked independently of the larger scenarios in which they are included.

Updating results and creation of contributions

This set of scenarios centers around the ability to update an Automation Result, as well as the ability to create and update Automation Result Contributions.

• Scenarios TBD

Notifications

This set of scenarios centers around the ability to receive event-based triggers based on changes to (probably a subset of) OSLC Automation Resource Definitions. This is in direct contrast to the normal model of polling to determine changes.

• Scenarios TBD

Automation Provider/Automation Tool (Worker) Interaction

This set of scenarios centers around the interactions of the automation execution tools (or worker systems) that are typically/frequently used to perform the work on behalf of the OSLC Service Provider and the actual OSLC Server Provider itself.

This outlines the high level scenario of the interaction between Automation server and Automation Tool.
The term "automation tool" can also be thought of as agent or worker.

1. Automation Tool registers with Automation Server with the type of Automation Tool. Automation Server responds back with a URL to look for further work

2. Automation Server User (manual or scheduling facility) initiates Execution of a Automation plan.
(Either user can choose one of the registered tool for execution or Automation Server can decides itselt to dynamically
allocate Execution to one of the Registered Automation tool.)

3. An Automation Task is created to track this request.

4. Automation Tool polls periodically to Automation Server on provided URL for any work assigned

5. Automation Tool, upon finding an Automation Task, follows the link to get more information about the request

6. Automation Tool picks up the work and updates the Automation Server about the work it has taken

7. Automation tool continues to work and keeps on updating Automation Server with progress and any other status messages.

8. Optionally an user can Cancel the Automation task. Automation tool upon receiving such instruction cancel further execution and update Automation Task

9. Automation Tool upon completion of the work, Creates Automation Result back to Automation Server.

10. Automation tool updates Automation task to link with the result created and and mark Automation task as complete with 100% progress.

11. Automation tool repeats from step #4