Skip to main content
System StatusContact Support
Digital.ai Agility Community

Export test

Overview

Digital.ai Agility Integrations
Learn how to integrate Digital.ai Agility Connect with the systems and tools in your software delivery environment to coordinate across your mixed development environments in a single web-based interface.
Digital.ai Agility Connect is an enterprise integration solution for integrating Digital.ai Agility with other ALM tools such as JIRA and TeamForge. Agility Connect extends the capabilities of the Continuum Plugins and Webhooks to create an integration that lets you have the default fields of specific assets synchronized between the integrated tools. Agility Connect supports a project-level asset mapping for such synchronization to happen.

For more information, see Agility Connect Documentation

Extend VersionOne and create a single, synchronized agile software development environment with more than 70 pre-built integrations to best-of breed software development tools. Integrations are available for all VersionOne product editions, or you can build your own using VersionOne's open, web-service API and SDKs (Java & .NET). To see the complete list, visit the VersionOne Application Directory.

 

This feature is available in all editions.

editions-all.png

For Bugzilla Versions Below 5.0 Click Here

The VersionOne Integration for Bugzilla creates defects in VersionOne based on bugs found in Bugzilla. Using this integration, your organization can manage and triage bugs reported by customers and promote them to VersionOne once you determine a fix is necessary.

Once the integration is installed and configured, Bugzilla users can specify which bugs require engineering attention and they will automatically appear as defects in the VersionOne repository. Additionally, when the defect is closed in VersionOne, the integration updates bugs in Bugzilla to reflect this change.

This integration supports multiple modes of operation:

  • Assign a Bug: With this approach, bugs that require attention are assigned to a specific user in Bugzilla. This assignment is used to determine when to create defects in VersionOne.

  • Tag a Bug: With this approach bugs that require attention are identified using custom fields on the bugs. The value of the custom field is used to indicate when to create defects in VersionOne.

The following sequence diagram illustrates how the integration interacts with Bugzilla and VersionOne:

System Requirements

Operating System:

  • The ServiceHost executable can be ran on any Windows operating system that supports .NET Framework 4.5.1.

Framework:

VersionOne:

  • 7.3 and higher, all editions.

Bugzilla:

  • Versions 5.0 and above, Linux recommended. Previous versions of Bugzilla may continue to work, but are no longer supported by VersionOne.

Bugzilla must be running in the Apache Web Server. Bugzilla running in IIS is not supported.

Your Bugzilla instance must support RPC connections. This may require some optional modules including, but not limited to, SOAP-Lite, Test-Taint, and JSON-RPC. If these modules have dependencies, you will need to install those too. Refer to the Bugzilla documentation for your release for exact details and instructions on how to install these modules.

Download

The latest version of the integration is available in the VersionOne Application Catalog.

Upgrade

If you already have Bugzilla running in your environment, you will need to backup the existing integration before installing this current version. 

Installation

These installation instructions assume that Bugzilla is already installed, configured, and working properly.

  1. Determine Installation Location.

    The integration can be installed on any server with network access to both VersionOne and Bugzilla. Exact placement should be determined by your internal software management requirements. The integration server must meet the system requirements stated above.

  2. Extract the files.

    Download the integration using the link above and extract it into a folder of your choice.

  3. Configure the integration.

    Configuration for the integration is a 3 step process:

    1. Configure Bugzilla

    2. Configure VersionOne

    3. Configure ServiceHost

  4. Start the integration.

    Open up the command prompt, navigate to your installation folder, and run the following command:

    VersionOne.ServiceHost.exe
    If you have configured your system properly, you should see several [Info] messages followed by a [Startup] message.

  5. Test the integration.

    To ensure the integration is working, perform the following steps:

    1. Create a bug in Bugzilla.

    2. Set the appropriate state in order for the bug to move to VersionOne.

      • Assigned methodology -  bugs should be assigned to the user(s) specified in the Bugzilla Saved Search.

      • Tagged methodology - the VersionOne Defect State should be set to value specified in the Bugzilla Saved Search.

    3. Submit the bug in Bugzilla.

    4. Verify that the bug appears in VersionOne as a defect.

    5. Close the defect in VersionOne.

    6. Verify that the Bugzilla bug has been updated as expected.

    7. Shut down the service host by pressing "Q" in the console window.

  6. Install the integration as a Windows Service (optional).

    While not required, you may configure the integration to run as a Windows Service using the following command from the console window:

    VersionOne.ServiceHost.exe --install
    This command installs the integration service so it will will run under the account NT AUTHORITY\Local Service. Local Service must be given access privileges to the directory where the integration was installed so it can store its state and write to log files.

    Follow these steps to change the security on the installation directory:

    1. Right click the installation folder from Windows Explorer.

    2. Select Properties.

    3. Select the Security tab.

    4. Click the Add button.

    5. Enter Local Service and click OK.

    6. Click the Allow checkbox for the Full Control row.

    7. Click OK to save the changes.

