This page is dedicate to gather some interest around developing a set of Integration Patterns.
Table of Contents
Contents
Goals
A way to provide an approachable way to understand what technologies are recommended by the OSLC community for various integration scenarios. These patterns can also be thought of as a way to present and share various best practices.
Definition
Patterns could cover both high-level and lower-level patterns. They identify the problem that they are addressing and scenarios where it has emerged, though not limited to. There may be multiple patterns that for various scenarios, it will be up to the end user to decide which pattern applies to their specific situation.
Usage
The intended usage if for anyone to be able to use these scenarios as a starting point to customize for their specific situation and needs. It would be ideal to link to original pattern when this is done and it indicate which patterns are used.
Pattern Catalog
The following is only a sampling/proposal on what these patterns might be (level of detail, scope, high priority)
Heterogeneous Change Management
Status: Proposed
Recommendation: TBD
Problem: More than one change management (CM) solution is often needed to track an original enterprise change request, which needs to flow to other CM tools.
Pattern: Leave the CR in the “parent” CM tool, link to a subordinate resource in another tool a work item to fulfill the request. Information about the state is fetched. State transition between the tools is the responsibility of the linked-from tool to ask the linked-to tool about changes, including state, and then take action based on that.
Scenarios:
- Enterprise change request broken down into stories+tasks in agile tool used by software development teams.
Specifications: OSLC-CM 2.0, OSLC-CM 3.0
Type: ALM, PLM
Contributors: Steve Speicher, Rainer Ersch
Continuous Delivery Pipeline
Status: Proposed
Recommendation: TBD
Problem: An automation tool will need to orchestrate automation requests(tasks) across a variety of tools such as source code extraction, compilation, packaging, deployment to test, automated testing, staging for production. There is limited traceability and consistency of interfaces between all the pipeline contributors and therefore making it costly or near impossible to determine what the input and outputs of the different automation phases are and how they relate to the overall lifecycle.
Pattern: Utilize a single pipeline server and specific tool to orchestrate the automation tasks. Utilize a consistent interface for configuring which tasks to run and with what parameters, how to execute them and how to gather the results.
Scenarios:
Specifications: OSLC-Automation 2.1/2.0, OSLC-Automation 3.0
Type: ALM, PLM, DevOps
Contributors: Steve Speicher, Martin Pain
Contributing
Add your name if you’re interested in participating or contact Steve Speicher directly
