JIRA Integration - Code Cleanup

[smittysmee]

Feature Request: Integration with JIRA Ticket Trigger

Problem Statement:
Teams are often plagued with tech debt because of poor management practices of code & managing feature flags.

Summary:
The integration of Flipt with JIRA ticket triggering enhances the process of managing feature flags by automatically creating JIRA tickets when specific events occur. This feature streamlines communication between development and project management teams, ensuring seamless tracking and resolution of flagged features, thereby contributing to maintaining a clean code-base and reducing technical debt.

How It Should Work:

1. Event Detection: Flipt continuously monitors flagged features and detects specific events such as flag removal or modification.
2. JIRA Ticket Generation: Upon detecting a relevant event, Flipt automatically generates a corresponding JIRA ticket.
3. Ticket Details: The JIRA ticket includes details such as the flagged feature, the nature of the event (e.g., flag removal), and any relevant metadata.
4. Assignment and Notification: The ticket is assigned to the appropriate individual or team responsible for resolving flagged features. Notifications are sent to relevant stakeholders to ensure prompt attention.
5. Tracking and Resolution: Development and project management teams utilize JIRA's tracking capabilities to monitor the progress of flagged feature resolution until completion.

Why We Care:

1. Maintaining Code Cleanliness: By automating the creation of JIRA tickets for flagged features, development teams can ensure that necessary actions are taken promptly to either remove or properly integrate flagged code segments. This contributes to a cleaner and more maintainable code-base.
2. Reducing Technical Debt: Proactively addressing flagged features through automated JIRA ticketing reduces technical debt by preventing the accumulation of deprecated or unnecessary code. It promotes ongoing codebase hygiene and fosters a culture of continuous improvement.
3. Streamlining Communication: Integration with JIRA facilitates seamless communication between development and project management teams. Automated ticket generation ensures that all stakeholders are aware of flagged feature issues, promoting transparency and collaboration in resolving them.

In essence, the integration of Flipt with JIRA ticket triggering optimizes the management of feature flags, aligning development efforts with project management goals and ultimately contributing to the overall health and cleanliness of the code-base.

[markphelps]

@smittysmee great idea!

Teams are often plagued with tech debt because of poor management practices of code & managing feature flags.

I 💯 % agree.

Event Detection: Flipt continuously monitors flagged features and detects specific events such as flag removal or modification.

We could probably leverage our support for Webhooks and Audit Events for this potentially.

What I don't know is how to actually build a Jira integration to accomplish all of the above^. Are you able to help with this/ provide insight into the process/what needs to be built on the Jira plugin side?

[smittysmee]

Dope. Yeah, let me do a little digging in my free time and post back with a rough overview of resources to be used. Would be a nice integration for sure

[thepabloaguilar]

Hi y'all, I didn't see this discussion before I opened the #3498 and @erka put the link there! I think if we follow with the issue idea this could be accomplished inside Jira with their automations despite the links I've put in the issue I just found those as well:

• 🔌 Plug Into Jira: Keep track of feature flags 🚩with Jira Software
• Integrate with feature flags

Maybe this could be the way to go

[markphelps]

thank you for the hard work and research @thepabloaguilar !!

My suggestion here would be to implement before for declarative-backends and then proceed to changing the UI with all the stuff.

I agree, we could likely store any ticket / issue information for each flag in the existing flag metadata field. Not sure how others feel about it.. but we could have some 'well known' fields like '{"jira": { "links": [ ] } }' or similar? this maybe we could even replace struct with a type? not sure if proto allows this though.

Is your POC open source by chance?

[thepabloaguilar]

Sure @markphelps, in fact, it's just a one file app rn 😆

I've created a gist with it if you want: JIRA Feature Flag Integration Test. The only thing is you need to setup a JIRA account

I'd like to discuss more about how we gonna send the data using the REST API - Feature Flags. If you take a closer look a FF for JIRA allows us to send one flag with different environments, doing that it'll look like this:

I see two problems here:

1. People who uses Flipt namespaces as environments
2. People (like me) who uses on Flipt instance per environment

And the problem is the correlation between the flags, how can I say those are connected when sending to JIRA. My first thought was to consider those flags as different (so we end up with a different ID and JIRA will be happy). I'd say that's OK, WDYT?