Configuration

Configure Bugzilla

This section describes how to modify your Bugzilla instance for use with VersionOne. Before you begin you need to know your Bugzilla version number and you need to decide if you want to Assign or Tag the bugs you want visible in VersionOne.

It's beyond the scope of this document to describe how to create filters in Bugzilla , but here are some filter ideas:

It is recommended that you create the filter using the same credentials used by the integration.

  1. Select or Create a Bugzilla User.

    The integration requires a valid Bugzilla User Id and a Password in order to connect. This user must have sufficient rights to accept work and modify bugs.

  2. The next step depends the approach for pushing bugs to VersionOne.
    • Assigned

      If you choose to push bugs by assigning them to the user identified in step 2, proceed to the next step.

    • Tagged

      If you want to push bugs to VersionOne using a Custom Field, you need to do the following:

      1. Create the Custom field. It is recommended that you use a drop-down field and limit the values.
        BZ_AddCustomField.png
      2. Populate the field with the desired values.
        BZ_CustomFieldValues.png
  3. Create a 'Saved Search' to select the bugs you want pushed to VersionOne.
     
    Assigned

    Using this approach, the easiest filter is based on who is assigned to ("Assignee is {user}") and Status (i.e. "CONFIRMED")

    BZ_SavedSearchAssigned.png

    Tagged

    Using this approach, the easiest Filter is based on the value of the Custom Field.

    BZ_SavedSearchTagged.png

  4. Determine how to prevent bugs from being pushed more than once.

    This decision is based on your search and how you want bugs pushed to VersionOne.

    • Assigned. Using this approach, the simplest option is to change the Status. To do this you need to accept the bug.

    • Tagged. Using this approach, the simplest option is to change the value of the Custom Field. To do this you need to know the value you want set in the Custom Field.

  5. Do you want the URL of the VersionOne defect to appear in Bugzilla? If so, you'll need to create a custom field in Bugzilla.

    BZ_CustomURL.png

Configure VersionOne

Skip this step if you are configuring a VersionOne Team Edition instance.

  1. Add "Bugzilla" to the VersionOne Global Source list.

  2. Determine where to store the Bugzilla ID.

    The integration needs a text field in VersionOne to store the Bugzilla identifier; by default this is the Reference field. If you are already using this field, you'll need to create a custom text field and note the name.

Configure the Integration

To configure the Bugzilla integration, run the ServiceHost configuration tool: ServiceHostConfigTool.exe

