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 V2 Automation scenarios.
Each scenario contains a note as to whether it is enabled by the final V2 specification or if it was deferred.
ALM and Linked Data
- These scenarios are enabled by the final V2 specification
This set of scenarios revolves around basic lifecycle traceability between Application 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 ALM 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”.
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.
- Automated build scenario - Partially enabled by the V2 specification. Notification and multiple automation orchestration is deferred.
Deployment and DevOps scenarios
Defining workflows across OSLC Automation providers
- Deferred from the final V2 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).
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.
- Deferred from the V2 specification
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.
- This scenario is enabled by the final V2 specification.
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.