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
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”.
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.
Deployment and DevOps scenarios
Defining workflows across OSLC Automation providers (out of scope for V1 of specification)
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).
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.
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.
Synchronous Execution
This set of scenarios centers around the ability to process certain requests with fewer HTTP round trips required. While a basic Automation assumption is that Plans, Requests, and Result contributions can each originate from and be updated by a set of distributed components, there is a desire by some to not exclude simpler implementations that can further optimize the number of HTTP requests used to make a request and obtain the final results.