The following section describes how to configure your Bugzilla integration using the configuration tool.

  1. On the General tab specify your VersionOne connection details.

    The following table describes the fields on this tab:

    Field

    Description

    Server URL

    This is the URL to your VersionOne server.

    Access Token

    VersionOne generated Access Token

    If there's a proxy between this machine and the VersionOne instance, you'll also need to configure the following settings:

    Field

    Description

    Use Proxy For Connection

    Determines if the integration tries to connect through a Proxy.

    Proxy URL

    This is the URL to your Proxy Server.

    Proxy Username

    The username that will get you past this proxy.

    Proxy Password

    The password for the Proxy Username.

    Proxy Domain

    Name of Proxy Domain.

  2. Once the VersionOne parameters are specified, press the Validate button to continue.  You should see a "VersionOne settings are valid" message to the left of the Validate button.

  3. On the Workitems tab, specify the VersionOne field that will hold the Bugzilla ID.

    SvcHostTool_WorkitemsTab.png

    The following table describes the fields on this tab:

    Field

    Description

    Disabled

    Check this box to disable polling VersionOne for bug updates.

    Reference Field Name

    Workitem field used to hold Bugzilla ID; by default this is the Reference field.

  4. On the Bugzilla tab specify your Bugzilla connection details and the bug transfer behavior.

    This tab changes slightly depending on whether you are assigning or tagging bugs.

    Assign

    Tag

    1. Configure the Bugzilla connection (Connection Parameters):

      Field

      Description

      Disabled

      Check this box if you want to disable polling Bugzilla for new bugs.

      Bugzilla URL

      Fully qualified URL to your Bugzilla instance.

      An Example: http://{HostName}/bugzilla/rest

      Username

      Valid Bugzilla user. This user must be able to see and update bugs in the appropriate projects.

      Password

      Password for specified user.

      Ignore Certificate

      Select this option when using SSL on the Bugzilla server with no certificate or a self-signed certificate.

    2. Click the Validate button to ensure your Bugzilla connection parameters are correct.

    3. Configure how bugs are linked between Bugzilla and VersionOne (VersionOne Defect Attributes):

      Field

      Description

      Source

      Select the VersionOne Source to use for Bugzilla.

      VersionOne Team Edition contains a Source value of "External System"

      URL Template

      Template for URL to access specific bug in Bugzilla. #key# is replaced with the Bugzilla Bug ID. This field is used to create links from VersionOne to Bugzilla.

      URL Title

      This field is the link title in VersionOne.

    4. Configure how bugs are identified by VersionOne in Bugzilla.

      Field

      Description

      Search Query

      The query needed to return the desired bugs to be sent to VersionOne.

      Example:

      bug_status=CONFIRMED&email1=user%40company.com&emailassigned_to1=1&emailtype1=equals&query_format=advanced&resolution=---&known_name=Assigned%20Bugs

      Poll Interval

      Determines how frequently the integration polls Bugzilla looking for bugs.

    5. Configure how Bugzilla bugs are updated after defect creation and closure in VersionOne.

      Field

      Description

      Link to VersionOne Field ID

      Custom Field in Bugzilla used to hold VersionOne URL.

      Close Accept

      Check this box if you want the integration to update the bug status in Bugzilla once the VersionOne defect is closed in VersionOne.

      Create Resolve Value

      Value for Bugzilla status value after creating the VersionOne defect. For older versions of Bugzilla, this value was "NEW", for newer versions, the value is "IN_PROGRESS". However, you may set this value to what makes sense for your current workflow.

      See https://www.bugzilla.org/docs/4.0/en/html/lifecycle.html for more details.

      Close Resolve Value

      Value for Bugzilla status value after the VersionOne defect is closed.

    6. Select the appropriate mode of operation (Assign/Tag).

      • Assign
        The following fields are available when you are assigning Bugs to VersionOne:

        Field

        Description

        Create Reassign Value

        Identifier for the Bugzilla user to assign a bug after a defect is created in VersionOne. Should match the Bugzilla Login Name for the user.

        Close Reassign Value

        Identifier for the Bugzilla user to assign a bug after the VersionOne defect is closed. Should match the Bugzilla Login Name for the user.

      • Tag
        The following fields are available when you are tagging bugs you want in VersionOne:

        Field

        Description

        Create Field ID

        Name of the Bugzilla Custom Field to update after a defect is created in VersionOne. Leave this setting empty if not tagging the bug with a custom field.

        Create Field Value

        Value to set in "Create Field ID" after a defect is created in VersionOne. Leave this setting empty if not tagging the bug with a custom field.

        Closed Field ID

        Name of the Bugzilla Custom Field to update after a the VersionOne defect is closed. Leave this setting empty if not tagging the bug with a custom field.

        Closed Field Value

        Value to set in "Closed Field ID" after a the VersionOne defect is closed. Leave this setting empty if not tagging the bug with a custom field.

  5. Map your Projects Values.

    Project Mapping allows you to specify where defects are created in VersionOne. The algorithm for selecting a project is as follows: First, the integration looks for the Bugzilla Product Name in the map. If it exists, the defect is created in the corresponding VersionOne Project. If the Bugzilla Product Name is not found, the integration attempts to find a VersionOne Project with the same name. If found, the integration creates the defect in the VersionOne project with a matching name. If it cannot find a VersionOne project with a name that matches the Bugzilla Product, the integration will create the defect in the root level node of the VersionOne Project tree or in the first Project in the list if there are multiple top level nodes.
    SvcHost_BugzillaPriorityMappings.png

    To add a Project mapping you need to do the following:

    1. Click on the Project and Priority Mapping tab.

    2. In the Project Mapping grid, select a VersionOne Project value from the dropdown.

    3. Supply the corresponding Bugzilla Product name.
      To remove a mapping:

    4. Select the desired row.

    5. Click the Delete current row button.

  6. Map your Priority Values.

    Priority mapping allows you to configure how the VersionOne defect priority value is set based on the Bugzilla priority value. The algorithm for mapping is simple, if the Bugzilla priority value is in the mapping, the VersionOne defect value is set to the mapped value. If the Bugzilla priority value is not found, the VersionOne defect value is not set.
    SvcHost_BugzillaPriorityMappings.png

    To add a priority mapping you need to do the following:

    1. Click on the Project and Priority Mapping tab.

    2. In the Priority Mappings grid, select a VersionOne Priority value from the dropdown.

    3. Supply the corresponding Bugzilla Priority value name.
      To remove a mapping:

    4. Select the desired row.

    5. Click the Delete current row button.

  7. Save your changes and exit the program.

More Information

To learn more, visit the Bugzilla App Catalog page.

Source Code

Source code for this integration can be found in GitHub.

 

This feature is available in all editions.

editions-all.png

The Lifecycle Integration for Jenkins creates a record of builds in Lifecycle, so development teams can associate stories and defects to a particular build. This visibility is useful when identifying problem builds or generating release notes.

Once the plugin has been installed, team members include an identifier, such as “S-01454” or "TK-01234", in the comments of their SCM commit. Every time a build executes the publisher creates a PipelineRun asset in with details of the build. The PipelineRun is visible on the Relationship section on the Story/Defect Details page.

Using this integration you can better answer the following questions:

  • For Defects:

    • Which build the defect was reported against?

    • Which build contained the fix for the defect?

    • Which builds contain work for the defect?

  • For Stories (Backlog Item):

    • Which builds contain work for the story?

    • Which build contained the completed story?

  • For Pipeline Runs:

    • Which defects were fixed?

    • Which stories were completed?

    • Which defects were introduced?

    • When work for a story or defect was included?

    • Which Change-sets were included?

  • For a range of Pipeline Runs:

    • Which stories were completed?

    • Which defects were fixed?

    • Which defects were introduced?

Sequence Diagram

The following sequence diagram illustrates the Lifecycle Integration for Jenkins behavior.

System Requirements

Lifecycle

  • 8.1 or above, including Team Edition

Continuous Integration Server

  • Tested with Jenkins version 1.651.2 & 2.107.2

Supported Source Code Management

  • Subversion - 1.17 or better

  • Perforce - 1.1.5 or better

  • Git - 1.3.1 or better

Installation

These instructions presume that Jenkins is already installed, configured, and working properly.

  1. Ensure Connectivity
    Verify that you can connect to your Lifecycle instance from the machine hosting Jenkins

  2. Extract Files
    Download the plugin from the link below and extract it into a folder of your choice. This can be a temporary location since we will copy some of these files during configuration.

  3. Configure

    • Configure Lifecycle

    • Configure Jenkins

  4. Verify the installation

  5. Once configuration is complete, follow the steps below to verify that the build integration is working

    • Navigate to your Jenkins instance.

    • Force a build on the project you configured.

    • Wait for build to complete, and then log into your Lifecycle instance.

    • Select the Lifecycle project in the Project Navigator.

    • On the main menu, select Reports, and then click on the Build Run Quicklist report.

Configuration

Step 1. Configure Lifecycle

  1. Log into Lifecycle as an administrator.

  2. From the Admin menu, select Configuration, and then click on the System tab.

  3. Select the Enable Build Integration checkbox, and then click the Save button.

  4. To build a new project, go back to the Admin, select Projects, and the select Pipelines.

  5. Click the Add button, and then enter the following:

    • Name. This is how the build project displays to Lifecycle members.

    • Reference. This is how the build project displays in Jenkins.

    • (Optional) Description. Enter a more details about the build project.

  6. Click Save.

  7. Click on the Projects tab.

  8. On the row for the project you want associated with the Pipeline, select Edit from the Add Child Project drop-down menu.

  9. Scroll to the Pipelines field, and then select a Pipeline from the drop-down list.

  10. Click Save to accept the changes, and then log out of Lifecycle.

Step 2. Configure Jenkins

  1. Log into Jenkins as an administrator.

  2. On the Jenkins Dashboard, Click Manage Jenkins.

  3. Click Manage Plugins, and then click Advanced.

  4. Under Upload Plugin, browse to your download location, select the versionone.hpi file, and then click Upload.

  5. Restart your Jenkins instance to load the new plugin.

  6. On the Jenkins Dashboard, Click Manage Jenkins.

  7. Click Configure System. A new Lifecycle section displays at the end of this page.

  8. Provide your Lifecycle connection parameters. Note: if you are connecting to an On-Demand VersionOne instance, make sure to use the https prefix, not just http.

  9. If you connect to Lifecycle through a proxy, select the Use proxy server checkbox and provide additional proxy parameters.

    We recommend that you do not change the Reference Field or Comment RegEx fields. The Reference Field is the system name of the attribute to search when matching the ID in change comments with work items in Lifecycle. The Comment RegEx is used to extract workitem identifiers from the change comments.

  10. Test the connection, and then save the settings.

  11. Choose the Job you want to publish to Lifecycle. Remember that this job name must be configured in Lifecycle.

  12. Click Configure to configure the workspace.

  13. In the Post-build Actions section, click the VersionOne Notifier check box, and then click Save.

Technical Details

Adding Support for Another Source Code Management System

To add support for new VCS, the following actions are required:

  1. Add plugin reference to pom.xml, make sure that this dependency could be successfully resolved.

  2. Add a class wrapping native changeset type. SvnModification or PerforceModification are good examples on how to do it.
    New class must inherit VcsModification interface and provide parameterless public constructor.

  3. Modify VcsModificationWrapperFactory class to support new changeset type.
    It is required to add line similar to classNameMappings.put("jenkins.plugins.perforce.PerforceChangeLogEntry","com.versionone.jenkins.PerforceModification"). String literals are mappings of native changeset log entry classes to our custom wrappers in format supported by Java Reflection, so that instances and class objects could be successfully created. Changesets will be processed as soon as user installs the corresponding plugin and restarts Jenkins server. In fact, our plugin won’t start without its dependencies.

Downloads

Application files for the current and previous versions of this integration can be found in the AppCatalog.

Source Code

Source code for this integration can be found in GitHub.

This feature is available in Ultimate edition only.

editions-u.png

VersionOne IssueSync for JIRA (formerly known as the VersionOne Integration for JIRA) creates Stories and Defects in VersionOne based on Issues orginating in JIRA. Using this integration, your organization can manage and triage issues reported by customers and promote them to VersionOne for the product team to address.

Description

For agile development teams using JIRA and VersionOne, and who need to integrate their issue management with agile project management, VersionOne IssueSync for JIRA is an integration that transforms JIRA Issues into Workitems (Defects or Stories) in VersionOne. Using this integration, an organization can manage and triage issues reported by customers and promote them to VersionOne for prioritization, estimation, planning, and implementation. When the work is completed in VersionOne, the integration updates JIRA to reflect the resolved status.

Once the integration is installed and configured, JIRA users can specify which issues require engineering attention and those issues will automatically appear as Workitems in VersionOne. Additionally, when the Workitems are closed in VersionOne, the integration updates the JIRA Issue to reflect this change. JIRA issues that require engineering attention are identified using JIRA filters.

The following sequence diagram illustrates how the integration interacts with JIRA and VersionOne.

IssueSyncforJira.png

System Requirements

Integration

The integraton can be run on any Windows operating system that supports .NET Framework 4.5.1. Download available here: http://www.microsoft.com/en-us/download/details.aspx?id=40773.

VersionOne

  • 14.0 and higher, all editions. 15.0 or higher if using access tokens for VersionOne authentication.

  • A member account with a Team Member project role or higher permissions.

JIRA

Versions 5.2 and 6.0 or higher. Integration with older versions of JIRA may work, but are no longer supported by VersionOne.

Downloading IssueSync for JIRA

The latest version of the integration is available in the VersionOne Application Catalog.

Upgrading IssueSync for JIRA

If you already have the integration running in your environment, you should backup the existing integration before installing the current version.

Installing IssueSync for JIRA

These installation instructions assume that JIRA and VersionOne are already installed and working properly.

Determine Install Location

The integration can be installed on any Windows system with HTTP access to both VersionOne and JIRA. Exact placement should be determined by your internal software management requirements. The integration system must meet the System Requirements stated above.

Extract Files

Download the integration using the link above and extract it into a folder of your choice.

Configure

Configuration for the Integration is a 3 step process.

  1. Configure JIRA

  2. Configure VersionOne

  3. Configure ServiceHost

Video

Configuring IssueSync for JIRA

Step 1. Configure JIRA

This section describes how to modify your JIRA instance for use with the integration. Before you begin, you need decide if you want to the Assign or Label method to indicate the JIRA issues you want visible in VersionOne.

Select or Create a JIRA User

The integration requires a valid JIRA User ID and a Password in order to connect to JIRA. This user must have sufficient rights to accept work and modify issues (i.e. must be assigned to the Developer Role on the project). This user must also have rights to the actions being performed by the integration (for example, the user must have rights to close Issues).

Although the integration does not require administrator access to run, there are some validation rules that can only be checked with a JIRA Administrator role. To help check first-time configuration, the recommended approach is to elevate the integration user to Administrator. After the integration has been verified (start the integration in the below steps) and before starting as a service (install as Windows Service in the below steps), reduce the JIRA access to the Developer Role. Then you can safely ignore log warnings about validation rules that require administrator access.

Create Filters for Defects and Stories

These filters must be available through the credentials used by the integration; hence, it is recommended that you create these filters using the same credentials to avoid the complexity of shared filters.

The results of a JIRA filter are used to determine which JIRA Issues will be transferred to VersionOne. By using a JIRA filter, you can make the integration fit with your existing JIRA workflow and fields. The details of writing such a filter are beyond the scope of this document; however, the following are some simple examples.

Filter

Description

Type and Status Filter

The simplest Filter is to move all JIRA Issues of a certain type and state to VersionOne.

JIRA_TypeAndStatusFilter.png

Assigned User Filter

If only a subset of JIRA Issues of a type and status should be moved, then you may want to create a Filter that transfers all JIRA Issues that are associated with a specified user.

JIRA_AssignedUserFilter.png  

This method is not supported when integrating with JIRA 5.2 or earlier.

Label Filter

Another method of transferring only a subset of JIRA Issues of a type and status would be to create a Filter that transfers all JIRA Issues that are labeled with "versionone" or some other value you or your organization designates.

jira_labelfilter.png

Please note that the label value must already exist on an Issue in order to create this type of Filter.

Custom Field or Combination

If the JIRA fields above would conflict with existing workflow, you may want to create a Custom Field and use it as part of the Filter.

jira_customfieldfilter.png

Create a Custom Field to hold the URL to the VersionOne Workitem

By default the integration puts the VersionOne Workitem information in the "Comments" section of the Issue. This information includes a URL to the VersionOne Workitem. You may optionally add another field to hold this data as necessary. To do this create the JIRA Custom Field and note the 'fieldId' value in the JIRA URL. This value is available to the JIRA Administrator.

Step 2. Configure VersionOne

Skip this step if you are configuring a VersionOne Team Edition instance.

  1. Add "JIRA" to Source of the Global List Types:

  2. Determine where to store the JIRA ID
    The integration needs a text field in VersionOne to store the JIRA identifier; by default this is the Reference field. If you are already using this field, you'll need to create a custom text field in VersionOne and note the name.

Step 3. Configuring ServiceHost

To configure the JIRA integration you need to run the ServiceHost configuration tool: ServiceHostConfigTool.exe

The following section describes how to configure the integration using the configuration tool.

On the General tab specify your VersionOne connection details:    

The following table describes the fields on this tab:

Field

Description

Authentication

The API authentication method used by the integration to connect to the VersionOne server.

Access Token

The access token generated for the VersionOne member account that the integration will use.

Server URL

This is the URL to your VersionOne server.

Username

VersionOne user that will create Workitems (Defects and Stories), used only when not using an access token.

Password

