Scalable custom fields deployment & removal

Question

Problem: Our typical deployment size of JIRA projects is to mega engagements who use Jira extensively. As a result, our custom Jira solution needs us to create 100 custom fields per deployment to a client. Every client has their own Jira instance (Server/DC).

We want to ensure we are not repeating the custom fields that are already there on the instance, however, because of our deployment timeframe, we cannot afford to manually check for same-named custom fields. As a result, we would seek a suggestion on how to best name custom fields which are: unique and repeatable in the way they are defined.

Please note all the above deployment is happening in an automated fashion via a plugin.

Catch: Once our contract with the client is complete, we "uninstall"/de-configure the solution we have built into the system.  And for this uninstall process, we need a "convenient" way of identifying custom fields that we have created so that we can remove the custom fields which we have defined.

Options Explored: We have explored using a prefix/suffix for custom fields. For eg, you have a field called Target Completion Date. We have tried it with "Prefix" Target Completion Date & Target Completion Date "Suffix". The problem we may run into here is that the prefix/suffix may make the search of a field for a user very difficult when trying to create Filters. If you are aware of a smart way of approaching this, happy to hear. Thanks.

Radek Dostál · Answer

I'm a fan.

How does SR come to the solution with regard to Custom Fields?

I know it has some out of box scripts but to create fields, I'm guessing you are using the console or executing cURL remotely to run your code?

Within groovy you could work with files on the file system, so could keep your "config file" so to speak containing a list of custom fields created through SR.

If running your code remotely (cURL) you could as well store that file locally without trusting your customer won't perhaps change or delete the file somehow.

Other than that.. still no better idea.. :)

Yash Doshi_376rox · Answer

Thanks Radek. The prefix/suffix in custom field names were our way of defining a "label".

We are using Adaptavist's Project configurator to automate the deployment of our solution configuration.

Radek Dostál · Answer

Hi Yash,

So if I understand then you are essentially looking to "filter" through custom-fields, to identify which ones are to be uninstalled.

Then there would need to be some form of a "label" or a "tag" one way or another (unless maybe storing a list of created fields in a separate sheet somewhere), since custom fields have no other labeling thingy - not that I'd ever come across one even on the marketplace. Sounds like a pretty limited use case.

Not sure how you are creating those fields in the first place - is it via your own plugin or does somebody create those fields manually?

Could perhaps automate it with your plugin, which in that case could be automatically storing that information somewhere for later use (incl. field removal). At the same time, it could do a quick custom field name check before it creates the field so you can either re-use your customer's field, or just name it differently (e.g. warning pops up for you to change the name).

Even if someone needs to go in and manually create a field, doing it through your own plugin instead which would store the data someplace safe, perhaps a custom table in the db, sounds like one way.

At least first idea that comes to my mind, maybe I'm missing a few things though;

Regards,

Radek