Ticketing system in proget?

[paul.moors_5682]

Hi,

Having the best practises as described in proget package promotion implemented I want to more in control over which packages have to be promoted.

At this moment I have a separate process in place in which in engineers can request a specific package-version in which certain criteria are being checked before the actual promotion can is done (or not). These criteria are described in a single (markdown) file.
This all works fine, but it is difficult to setup traceability from the request to the actual package promotion. (Multiple tools are involved causing unnecessary context switches.

This is where the idea crossed my mind if it is possible to have a kind of ticketing system added to proget that provides that supports this package promotion request process.
So basically a system to support the process of requesting and decision of promotion of packages.

(This ticketing system could be similar to the support-ticketing system currently available for Inedo products.)

[apxltd]

Hi @paul-moors_5682 ,

Thanks for sharing this idea; it's interesting idea and is actually something we talked about internally over the years.

However, after several conversations with a few customers who used the Package Promotion Workflow, they wouldn't find any value or use the feature. The reason is, they already have workflow tools (ServiceNow, JIRA) that document/automate SOP like these, and some will even do a quick API call once the package is approved.

In other words, everything happens in the workflow tool -- which is used for every other SOP from architecture review to vacation requests.

Now just to comment on the "best practices" part; we are working on revising our practices, but we don't consider "package promotion" the best practice anymore. Instead, we consider it the "option with the most control (and highest cost)".

If that level of control is not needed by the organization, then it shouldn't be used -- given the explosion of dependencies (1000+ for the average npm project), it's a lot of process to maintain. A lot of customers (military contractors, etc) are used to that level of process/control and it's fine.

But if you try to institute this at an organization without this process-heavy culture, you'll get a "rebellion" and just see shadow-IT and bypassing of these rules. And they won't get fired or even scolded.

And that brings us back to why no one seems to want this type of system -- companies with this level of process use ServiceNow/JIRA for everything already.

Cheers,
Alex