![](bg3.png)
DevOps, then at runtime even the order service might
fail. Whereas in the past, often only one project was
developed, today, with these numerous dependencies
on other services and the uncertainty of how often
these are deployed, the uncertainty of when errors
might occur has increased dramatically. Although the
teams typically write e-mails to each other as found
out in an industry expert survey (Speth, 2019), typi-
cal problems are that after a short time nobody might
read them because they come in a frequency that can-
not be processed without support. Since the order ser-
vice’s development team does not have the ownership
of the shipping service’s source code, they cannot fix
their bug themselves. As a result, they have to create
an issue in the shipping service’s issue management
system. Nevertheless, the issue for the order service
should be documented as well.
Use Case ”Issue Synchronization”. Next, consider
a similar example where two components depend on
the payment service’s interface and, therefore, the is-
sue would be propagated to both dependent compo-
nents. The resulting issues of order service and ship-
ping service components are semantically equivalent.
However, as both components manage their issues
in different issue management systems, the issue in-
stances cannot be the same. Therefore, a change in,
e.g. the order service’s issue, has to be propagated
to the shipping service’s issue. However, as no issue
management system technology supports such propa-
gation across issue management system boundaries,
teams need to find a way of synchronizing the is-
sues. Here, often e-mails or business messengers are
used (Speth, 2019), but no dedicated tooling.
Use Case ”Linking to Other Component’s Inter-
faces”. In the last use case, we focus on a new func-
tional interface for an API endpoint of the shipping
service. The order service has to be adapted to use
the newly developed interface feature of the shipping
service. Therefore, a feature request for the order ser-
vice component is created. However, developers need
to know how the new interface looks like they have
to adapt to resolve the feature request. A description
using only the issues’ text body is hard to understand
and might be not complete. As a result, linking the
issue to the interface description of the new endpoint
of the shipping service would provide an excellent ad-
vantage for the issue’s description and comprehensi-
bility. However, the shipping service’s source code
and artefacts are stored in a different repository sys-
tem than the source code and artefacts of the order
service. Thus, linking an issue to an artefact of an-
other component is impossible due to the bound of
an issue management system’s project with a compo-
nent’s source code repository.
2.3 Problems of the Scenarios
While there are tools that allow issues to be managed
from multiple components or synchronised across
components, such as the Jira plug-ins Backbone Is-
sue Sync (K15t, 2020) and Multi Project Picker (Bro-
ken Build, 2020), these only work within the same
issue management system vendor (Speth et al., 2020).
However, due to the distributed architecture and mod-
ern microservice and DevOps approaches, each team
can choose its own desired technology stack (New-
man, 2015; Nygard, 2007). This results in the fact that
such a component-based architecture often manages
its issues in many independent issue management sys-
tems from different vendors. Existing tools do not
provide the functionality required regarding manag-
ing issues across multiple components developed by
different teams. As a result, managing such issues re-
quires complicated communication, as several inde-
pendent teams may be involved.
In the third use case, an issue should link to an
artefact from another component. However, in state-
of-the-art issue management systems, such links are
only possible within the system as an additional prop-
erty or as a URL in the issue’s body. Quick access to
such artefact dependencies of other components with
clear semantic representation is not possible. A fur-
ther problem is the representation of issues that af-
fect several components in existing tools. A repre-
sentation in a concrete textual syntax, as developers
are currently used to from all state-of-the-art systems,
is well suited for issues of individual components.
However, as soon as an issue affects several compo-
nents, or is dependent on an issue of another com-
ponent, this can only be represented poorly in tex-
tual terms which means that quick access to the is-
sues on which the issue is dependent is not possible.
Often important information is lost or can be easily
overlooked if other components are involved. One
reason for this is that the current textual representa-
tions do not consider the overall architecture of the
system. In the usual tools, such as Jira or GitHub,
this is always a project-specific scope in the sense of
an issue management system project. However, to
effectively present cross-component issues, a cross-
project or cross-component scope of the issue man-
agement system is required without having to migrate
the existing applications to a new issue management
system. Additionally, a representation of such cross-
component issues requires the inclusion of the over-
all systems’ architecture to gain a cross-component
scope instead of a single-component scope and model
the cross-component influence of an issue in a clear
and comprehensible way.
CLOSER 2021 - 11th International Conference on Cloud Computing and Services Science
306