Password for the specified VersionOne user, used only when not using an access token.

  1. If there's a proxy between this machine and the VersionOne instance, you'll also need to configure the following settings:

    Field

    Description

    Use Proxy For Connection

    Determines if the integration tries to connect through a Proxy.

    Proxy URL

    This is the URL to your Proxy Server.

    Proxy Username

    The username that will get you past this Proxy.

    Proxy Password

    The password for the Proxy Username.

    Proxy Domain

    Name of the Proxy Domain.

  2. Once the VersionOne parameters are specified, click Validate button to continue. You should see a "VersionOne settings are valid" message appear before you can advance to the next step.

  3. In the Workitems section, specify the VersionOne field that will hold the JIRA ID.

    The following table describes the fields on this tab:

    Field

    Description

    Reference Field Name

    VersionOne field used to hold JIRA ID; by default this is the Reference field. If you created a custom field in VersionOne for this value, enter it here.

    Disabled

    Check this box to disable polling VersionOne for Workitem updates.

  4. On the JIRA tab specify your JIRA connection details and the Issue transfer behavior.

    1. Configure the JIRA connection.

      Field

      Description

      Disabled

      Check this box if you want to disable polling JIRA for new Issues.

      JIRA URL

      Fully qualified URL to your JIRA instance.

      Don't forget /rest/api/latest

      Username

      Valid JIRA user. This user must be able to see and update Issues in the appropriate projects.

      Password

      Password for specified user.

    2. Click the Validate button to ensure the connection parameters are correct.  You should see a "Connection settings are valid..." message appear as confirmation.

    3. Configure VersionOne Workitem attributes.

      Field

      Description

      Source

      Select the VersionOne source value to use for JIRA.

      VersionOne Team Edition contains a Source value of "External System".

      URL Template

      Template for URL to access specific Issue in JIRA. /browse/#key# is replaced with the JIRA Issue ID. This field is used to create links from VersionOne to JIRA.

      URL Title

      This field is the Link title in VersionOne.

    4. Configure Poll Interval.

      Field

      Description

      Poll Interval

      Determines how frequently the integration polls JIRA looking for issues in minutes.

    5. Configure Find JIRA Issues.

      Field

      Description

      Create Defect Filter ID

      JIRA identifier for the filter used to determine which issues are pushed to VersionOne as Defects. This field cannot be empty.

      Create Story Filter ID

      JIRA identifier for the filter used to determine which issues are pushed to VersionOne as Stories. This field cannot be empty.

    6. Configure Update JIRA Issue.

      Field

      Description

      Link to VersionOne Field ID

      Custom Field Id in JIRA used to hold VersionOne URL. If blank, the URL will be created in the Comments field in JIRA.

      Create Field ID

      Name of the JIRA Custom Field to update after a Workitem is created in VersionOne. If left blank, the JIRA Issue Status field will be updated.

      Create Field Value

      Value to set in "Create Field ID" after a Workitem is created in VersionOne. If left blank, the JIRA Issue Status field will be updated to IN PROGRESS.

      Close Field ID

      Name of the JIRA Custom Field to update after a VersionOne Workitem is closed. If left blank, the JIRA Issue Status field will be updated.

      Close Field Value

      Value to set in "Closed Field ID" after a the VersionOne Worktiem is closed. If left blank, the JIRA Issue Status field will be updated to RESOLVED.

      Assignee State Changed

      The name of the JIRA user to assign to the Issue once it's closed in VersionOne. A value of -1 will cause JIRA to set the assignee based on workflow rules.

      Progress Workflow Created

      The JIRA Workflow Transition ID to set once it's created in VersionOne.

      Progress Workflow Closed

      The JIRA Workflow Transition ID to set once it's closed in VersionOne.

  5. Map your Projects

    Project Mapping allows you to specify where Workitems are created in VersionOne. The algorithm for selecting a project is as follows: First, the integration looks for the JIRA Project Name in the map. If it exists, the Workitem is created in the corresponding VersionOne Project. If the JIRA Project Name is not found, the integration attempts to find a VersionOne Project with the same name. If found, the integration creates the Workitem in the VersionOne Project with a matching name. If it cannot find a VersionOne Project with a name that matches the JIRA Project, the integration will create the Workitem in the root level node of the VersionOne Project Tree or in the first project in the list if there are multiple top level nodes.

    To add a Project Mapping you need to do the following:

    1. Click on the Project and Priority Mappings tab

    2. In the Project Mapping grid, select a VersionOne Project value from the dropdown list.

    3. Supply the corresponding JIRA Project name.

    4. To remove a mapping: Select the desired row.

    5. Click the Delete selected row button

  6. Map your Priority Values

    Priority mapping allows you to configure how the VersionOne Workitem priority value is set based on the JIRA Priority value. The algorithm for mapping is simple, if the JIRA Priority value is in the mapping, the VersionOne Workitem priority value is set to the mapped value. If the JIRA Priority value is not found, the VersionOne Worktiem priority value is not set.
    Updated-Config-Tool-Mappings.png

    To add a Priority Mapping you need to do the following:

    1. Click on the Project and Priority Mappings tab.

    2. In the Priority Mappings grid, select a VersionOne Priority value from the dropdown.

    3. Select the corresponding JIRA Priority value. Note that one VersionOne priority value may map to more than one JIRA priority value.

    4. To remove a mapping: Select the desired row.

    5. Click the Delete selected row button.

  7. Save your changes and exit the configuration tool.

