User-created integrations in DevOps Change Velocity
Summarize
Summary of User-created Integrations in DevOps Change Velocity
User-created integrations in DevOps Change Velocity enable you to connect additional planning, coding, and testing tools not included by default in the application. This flexibility allows you to enhance your DevOps environment by integrating custom tools according to your organization's needs.
Show less
Key Features
- Integration Objects: Key actions include Connect, Discover, Import, Lookup, and Notification, each serving specific purposes in managing data flows between ServiceNow and the integrated tools.
- Integration Configuration: Configuration involves both integration developers and DevOps admins, who set up tool integration records, subflows, and capability mappings.
- Inbound Events: These records allow for reprocessing of failed payloads and are instrumental in error handling and notifications.
- Mapping Capabilities: Tools can be mapped to multiple capabilities and actions, facilitating comprehensive integration with various tools like Azure DevOps, GitHub, Jenkins, etc.
Key Outcomes
By utilizing user-created integrations, you can expect improved connectivity and functionality within your DevOps environment, resulting in better data management and operational efficiency. Enhanced integration capabilities allow for tailored workflows that align with your organization’s specific processes, leading to more informed decision-making and streamlined operations.
User-created integrations are for integrating additional planning, coding, and test tools that are not available by default in the DevOps Change Velocity application.
The DevOps Change Velocity application includes tool definitions for integrating some common planning, coding, and DevOps test tool integration, but you can also set up user-created integrations for additional tools in your DevOps environment.
Integration objects
DevOps tool integration consists of these objects.
Tool capability actions
- Connect action:
When connecting, the subflow for the specific tool is called and the connection state is updated. The connection status message is shown on the form.
See Connect capability subflow for more details.
- Discover action:
When discovering, an import request record is created and the subflow for the specific tool is called (as defined in the Integration Capability record). Detail and Status fields in the Import Request record are updated with the number of items discovered, updated, and failed.
The transformed payload consists of an array of objects as a JSON string. Elements vary depending on the tool type.
See Discover capability subflow for more details.
- Import action:
Import action does not support historical import functionality.
- Lookup action:
The Lookup main flow is provided to support artifact tool type in a subflow created by your integration developer.
- Notification (webhook) action:
The source tool is configured manually (by your integration developer) to send raw data to the ServiceNow instance. The raw payload is then transformed into a standard JSON object using a subflow.
See the Notification capability subflow and the DevOps - POST /devops/tool/{capability} endpoint of the DevOps API for more details.
Note:If a subflow is not specified, default handling of notifications occurs (original payload is automatically copied to transformed payload).This behavior is useful when the transactional data of the tool is supported by ServiceNow DevOps as is.
See the expected standard payloads in the Notification capability subflow for more details.
DevOps integration configuration overview
Tool integration configuration can be completed by your integration developer and your DevOps admin.
- Integration developer
- Create a tool integration record in DevOps to define the tool you are integrating (source tool).
- Create a Workflow Studio subflow to collect and transform data from the tool you are integrating (source tool).
- Create a tool capability mapping record in DevOps to map the tool
integration record to the tool type capability.Note:Notifications (webhook) capability is supported. Connect and discover capabilities are also supported.
- Create an integration capability record in DevOps to specify the action for the tool type capability.
- DevOps admin
- Create a (planning, coding, or test) tool record in DevOps to
connect to the tool you are integrating (source tool).Note:The tool integration record must be specified in the Tool field of the tool record.
- Configure the source tool with the webhook and credentials.
- Create a (planning, coding, or test) tool record in DevOps to
connect to the tool you are integrating (source tool).
Inbound events
An inbound event serves as a staging area for the notifications flow that supports reprocessing of failed payloads. Meaning, a record in an error state from a failed integration or transformation can be retried.
If an Inbound Event record is in the Error state, the flow was not able to insert the record successfully into the core DevOps tables.
Common errors can be resolved with these actions.
| Error | Action |
|---|---|
| Missing required fields | The transformed payload does not match the standard payload. Refer to the standard and JSON payloads provided. |
| Repository not marked for tracking | The commit cannot be inserted. The DevOps admin needs to track the repository. |
| [Subflow] has not been published within application scope [app_scope] | The subflow is created but not published yet. |
| Timeout exception | The subflow takes more time than the value set in the property: com.glide.hub.flow_api.default_execution_time See FlowAPI - executeSubflowQuick(String name, Map inputs, Number timeout) for more details. Note: The execution of the subflow exceeds the value set in the
Timeout field in the Integration Capability
record. |
| Did not find a matching subflow for notification capability and [tool_integration_sys_id] tool integration | The flow was not able to find the matching subflow. Verify the integration setup procedure. |
| Payload does not match the expected capability. | The Original payload (payload being sent) is a different Capability type than the tool type capability configured in your tool capability mapping. The payload type must match the tool type capability configured in your tool integration. |
- Source tool has not passed the tool ID as a query parameter.
- Source tool has passed on a tool ID, but there is no matching tool ID in the instance.
Tool mappings
A tool can be mapped to multiple capabilities.
| Tool Integration | Tool Type Capability | Tool Capability Mapping | |
|---|---|---|---|
|
|
Plan
Code
Orchestration
Test
|
|
A tool capability mapping can be mapped to multiple actions.
| Tool Capability Mapping | Tool Action | Integration Capability | |
|---|---|---|---|
|
|
Agile Development 2.0
Azure DevOps
Bitbucket
GitHub
GitHub Enterprise
GitLab
Jenkins
Jira
Rally
|
|
Multiple test types can be mapped to each tool integration.
| Test Type | Tool Integration | Test Type Mapping |
|---|---|---|
Unit: JUnit, XUnit, NUnit, Unit test Functional:
Performance: Load |
|
Azure DevOps
Jenkins
GitLab
GitHub and GitHub Enterprise
|