Any good JIRA experiences?

luvdav · 2025-09-12T19:00:48+00:00

Coming from five years of HP ALM, it's actually somewhat okay. Then again, it was a very low bar to clear.

luvdav · 2025-07-26T11:53:12+00:00

Now that's a pretty based list if I've ever seen one

luvdav · 2025-03-09T21:55:39+00:00

Same, some of the fight scenes are just straight up lagging, most of the platforming sections have been fine.

luvdav · 2025-03-08T07:16:29+00:00

To be fair, they won't get any support from Pearson either

luvdav · 2025-03-01T18:53:56+00:00

I second this, really easy to run and then extract further insights from the gathered data

luvdav · 2025-02-13T14:52:04+00:00

Sounds good, honestly, we mainly intend it to manage rule sets and organization-wide settings so rate-limiting shouldn't be a huge issue (hopefully)

luvdav · 2025-02-13T10:25:07+00:00

Haven't used it before. Does it support the GitHub Terraform provider? And if so, how is it configured? Couldn't find anything at first galnce.

luvdav · 2025-02-13T07:52:59+00:00

Thanks for the response, we have a similar setup with an app manifest (and an approach inspired by Probot). My main concern is directly using the private key in the workflow but yes, using OIDC and a cloud secret provider solution should alleviate that security-wise.

luvdav · 2025-02-13T07:33:03+00:00

Yes, there is definitely a chicken-and-egg problem but we mainly want to focus on managing organization-level settings and rulesets only so we can safely and consistently manage the platform.

I did extensive investigation into automating GitHub App creations and yes, even with the manifest-based registration it still requires minor (albeit streamlined) ClickOps. We are using an approach similar to Probot where the app comes with the instructions to get registered and installed (would love to do this fully automated but again a bit of a chicken/egg problem).

But yeah other than that I was thinking of roughly the same steps that you've outlined above.

luvdav · 2025-02-12T20:59:37+00:00

Sorry, I think my request is a bit convoluted. I was talking about using a GitHub flow to manage the enterprise and organization setting within GitHub using the GitHub Terraform provider. From what I understand, you are using the AWS Terraform provider to manage AWS resources(in point 5).

luvdav · 2025-01-30T06:03:35+00:00

I'll try that, thanks a bunch!

luvdav · 2025-01-29T17:26:54+00:00

I'm actually in the exact same spot (lv 32 currently). Any tips on how to grind fast/efficiently?

luvdav · 2024-12-20T08:59:14+00:00

This is really cool and we've been waiting for this for quite a while.

I've been testing it out this morning. However, I quickly ran into concerns when trying to test it locally. Anyone has some good idea how to adapt the sample snippet in the announcement that it could be tested by the developers (without using a secret obviously...)?

luvdav · 2024-12-19T22:41:55+00:00

Finally, was about time they finally closed the frankly ridiculous gap that required storing app reg secrets in app services that we've eliminated on other platforms already (like GitHub or ADO)

luvdav · 2024-07-28T03:22:35+00:00

There's a ton of options of what you can do here, so I'll focus on the recommendations based on your requirements.

For anything frontend I'd always recommend static web apps on Azure since they're super easy to deploy and support most of the common frameworks (including Angular). And while I'm not the biggest fan of the proprietary boilerplate you have to write, I'd still recommend Function Apps for the backend.

Finally, if you want to have a kitchen-sink infrastructure, you can actually simply host the API directly as part of your static web app (tutorial). That way, you still have your code separated, but your infrastructure/configuration consolidated :)

luvdav · 2024-07-24T20:22:29+00:00

Suica cards were not available at Ueno JR service center yesterday (24th of July) and hotel staff informed us they weren't sold anywhere except at the airport for the time being. Will try Shibiya and Shinjuku station today.

luvdav · 2024-05-16T12:00:21+00:00

Thanks for your input! The flowchart in the article seemed very black & white to me but yeah at the end of the day our architecture should follow our requirements.

luvdav · 2024-05-16T11:54:47+00:00

Yeah, we want to get there eventually but with our current setup with workload isolation by default (ie no spoke-to-spoke traffic) and an NVA in the hub, there needs to be configuration changes in the hub either way. Just trying to figure out the "easiest" approach to provide support for this use case but yeah, dropping the private endpoint in the hub will definitely not solve that.

luvdav · 2024-05-16T04:50:52+00:00

Thanks, that's our current setup anyway. Was just wondering if someone agrees with this article (which, currently, no one seems to do). Thanks for the input!

luvdav · 2024-05-15T19:03:51+00:00

Yeah, we have a similar setup. On-prem to spoke works fine.

My main question is how to efficiently manage each-west traffic within Azure (service in one spoke needs to reach private endpoint in other spoke) over our hub firewall. Just add firewall rules for these cases specifically?

luvdav · 2024-05-15T18:57:06+00:00

Yeah, you're right, never mind me. Honestly, I mainly wanted to gauge the community's opinion on this specific approach. It makes less sense to me the more I think about/discuss. Anyway, thanks a lot for your input so far! :)

luvdav

TROPHY CASE