Running IssueSync for Jira

  1. Start the IssueSync for Jira.

    Navigate to your installation folder and double-click VersionOne.ServiceHost.exe.  A command window will open. If you have configured your system properly, you should see several [Info] messages followed by a [Startup] message.

  2. Test the integration

    To ensure the integration is working properly, perform the following steps:

    1. Create an Issue in JIRA.

    2. Set the appropriate criteria based on your specified filter in order for the Issue to move to VersionOne.

    3. Verify that the Issue appears in VersionOne as either a Defect or Story (depending on the Issue Type you selected in JIRA and specified in your Filter).

    4. Verify that the JIRA Issue Status has been updated to IN PROGRESS.

    5. Close the Workitem in VersionOne.

    6. Verify that the JIRA Issue Status has been updated to RESOLVED.

    7. Shut down the integration ServiceHost by pressing "Q" in the console window.

  3. Install as a Windows Service

    Run the following command from the console window:
    VersionOne.ServiceHost.exe --install

    This command installs the integration as a Windows service that will will run under the NT AUTHORITY\Local Service account. The Local Service account must be given access privileges to the directory where the the integration executable was installed so it can store its state and write to log files. Follow the steps below to change the security on the installation directory:

    1. Right click the installation folder from Windows Explorer.

    2. Select "Properties".

    3. Select the "Security" tab.

    4. Click the "Add" button.

    5. Enter "Local Service" and click "OK".

    6. Click the "Allow" checkbox for the "Full Control" row .

    7. Click "OK" to save the changes.

Troubleshooting IssueSync for Jira

  • If you cannot connect to VersionOne:

    • Verify the URL of your VersionOne instance.

    • Verify that you have chosen the correct authentication type for your VersionOne instance.

      • If your authenication type is Access Token and your token is entered into the appropriate box and you are unable to connect, you may need to generate a new one.

  • If the Issue Status does not update in JIRA:

    • Verify the values of the Progress Workflow Created and Progress Workflow Closed fields in the integration configuration tool.

      • Navigate to Administration -> Issues -> Workflows

      • Select View under the Operations column for your project.

      • You should be presented with a table containing Linked Status and Transitions (id). The VersionOne Linked Status is OPEN.

      • Upon creation in VersionOne, an Issue Status should be updated to IN PROGRESS.  Determine the Transition Id value per the specified Workflow for your project.

      • Upon close in VersionOne, an Issue Status should be updated to RESOLVED. Determine the Transition Id value per the specified Workflow for your project.

      • Enter or verify those values in the integration configuration tool.

    • Verify the JIRA Filter IDs for Create Defect and Create Story.

      • Click on the Issues menu and select your desired Filter name.

      • Check the browser URL for ?filter= and make note of the Id after the =.

      • Enter or verify that value in the appropriate field of the integration configuration tool.

Technology

More Information

For more information, visit the VersionOne IssueSync AppCatalog page.

 

 

This video has been moved to a new location. Go to VersionOne IssueSync for JIRA Integration to watch how to use your JIRA issue tracking system to load defects into VersionOne and update JIRA when they are closed out by the team.

Extend VersionOne and create a single, synchronized agile software development environment with more than 70 pre-built integrations to best-of breed software development tools. Integrations are available for all VersionOne product editions, or you can build your own using VersionOne's open, web-service API and SDKs (Java & .NET). To see the complete list, visit the VersionOne Application Directory.