Teams across many industries struggle to optimize product delivery and quality or increase transparency and predictability.

The new DevOps integrations in Targetprocess serve these goals and more. They compliment planning work in Targetprocess by adding visibility into the work in progress, workflow automation and comprehensive analytics at any point of the value delivery process.

Any integration in Targetprocess unlocks a number of possibilities immediately after it's been set up.

There are:

Let's talk about these possibilities one by one.

If a company is using several tools or services, context switching is always an issue. It's a pain to switch from one tool to another and to know which item in one tool is connected to what data in another tool. We try to solve this in our integrations.

We add important information from third-party tools into Targetprocess. Therefore, Targetprocess becomes a source of information where you can quickly and easily see important things in one place.

Here is an example with a GitLab integration.

If you open a card in Targetprocess, you can see a specific work item. We quickly show all pull requests and branches related to this work and give you the ability to easily navigate to third-party systems (like GitLab, in this case).

We also show additional information, for example, the state of the merge request. Here you can see it's closed. You can see pipelines and the code review status for the specific branch.

All this information is available on the boards as an extra control.

A very important component of Targetprocess is the sub-system of Automation Rules that we released not so long ago.

This is a very powerful development that lets you automate the processes inside your company. Originally, it was designed for some events happening in Targetprocess, so you could make changes to the data in Targetprocess. As a result we can trigger some actions and implement various business logic.

For example, if the state of the User story is changed, let's close the state of the new feature.

This unlocks the possibility to create various new scenarios. For example, if the state of a card is changed and we move a User story to "tested", then please merge a pull request that is linked to this card.

Opposite-direction scenarios are also possible. For example, if a pull request has been merged, then let's change the state of the card in Targetprocess.

For example, in GitLab, if a pipeline passed for some service and the tests have been passed, we can trigger a pipeline with integration tests in another repository.

For example, if in GitLab a pull request has been merged and pipelines passed, let's trigger another pipeline in Jenkins.

As you can see, we gain the ability to automate processes that go beyond Targetprocess in a company and involve a certain set of tools the company uses, as long as we have integrations for these tools

This is the last important aspect. We perform all our integrations so they also integrate into our visualization system, our BI tool Vizydrop. This lets us build analytics using cross tool data. For example, we can build a report in Targetprocess that also incorporates GitLab's pull request data.

Here is a sample report built with the help of our DevOps integration: PR lead time by Teams.

If you go to Settings, you will see a new Data source called DevOps.

This report shows you the cycle time and the number of pull requests every team in Targetprocess has done over the last 90 days.

We take data from GitLab, map it to data in Targetprocess, and can see how different teams work. This can serve as a source of extra useful information because you can now analyze the efficiency of processes happening in other tools outside Targetprocess.

Here is another interesting report to look at: PRs Lead Time by Iteration.

How did the cycle time of pull requests of one team change over time?

This is our team, and we can see that in every sprint we worked differently. Our efficiency and approach to work have been changing. We see the cycle time of pull requests has been declining, so we made smaller changes in code, which is also indicative of the quality of processes inside the team.

Another example is the Areas of Responsibility report.

Here we can see which people are contributing to specific features in the system. A bubble shows the number of pull requests for a certain feature, and we can easily see how many pull requests have been made and reviewed, who made them, and for which features they have been made.

Time to sum it up.

We are working on the DevOps integrations with the following goals in mind: