Tackle Integration with Jira #85
Conversation
Signed-off-by: Ramon Roman Nissen <rromannissen@gmail.com>
rromannissen
changed the title
|
|
||
| - Adoption leads are frequently not part of the organization that is executing the migration initiatives, and it is very common that these are managed by migration/adoption experts from consulting teams from GSIs and vendors. This integration would allow adoption leads to keep track of the progress of the overall initiative or at application level without having to create profiles in the corporate tooling for them, or requiring them to understand how such tooling works. | ||
| - Migrators, or the developers in charge of executing the actual changes in the applications, are often part of Third Party factories provided by partners or internal development teams belonging to the organization itself. It is fairly common for organizations to keep track of the work executed by such resources using their own task/issue trackers. This approach would avoid having to log this work twice with two different tools, and might even prevent some development teams from having to learn another additional tool. | ||
| - This integration would enable Tackle to aggregate progress and status data about the overall migration initiative, opening the door for executive dashboards that could be consumed by a potential new senior management persona. |
There was a problem hiding this comment.
I guess we should decide with @jwmatthews and @jortel if we want to get started replacing the terminology and refer to Tackle as Konveyor from now on.
There was a problem hiding this comment.
+1 to replace terminology. I am trying to do this with how I speak/write but I still slip up :)
In future we should consider if we want to go further and change repository names as well.
|
|
||
| #### Architect | ||
|
|
||
| A technical lead for the migration project that can create and modify applications and information related to it. The Architects don’t need to have access to sensitive information, but can consume it. Example: Create an issue from an application without knowing the credentials of a given Jira instance. |
There was a problem hiding this comment.
Is there a security layer here that we need to make sure is covered?
The use case is Architect A has access to applications 2 and 3 but not 3. They probably shouldn't be able to access the Jira instance for 3, right?
There was a problem hiding this comment.
Not really, the idea for this is to abstract Architects from using nominal Jira accounts. A service account is provided by the organization, and Architects can use it to access Jira indirectly. Regarding access to application 1 or 2 for an Architect, we don't have the concept of multi tenancy in Tackle. All architects are able to access all applications, so by extension it makes sense they are able to access their associated information in Jira as well, at least indirectly.
There was a problem hiding this comment.
Sounds good for now. I do think that this is a feature that we should add to the backlog then.
I see it being useful for managed services as well as Active Directory integration.
| - *Enable insecure communication*: Toggle. | ||
|
|
||
|
|
||
|  |
There was a problem hiding this comment.
Nit: naming concern
Doesn't Jira call a running thing that you use an instance? could we re-name this to connection or something so that no one thinks we are spinning up a Jira Instance?
There was a problem hiding this comment.
Yeah, good catch. I'd say "Create Jira Instance Connection" could make more sense. How does that sound?
There was a problem hiding this comment.
+1 was a small concern and it think that would solve it!
|
|
||
| ## Design Details | ||
|
|
||
| ### Test Plan |
There was a problem hiding this comment.
We have this as an open question I do think we should figure this out before merging.
we should also add to this, how does changes in the integration code when changed, also run through the hub and the hub should run the implementation when it changes. IMO.
Signed-off-by: Ramon Roman Nissen <rromannissen@gmail.com>
|
LGTM, I read what's captured so far and makes sense. |
Added Implementation Details/Notes/Constraints
|
@joseacr @tprumbs I think the best approach here would be for you to share details on how to interact with the different flavors and versions of the Jira API. Creating a standalone service would require additional resources for the deployment of Konveyor/Tackle, and the team is considering to include the integration with issue trackers as part of the core. Another interesting topic to contribute to would be to define automated testing strategies when dealing with Jira. We don't know of there is any kind of mock API or a way to spin up Jira instances on demand, but we definitely need something for our automated end to end tests. |
I completely agree @rromannissen. We will bring our functional knowledge about JIRA and its integrations. |
Revert "Added Implementation Details/Notes/Constraints"
Signed-off-by: Ramon Roman Nissen rromannissen@gmail.com