ALM Octane Integration with Azure DevOps Services

0.2.5.4 version Release notes

• Added support for Gherkin injection
• Various other improvements, including bug fixes and logs

0.2.3.1 version Release notes

• Fixed 401 error in tasks not showing as failed
• Homogenized public and private extensions. Currently, besides Azure DevOps required manifests and versions there will not be any difference between the private and the public extension.
• Other non functional improvements

General information

• An Azure DevOps Services account normally implies an organization level.
• Every account (organization) may have one or more projects.
• Every project may have one or more pipelines.
• Every pipeline consists of one or more jobs that may run in parallel.
• Every job is a sequence of one or more tasks.
• Every task is an activity executed during the run of the job containing it. A task can be written in a variety of programming/scripting languages and can be a part of either the Azure DevOps Services framework or an extension.
• The only unit of an executable code that an extension can contribute to the Azure DevOps Services framework is a task that is normally executed during a pipeline run. The task can be integrated into existing jobs or can be added to the pipeline under a separate job.

The integration

• The current implementation supports only one direction – an Azure DevOps pipeline and its jobs can notify ALM Octane about their progress and statuses, as well as send information about the source control commits and test results relevant to them. However running and stopping the pipeline from ALM Octane, is not supported.
• The integration was implemented by developing an Azure DevOps Services extension with the following contributions:
  1. A new service connection type (ALM Octane Service Connection). By creating an a service connection of this type the user provides the properties of an ALM Octane Workspace (Connection name, URL, instance ID, shared space ID, workspace ID, API client ID and secret). This instance is then used by Azure DevOps pipelines for notifying the workspace with the events and data specified above.
  2. Two new task types (“ALM Octane Job Start” and “ALM Octane Job End”), instances of which must be added to every job in the pipeline at the appropriate locations – the start and the end points of every job by the client itself, either through YAML or Legacy drag&drop process

The workflow for establishing a successful integration between an ALM Octane workspace and an Azure DevOps Services project

1. In the Azure DevOps organization you must install the private ALM Octane Integration Extension. (For the Alpha and Beta versions a special request must be sent to ALM Octane Dev for sharing the extension with the target organization. For the GA release, the extension will be published to the Microsoft Azure DevOps Marketplace).
2. In the ALM Octane shared space: Create an API client ID and secret with the “CI/CD Integration” role over the target ALM Octane workspace.
3. In the target Azure DevOps project:
   1. Create a new ALM Octane Service Connection by providing all the required settings. Let’s assume the connection name is OctaneCon.
   2. Let’s assume your pipeline consists of the following jobs: A, B, and you created the pipeline through the YAML editor (The same steps should apply with classic editor, just without manual editing). You must add 2 extra jobs to the pipeline: one to the pipeline beginning and the other to the pipeline end. These jobs must have the following names: AlmOctanePipelineStart and AlmOctanePipelineEnd. They must be set to always run (independently of the status of any other jobs). Moreover, the AlmOctanePipelineEnd must wait until all the other jobs will finish, even if the other jobs run in parallel. The best way to ensure this is by setting it as dependent on the other jobs. Thus the final version of our AlmOctanePipelineEnd job will be:

      - job: AlmOctanePipelineEnd
        condition: always()
        dependsOn:
        - AlmOctanePipelineStart
        - A
        - B      
      

      On the other hand, we want to let the AlmOctanePipelineStart to always run first.
      Therefore we need to force the other jobs to depend on it:

      - job: A
        dependsOn:
        - AlmOctanePipelineStart
      

      The final version of our pipeline should be similar to the figure below. After it runs, the appropriate “CI server” and “Pipeline” entries will be created in ALM Octane (if they don’t already exist), and the pipeline UI will reflect all the regular properties related to the pipeline run: its progress, topology, status, related source control commits, and test results.

      jobs:
      - job: AlmOctanePipelineStart
        condition: always()
        steps:
        - task: octane-start-task@1
          inputs:
            OctaneServiceConnection: 'OctaneCon'
            WorkspaceList: 'YOUR_COMMA_SEPARATED_WORKSPACE_IDS'
      
      - job: A
        dependsOn: AlmOctanePipelineStart
        steps:
        - bash: echo "A"
      
      - job: B
        dependsOn: AlmOctanePipelineStart
        pool:
          vmImage: 'ubuntu-latest'
        steps:
        - task: Maven@3
          inputs:
            mavenPomFile: 'pom.xml'
            mavenOptions: '-Xmx3072m'
            javaHomeOption: 'JDKVersion'
            jdkVersionOption: '1.8'
            jdkArchitectureOption: 'x64'
            publishJUnitResults: true
            testResultsFiles: '**/surefire-reports/TEST-*.xml'
            goals: 'package'
      
      - job: AlmOctanePipelineEnd
        condition: always()
        dependsOn:
        - AlmOctanePipelineStart
        - A
        - B
        steps:
        - task: octane-end-task@1
          inputs:
            OctaneServiceConnection: 'OctaneCon'
            WorkspaceList: 'YOUR_COMMA_SEPARATED_WORKSPACE_IDS'