And about the metadata, I agree we can use it and I can say in advance we need these info:

• JIRA Issue Key (eg.: TEST-1)
• The URL Flipt is being hosted (to create a hyperlink within JIRA)
• Environment (I think the user would choose between a global value or a specific value for that flag, it'll depends on how they deploy/use Flipt)

[thepabloaguilar]

Oh, and just to be clear! The thing about the environment it is because if we send one feature flag with all the environments the JIRA FF counter will show only one flag but if we submit one FF per environment, saying 3, it'll count 3! I don't think this is smth bad we just need to make it clear in the docs this behavior

[markphelps]

Hey @thepabloaguilar ! Thanks for all the help so far and the demo! Looks great.

How can we help get this into Flipt Open Source?

I think we should focus on supporting:

People (like me) who uses on Flipt instance per environment

Atleast at first, since this is likely the most common case I would think. Perhaps we could make it configurable after getting it working, something someone could specify in our config.yml

Related we'll have to think about how this could be configured in general, maybe something like a new config section:

integrations:
  jira:
    api_key: xyz
    URL: ABC

For the metadata part storing on our end i think we could follow a similar pattern for the JSON that will be stored as metadata:

metadata: {
  integrations: {
    jira: {
     issues: [ Test-1, Test-2 ] 
    }
  }
}

Unless I am misunderstanding all of the data we'll need to save on our end.

And the problem is the correlation between the flags, how can I say those are connected when sending to JIRA. My first thought was to consider those flags as different (so we end up with a different ID and JIRA will be happy). I'd say that's OK, WDYT?

Do you mean the correlation between our flag keys and the IDs that JIRA stores? If so I agree they could just be autogenerated before sending to Jira and I guess stored in that flag's metadata perhaps? I think i see the issue, where you will have multiple of the same flag key if using in different environments, which Jira will not like as IDs.

Another question:

We need to create a JIRA app passing some configurations around which is pretty simple and we define up to three callbacks:

createFlag
connectFlag
listFlags

How will this JIRA app work for users running open-source/self-hosted Flipt? Would this mean we (Flipt org) would need to build a Jira App that is hosted on the Jira App store? And it would be a service we run ?

Excited to get rolling on this!! Im just still a bit fuzzy about how it will all work for self-hosted users.

[thepabloaguilar]

I thought on putting the config under the experimental section as it'll not be available for everyone at the first, something like this:

experimental:
  jira:
    enabled: true
    environment: "production"
    authentication:
      oauth:
        cloud_id: "CLOUD_ID"
        client_id: "CLIENT_ID"
        client_secret: "CLIENT_SECRET"

AFAIK we only need the CLOUD_ID for the OAuth method

---

Do you mean the correlation between our flag keys and the IDs that JIRA stores? If so I agree they could just be autogenerated before sending to Jira and I guess stored in that flag's metadata perhaps? I think i see the issue, where you will have multiple of the same flag key if using in different environments, which Jira will not like as IDs.

For example, if a have a flag with the key awesomeNewFeature in two different instances: Development and Production. When sending the FF info we cannot use the awesomeNewFeature as the ID 'cause one of them will overwrite the other, so we need to think in a stable way of generating those IDs. I thought on something like this: {feature_flag_namespace}:{feature_flag_key}(:{environment}), the IDs can have up to 255 characters.

---

How will this JIRA app work for users running open-source/self-hosted Flipt? Would this mean we (Flipt org) would need to build a Jira App that is hosted on the Jira App store? And it would be a service we run ?

Great question, we have two kind of apps for JIRA:

• That one from the link you sent which you put it in their store, I'd say having the app in their store is more like a convenient way for commercial tools (non-self-hosted)
• OAuth app where self-hosted tools can plugin

We gonna create the OAuth app first and when the users is setting up it they can set those callbacks to whatever address they want as you can see below:

And just to remember, those callbacks are "UI redirection" which I think will be the problem because it does not have the namespace concept, so, what namespace should be selected for those callbacks? Maybe a config saying the issues with key BETA-* is for ns beta? But I guess this is a future problem, after we get it work only in the BE side 😆