So it’s time for a JIRA Server Upgrade

So, I was recently contacted by a good friend. He isn’t a JIRA Admin, at least by trade, but he’d kind of found himself in the role anyways. He’s facing an upcoming upgrade, and wanted to know if I wanted a side gig helping out.

Unfortunately, as I’m a consultant in my day job, there was some concerns about me doing the same thing on the side, so I had to decline. However, that doesn’t mean I can’t help out.

A JIRA upgrade is no trivial manner, but they happen everyday somewhere. If you know what you are doing, you can even automate it – to a point. I obviously don’t recommend automating a production upgrade, but for testing it wouldn’t be a terrible idea.

For this I’m going to use my JIRA Test instance. It’s running on CentOS and MySQL 5.7, and is currently running JIRA 8.4.3. For this I’ll be targeting the latest Enterprise release 8.5.3. Your system may vary a bit, but so long as you are on linux it should still be the similar enough that you can follow the post.

And yes, I am aware of you windows folks out there. I do owe you an install and upgrade guide too. But I only have one windows server license – and well…it’s in use. So that will have to wait for another day.

Data Center?

So, this guide here today is for JIRA Server. There are a few extra steps in a Data Center Upgrade, but the benefit to Data Center is you can upgrade without downtime, as you upgrade each node one at a time. So, I’ll cover a Data Center upgrade next week.

When you need an expert

So, my day-job is as an Atlassian Partner and Consultant. So – it’s my job to help people with their JIRA problems. And sometimes that includes helping people plan and execute their JIRA upgrades. So trust me, sometimes experts are needed.

So, when do you need an expert? Well…that depends. How confident are you in doing this yourself? Do you foresee problems you don’t know how to fix? What’s your support plan?

I’ve learned a lot by doing upgrades myself and getting help when I ran into a problem I couldn’t fix. But I had the benefit of working with Atlassian Premiere Support, and every time I came across a problem I’d work closely with them to learn what went wrong, what it’s supposed to do, and how to fix it.

That being said, I’ve been known to live off of adrenaline, and some people’s tolerance for this sort of thing is…less. Ultimately, there are no hard rules I can give you for when you need help. It comes down to your unique situation. But if you feel you do need help, don’t be afraid to reach out to an Altassian Partner. That’s what we are here for.

Planning it out

So, you want to go forward with the upgrade. What’s next? What are the questions you want to answer?

Well, the first question is “When should you upgrade?” This depends on your teams, but I find a good rule of thumb is to try to get an upgrade in every six months. This not always going to happen, but you shouldn’t let it go more than a year out. Updates to JIRA Server not only include new functionality, but a multitude of bug and security fixes as well.

However, you don’t always get your way. When I was working with Development teams, I’d always avoid an upgrade leading up to and immediately after a release. This is a time your teams depend on JIRA most, and having it down just isn’t an option, even for an hour.

Next question you have to answer is “What Version am I upgrading too?” To determine this, I’ll spend an hour or two with the JIRA Release notes. Not only will I go over each feature release, taking notes on which new features are available, but I’ll also look at each feature release’s upgrade notes for gotcha’s and changes. As I’ve stated in previous post, I give a heavy preference to an Enterprise Release.

After this, you should ask yourself “Will I need to upgrade anything else?” It doesn’t happen often, but sometimes Atlassian will deprecate support for a particular Database or JRE Version. So you should check the Supported Platforms Section to see if your systems are still good. Assuming you are, you can move on to testing. If not, take the time to get your supporting systems up to a supported version, then proceed.

And the last question you should be asking is “How will this affect my Addons/Apps?” Not every app is compatible with every version of JIRA. In order to account for changes in the JAVA API between different versions, a particular version of an app will only be compatible with a particular set of versions of JIRA.

Thankfully JIRA manages all this for you. You can even get a report of what apps will be compatible with the version of JIRA you are going to. Go to Manage Apps -> Manage Apps -> JIRA Upgrade Check

Here, you can select another release of JIRA, and it will give you a list of what apps are good to go as is, what apps will be good to go if updated, and what apps are not available for that version of JIRA. This will give you a heads up on what changes you need to make to be ready.

Now an App upgrade should be treated with the same respect as a JIRA Upgrade – even though it is far easier. App upgrades can change features your teams depend on, so always do them first in test and have your teams review that functionality to make sure it works as expected.

Test Test Test

So you have all the questions answered, what’s next? Well, Testing! Wait, is this déjà vu ?

Yep, I actually did cover how to go about testing last week. You should go back and read that. 😉

I’ll take a backup of my test instance, and upgrade it, then figure out what breaks. Then I’ll figure out how to fix that, document the fix, reset the instance, and test the full upgrade – including fix – again. I’ll rinse and repeat until I have a fully documented upgrade with no bugs.

This is always a bit of work, but I’d much rather break it in testing than in production. The last thing you want is to come into work the Monday after the upgrade to find a line at your desk. Trust me on that one.

Once you are happy with your test system upgrade, now comes the wait. You should give a week or two for end users to test the new version of JIRA before you put it into production. Not every user will test things out, but those that care the most will. So give them a chance to find what you might have missed.

Doing an Upgrade on System

So, this is the main event. Whether you are doing it as a test, or in production, the process should be the same. That being said, I suggest you practice it in test first to get a good feel for doing it yourself.

Now I shouldn’t have to say this after last week’s post, but here it goes. Backup now. Even if it is a test, give yourself an easy way back to a pre-install state. If you must do it manually, backup JIRA’s Home Directory and take a database dump. IF you can, just take a snapshot of the VM. But make sure you can undo this upgrade easily if you need to.

Either way, you will need to get the download first. Go to Atlassian’s JIRA Download Page. Once there, find the “All Versions Link”, then navigate to your chosen version.

Once you click the “Download” link, you will select “Linux 64 Bit” from the dropdown, click the check box to approve the EULA, then download the software. After this, you will need to transfer this file to your server via your favorite method.

Once on your system, you should have a file named “atlassian-jira-software-<version>-x64.bin”. We will make this file able to be run as a program using a chmod command. Be sure you are running the commands that follow as root.

chmod 755 ./atlassian-jira-software-*-x64.bin

Before we start the upgrade, we will need to shutdown JIRA.

systemctl stop jira

And once it’s stopped, we can initiate the upgrade

./atlassian-jira-software-<version>-x64.bin

The first option we face is just making sure we intended to start the installer. Take a second here and confirm the version matches what you are intending to upgrade to, then click “Enter”

After this, it will ask you the operation you intend to undergo. The Installer will detect that JIRA is installed on the system, and set the default option here to 3, which is upgrade. So press “Enter” to proceed.

The next option will ask you to confirm your installation directory. Take a second here and confirm this is correct. If it is, press “Enter” to proceed. If it is not, enter the correct directory, then proceed by pressing “Enter”

The next screen will ask you to backup your home directory. Technically, you should have already done this before you started (right?). Therefore, I often skip this step as it can eat up valuable time and disk space. And I already had a backup. But if you didn’t heed my earlier warning, this is your last chance to back up that information.

Next JIRA will check for modified files. These normally aren’t but two or three, with the most common suspect being <jira_install>/conf/server.xml. Open up a separate terminal window and copy these out of the install directory. Once you have these backed up, hit enter.

Next will give you a final checklist, and one last chance to back out. If you proceed from here, you are committing to changing the install directory, and will need to restore your backup to get back to a pre-test state. So hit “Enter” once to confirm you’ve completed the checklist, then hit “Enter” proudly once more. You are ready.

Here, JIRA will backup the current install directory, then replace it with a new one for the new version. For JIRA 8.5.3, it will not copy over any modifications you make, but we’ll get to that in a bit. Once done, it will ask if you if you want to start JIRA. Say “No”.

And JIRA is Upgraded….mostly. Time to deal with those modified files.

Re-adding modifications

So, you can just drop in the modified files you backed up during the install and have things right, correct?

https://gifimage.net/wp-content/uploads/2017/11/isnt-that-cute-but-its-wrong-gif-1.gif

Atlassian will on occasion make drastic changes to these files – changes that if not present, will cause JIRA not to run well – or at all. One such test I did on an upgrade, where I just copied over the files from a previous install, all I had from JIRA was a blank white page. Took me two days to figure out what I had did wrong.

Seriously, don’t be me. Or at the very least learn from my mistakes.

The easiest way we can tell how much has changed is with linux’s diff tool.

diff <backed up version of file> <current version from install directory>

If all you see are your modifications, then probably not a lot has changed. You should still use this as a road map to remake those modifications to the new files. Even a minor change can have an impact, no sense in risking it. Do this with all the files. Slow and steady keeps you out of trouble, after all.

It may also be worthwhile to store these modified files within a git repo – that way you can track what has changed with each upgrade across time. I’ve done it with various productions systems over the years, and it certainly cannot hurt.

After you’ve done this for all modified files, you are clear to start JIRA:

systemctl start jira

For the first start after a new install, I like to follow the logs to see if anything goes wrong.

tail -f <jira_home>/log/atlassian-jira.log

Assuming all is well, we can now log into JIRA’s UI to do the next step.

A note about modified files in JIRA 8.6 and above

As I noted when I looked at JIRA 8.6, the JIRA installer will start looking at your modified files and where it can, copy over the modifications to the new install. To be honest, I don’t like it.

If you’ve been in this business for any length of time, you too likely have a rather healthy skepticism to anything that happens “Automagically”. Even doing this, I’d be one to copy the modified files out during the install and compare the old ones to the new ones.

That being said, I admittedly haven’t done a JIRA 8.6 install yet, and their docs didn’t provide much detail on how the process works, so it could be fine. Just a warning to you in the future that an ounce of caution here might be worth a pound of cure later.

Updating Plugins

When you first get onto JIRA, it will warn you again about those modified files. Ignore the warnings to continue onto JIRA. From here, log in, then go to the Admin Console -> Manage Apps.

Come on Rodney – that isn’t good…

Given how App compatibility works, it’s likely you will have a few to upgrade. Take this time and upgrade these as well. Just click “Update” next to each one.

Be aware when you upgrade the “Atlassian Universal Plugin Manager”, you will need to refresh this page to proceed. That alone usually makes that plugin my first target.

Also be aware that any plugin update will require you to do a re-index. You don’t need to do a re-index for each update, but be sure you do one after you finish.

Wait…that’s not right…OH SHI

Now this guide assumes everything went well. As I’ve stated, everything doesn’t always go well. Hopefully this is in test and you have time to work it out. Even if it’s not, just take a second, and breathe, and relax. This isn’t ideal, but you got this.

IF this is in test, collect any logs files or support packets you can to your local system, then reset your instance back to before you started the upgrade. Try it again to confirm you did everything as you expected to. IF the problem reoccurs, you now have a pattern, and two data points.

Then open a ticket with Atlassian Support, and include everything you have, including a detailed account of the system you are running on, the version you were on, the version you are upgrading too, and all the files you got from the system.

If this is production, get what files you can, and execute your back out plan now. Restore the system to before the upgrade using the backups you have taken (don’t forget to also restore the Database) and bring it back up on the previous version of JIRA. There is no shame of backing out of a bad upgrade. There is shame on keeping your teams without JIRA “while you figure it out.”

Take those artifacts and open a ticket with Atlassian. Because this was production, and an issue that (presumably) didn’t pop up in Testing, it can often get a higher Business Impact than a test system problem.

And that’s it?

Yes, really, that’s it! You have JIRA Server running on a new version! Whether this is test or production, the above instructions should be sufficient to get you across the finish line.

At this point in my career, I’ve honestly lost track of how many Upgrades I’ve done. Using the method outlined above, I can usually complete an upgrade cycle – from kickoff to production upgrade complete, in about three weeks. Most of this time is to give end users a chance to test new features before they hit production.

So…humble brag. January is now the best month the blog has had to date, both in page views and visitors.

I cannot thank you all enough for coming by each week to see what I’m writing about. January has been an interesting month for me, with a lot going on. But being able to sit down at some point each week and share with you something about this tool has been both affirming and stabilizing. So thank you. Now lets see if we can make February even better!

Don’t forget that if you need help, we have a discord community. Stop by, ask questions, and chat with fellow Atlassian Admins: https://discord.gg/mXuRsVu

And until next time, this is Rodney, asking “Have you updated your JIRA Issues today?”

How to test changes in JIRA

So, a bit of a backstory here. I was doing some experiments at work on running JIRA Data Center in Kubernetes using the official Atlassian containers when I noticed something odd. After loading the MySQL Connector and starting it all up, JIRA Setup kept telling me that the database wasn’t empty. I could see that it was, and per advice from a colleague, even double checked that the collations and char-sets were all correctly set.

Finally I isolated it down to the MySQL Connector. I had grabbed version 8.something, and Atlassian only supports version 5.1.48. And while this connector worked for JIRA 8.5.0, it apparently had some issues with JIRA 8.5.2 and 8.5.3.

This did get me thinking though. I went through the process of isolating the problem relatively quickly as I have had to do this fairly often in my career. But it isn’t the most intuitive thing to learn. So why not cover that this week!

Dev and Test

So, first thing: Friends don’t let Friends Test in Production. People are depending on that system being stable and there, and if you are mucking about in it constantly to “test” things, it will be anything but stable.

For all license tiers save the smallest, Atlassian also gives you an unlimited use Development License. And this is for both Apps and the main Applications. USE IT! If I.T. won’t give you another system, setup a VM on your desktop. IF they won’t let you use that, bring in an old PC from Home. There is no excuse for testing in production.

The most common setup I see is for a team to have two non-production instances of each platform: Test and Dev. Dev is your personal instance. This is where you can make changes to your hearts content, bring it up and down, upgrade it, reset it, whatever as much as you want. Break it? Won’t impact anything, and just refresh from Production. This is usually where I test “I wonder what will happen if I do this?” at.

Test, on the other hand, is your public non-production instance. You want to let a user test the functionality of a new App before purchasing it? Goes in Test. A user wants to add a new field? Put it in test and let them see what it looks like first. I usually like to refresh this from production on every JIRA Upgrade, but will do it sooner if we’ve made any big changes in production.

As a best practice, I also like to change the color scheme of JIRA for each instance, so you can identify which is which on site. My usual color scheme is to have the top bar be orange for Test, and Red for Dev. A few other things I do:

  • Separate out each instance to a separate DB Server
  • Make sure that if a given non-production server tries to talk to Production, it’s rerouted to the appropriate non-production instance instead. Often using /etc/hosts file.
  • DISABLE THE OUTGOING EMAIL SERVER

I definitely recommend you have both available. If you are only limited to one due to policy or budget, at least have a test instance. Your production instance will thank you.

But what about a non-production site for JIRA Cloud?

Okay – so I haven’t had to deal with this too often. BUT, you are also not the first person to ask, dear reader. Atlassian has a document actually outlining a few options you have to setting up non-production Atlassian cloud instances.

Take a snapshot and/or backup before changing anything

Before trying to figure out a problem or making a change, give yourself a way to get back to a pre-test state. If your instance (DB and all) is on a single VM, take a snapshot of the VM before starting. IF not, Take a tarball of your install and home directory, and while those are running take a database dump from your DB. Heck, if you can, take a file backup and a VM snapshot, do both!

Before I have your ESXI admins after me with torches and pitchforks, I should note here. The way I understand it, a snapshot setups up a way for ESXI to journal all the changes made to a system within a file, and revert back those changes. That means the longer a snapshot sits on a system, the larger it becomes. So always go back and remove a snapshot after you finish your testing. At the very least, it keeps things from getting messy.

This doesn’t only extend to a whole system. If you are changing a single file, make a copy of it first. That way you can go back to the file before you made any changes should the change prove catastrophic. The goal here is no matter what you are doing, always give yourself a path back to before you did it.

Isolate and make only one change at a time

This is probably the most challenging part of testing. For each run you do, you need to make only one change at a time. But what do I mean by change? Do I mean you should upgrade by changing one file at a time? Of course not!

The purpose of this is to isolate something enough to know what fixes or breaks it. So if you are doing a full upgrade, start by upgrading JIRA. Then check to see that it still runs as expected. Then make your changes to setenv.sh. Check again. Then server.xml. Then check again. Then upgrade the apps. Check again.

In the example I gave in the intro, here’s the changes I made each run when I found there was a problem with the DB:

  1. Drop and Re-Setup the Database using a GUI Tool
  2. Drop and Re-Setup the Database from command line.
  3. Try a MySQL 5.7 DB instead of a MySQL 5.6 DB
  4. Try JIRA 8.5.2 instead of JIRA 8.5.3
  5. Try JIRA 8.5.2 with MySQL 5.6 instead of MySQL 5.7
  6. Try JIRA 8.5.2, MySQL 5.6, with a different MySQL Connector – FIXED!

So you can see how each step I only changed one item. Yeah, it took me six runs to find a solution, but I now know it was for sure the MySQL Connector.

Yes, this adds significant overhead of bringing down and restarting JIRA each run. BUT – if and when something does break, you will know it was only the last thing you did that broke it. Likewise if something fixes it, you also know it was the last thing you did that actually fixed it.

Keep track of the changes you’ve made to each instance since the last Refresh

This is a bit of practical advice. Somewhere (Confluence), you need to have a document that shows in what ways each non-production instance has been changed since the last time you refreshed it from production.

Add a field? Add that to the doc. User tested an App? Document it. The idea is to have a journal to show what you’ve done, so that if you need to refresh it while a user is still testing something, you know where to find those changes to restore them.

And I get it – documentation is evil. Why spend time writing what you are doing when you can be doing more. This something I struggle with too! But this is a case where an ounce of prevention is worth a pound of cure.

Practice good Change Management on Production!

So, you’ve tested something in dev, put it before users in test, and now you are ready to put it on Production now. Enough delays, right?

Slow down there, friend! Production is sacred, you shouldn’t just run in there with every change.

Change control/change management is a complex subject – and honestly – hasn’t always been my strong suit. But it’s meant to keep you as an admin from your worst impulses. Annoying at times, I’ll grant you, but still a good thing overall.

The best way I found is to setup a board made of up of your Power Users, other Admins, and various other stakeholders as needed. Have them meet every so often (every other week seems to be the sweet spot here). If you have the budget for it, make it a lunch meeting and provide food. You are much more likely to get people to show up if they get to eat.

Then go over every change you want to make and gather feedback. They might spot a problem with a use case you hadn’t considered. But be sure to get a vote on each change before the meeting is over. Trust me, if you don’t structure and control the meeting, they will talk each point to death.

As a note here, there should be an exception to putting changes through the board during an emergency. If production is down, your first priority should be getting it back online as soon as possible. Then you can have time to retroactively put it through the board. For all non-emergency changes though, the change board is the valve to what you want to put into production.

Strictly this is not part of testing, but considering all, I didn’t want you to run off thinking testing was the last step. As with everything JIRA, it all works best when it’s a process.

And that is it!

You are ready to do some testing in JIRA. With the advice above, you are ready to maintain your JIRA Instances responsibly – or at the very least give yourself a way out of any sticky situations you find yourself in.

Don’t forget to join us on Discord! https://discord.gg/mXuRsVu

Until next time, this is Rodney, asking “Have you updated your JIRA issues today?”

What’s new in JIRA 8.6

Okay, so not my most inspired topic…

Nor the most timely…

But I thought it’d be interesting to take a look at exactly what are the new features coming to Server and JDC versions of JIRA. If you are running Cloud, new features are pushed out on a CI/CD style pipeline, so you often get the cool new features first. The rest of us have to wait for it to come out in a discreet release.

When I’m planning an upgrade, I’ll often scour the Release notes for all the new versions to select my target for the upgrade. Of course, when possible, I prefer an Enterprise Release, but sometimes either a feature in a future version is too-good to pass up, or a feature or change in an Enterprise Release will break something that my teams depend on. Usually fixing this will take more time than I have to give it, so I’ll settle for a lower version.

I’ll also take notes on these new features between the current and target versions of JIRA, and pull the ones I think users will be most excited for to send out in an announcement email.

But you shouldn’t wait until you are upgrading to check the release notes. I normally like to check them on Monday and read about any new versions that came out the previous week. That is, I like to do this when it’s not the holiday season and I’m just trying to keep up.

So where’s the Docs at?

You can find the release notes for JIRA within the JIRA Support KB. Each instance of JIRA (Software, Core, and Service Desk) will have it’s own page. On each page, it will have a list of all release notes broken down by their Feature Version number (That is the second number in Atlassian’s 3 digit version number). Going to each feature release will break it down further by bug releases.

For the purposes of this post, I’ll be focusing on JIRA Core, as changes there will be common to all instance. The pages listed will also include upgrade notes, which will have information and gotcha’s involved with upgrading from a previous version of JIRA

So, what’s new?

JIRA Copies over changed files when upgrading.

So – one of the biggest changes is something that has always been a pain when upgrading. In the past, when JIRA Upgrades, the installer will just erase the install directory and replace it with the new version. It would at least tell you what files changed during the upgrade so you can manually back them up. But that means you have to stop in the middle of the upgrade, open a new window, and back them up before proceeding, No Buenos.

Staring in version 8.6, however, the Installer will detect these changed files and copy them to the new install directory. While this is easier, it could lead to problems. Sometimes there are critical changes that will be squashed by doing this. I’m hoping Atlassian has thought of this and will just copy over the changed parts – but this would need some testing. I’d add this to my test routine for this specific version to figure out exactly how it behaves and plan accordingly

New JVM Code Cache Check

So…this one is a long time coming. Previously as your instance grows, you might hit a point where it just suddenly slows down. If you restart the JVM, it would seem fine for a bit, then slow down again. One factor leading to this is a setting for the JVM called the code cache. If you are using an older setenv.(bat|sh), this wasn’t always set appropriately, but won’t show up as a problem until you reach a certain scale. I know this because I’ve dealt with this.

Now the Health check will include a check for this setting, meaning you won’t have to figure this out on your own (or with help from Atlassian Support). This one is a win!

Users and Roles made better

So this one I’m on the fence on. Looks like they updated the Roles page on a project.

Image courtesy Atlassian Support KB

Rather than list users per role, it now lists all users, then what roles they belong to. This will solve the problem where not all users will show up on first load “to save space”, but it will be an adjustment and require some updates to end-user docs.

Supported Platform Changes

Atlassian has also updated some of the platforms they are supporting. I know at least one of these will impact some of my test systems. First off, they are adding support for the following database:

  • PostgreSQL 10

At the same time, they are deprecating the following:

  • PostgreSQL 9.4
  • PostgreSQL 9.5
  • SQL Server 2012
  • SQL Server 2014
  • Oracle 12c R1
  • Solaris
  • MySQL 5.6

These will still work with 8.6, but you will receive a warning about them. They plan to remove support entirely in JIRA 8.8 for all but MySQL 5.6 and SQL Server 2014, which will lose support in JIRA 8.10

As a side note, this also means we can expect a JIRA 8.10

Prefix and Suffix Search

In JIRA 8.0, they added a much needed feature that would allow us to do a wildcard search on text fields when preceded by as known string:

text ~ "Harry*"

This is great and all, but it only seemed to be half the job. In JIRA 8.6, they did the other half, which is allowing a suffix search

text ~ "*Potter"

My question here is will they allow both to be done at the same time, such as:

text ~ "*James*"

While I don’t see why not, it’s also not explicitly called out in the document, so maybe? I’d still like to test this out myself.

Accessible Dropdown Menus

So – I had this user one time. He seemed to not be able to remember *anything*. For example, he’d complain almost weekly that he couldn’t find some option on the “More” drop down menu. I’d remind him (again) that he may have to scroll down on the page to see every option, to which he’d go “Oh yeah, you told me that last week.” And he’d be good for another week or so.

Image courtesy Atlassian Support KB

This change was made for him. Now, when this menu is longer than the viewable screen, that menu itself will be able to be scrolled down. Of course, given this user, he’d still likely forget this – but at least it’s something.

And there’s more (If you run Data Center)!

There are three more features on this release, but they are exclusive to Data Center. They are:

  • API Rate Limiting: You can limit how much a given API integration can hammer your JIRA Instance, preventing that integration from bringing your whole instance to a crawl.
  • Improved Audit Log: They’ve added some new items to the Audit log. Be nice if they had done it for everyone, and not just Data Center, but it’s a step in the right direction, at least.
  • Cluster Monitoring: This one I don’t mind being DC only, as it really only impacts this type of instance. They’ve expanded the Atlassian Cluster Monitoring plugin to not only be included with Crowd and Confluence DC installs, but JIRA as well.

And That’s 8.6, in a nutshell

So, what did you think? Is this kind of breakdown for new JIRA issues helpful? Let me know!

Don’t forget to join our Atlassian Discord group here: https://discord.gg/mXuRsVu

But that’s it for this week, so until next time, this is Rodney, asking “Have you updated your JIRA Issues today?”

App Review: Botron Power Admin

So, Confession time…

This was going to be my Christmas day 2019 post. But – it wasn’t ready in time, and making it ready would have meant not spending time with my family. And family is always more important. So, I chose to delay it until today.

This also represents something new I am trying…well, actually a few things new. So let me know in the comments here or on LinkedIn what you think of it? Would you like more like this? Do you have any favorites you think need attention? I’d love to hear from you.

So then, I’ll be looking at a new(ish) app that I recently learned about from an ACE event in Atlanta last month. It solves a problem that has frustrated me many a times, and one I imagine you’ve dealt with too.

Now I should note here that this is a review of a app (or plugin if you are old-school like me). I have not received any sort of monetary compensation for this post, and they don’t even know I’m doing this. I did get a T-shirt and a few small plushies at the ACE Event, but that was swag we all got there. However, I do think I should be upfront an honest about that. In the end I think this app solves a big problem I’ve always had, and want you to at least try it out.

That being said, he is cute!

The Problem

So, imagine this. You are in a meeting, reviewing some configuration changes you want to make to a field, and a stakeholder asks this dreaded question:

So, where exactly is this field used, anyways?

Every stakeholder, every time.

Well, there goes your afternoon. This is not something that is easy to answer in vanilla JIRA. Yeah, you can see what projects it’s “Used” in…but that’s only if it happens to appear on a screen associated with that project. That leaves out workflow transitions, filters, and dashboards – the last two of which you may not get a clear understanding of, ever.

You are now doomed to check workflows, popular dashboards, etc. and hope you catch them all. And inevitably you will miss one, and that user is going to complain that they “Should have been notified about the change!*”, even though they used it in a private filter that you cannot see.

*technically, you should notify on all changes you plan to make in production, but this doesn’t always happen.

And this problem isn’t limited to just Custom Fields, though that’s the example I chose. It could be your boss asking, “How many people are really using this expensive plugin?” come renewal time. Or making sure a status name change you are about to make will only impact those you intend to. Or see which workflows are using a screen you need to change.

Finally, a solution

For the longest time, my best answer was to do about a half-day’s to a full day’s research, and try to find where all it’s being used. In a perfect world all of this would be documented, but that doesn’t always happen either. Sometimes we just get too busy doing to write up what we are doing.

Thankfully this isn’t an uncommon problem, and we finally have a tool in our tool-belt to find an answer quickly: Power Admin by Botron.

As I said, I found out about this when Peter Toudjarski from Botron came to speak at an Atlassian ACE event in Atlanta last month. You really should consider going to your local ACE Events if you can. I’ve been doing the admin thing for years and I still manage to learn something from my colleagues each time I go.

That aside, this app blew my mind when I saw what it can do. It solves a gripe I’ve had that I wasn’t even aware of. Lets take the above example: Finding out where a custom field is used. I’ll go to my test instance, and look up “Company”

I really should remove that terrible theme…it’s after the New Years already!

From the quick search, I can see that it is used in one project. So what? Now watch as I click on “Company” in the search results.

Boom.

There you go. Every board, dashboard, and screen that custom field appears on. It will even catch workflows where applicable! That afternoon it would take previously? Now you can answer that question while you are still in the meeting!

And this isn’t limited to custom fields!

Now – this isn’t fool proof. It’s still up to you to interpret the result. For example, here is my returns for App:

So I can remove all plugins because they are used in no projects right? Eh…no. But it is far more insight than we were able to have previously.

What I wish it did better…

Now, I don’t have to tell you I’m already in love with this app. However, that is not to say it is perfect.

In custom fields for example, I’d love it to tell me what percent of issues in the projects a field is used are populated. Bonus points if it can give this to me as a report across all fields in JIRA.

Another area is Apps. Yeah – I actually had to defend this app to a co-worker who joked that because the Atlassian Troubleshooting and Support Tools were unused in all projects, it’s a candidate for removal. I think every experienced JIRA Admin knows this is a joke, but I can see how a new JIRA Admin could see that result and legitimately think that.

And as one last note, This is not available for JIRA Cloud. This relies on some low-level JIRA calls that don’t exist in the Atlassian cloud products. According to Peter, they are looking at some things now that Atlassian has added Forge to Cloud, which may let them get this kind of access, but they don’t want to rush something out the door until they know it’s good.

But that being said, for the price, this is invaluable knowledge on Server and Data Center instances.

About that price thing….

This is the part where you are expecting me to tell you it’s expensive. I mean, any JIRA Admin who’s been at this more than a year knows Apps can get expensive fast.

Well…..about that…

As of the time of this writing….

It’s free. Yes, Free as in beer. You can add this to your JIRA Server and Data Center instance today at no cost. I don’t know if and when it will become paid, so I’d scoop it up while I can.

Okay, you can hate me now.

I deserve that one. But it’s rare we get an app of this quality that is free, so I had to.

So, what do you think of this app? Personally, I think it deserves more attention, hence why I’m writing this post about it. As I’ve stated previously, this just saves so much time.

And now, for something else new!

As you may remember, I really started posting regularly to this blog after being in a position where I had lost my job. If I’m being honest, I had just ended a rough week in the job hunt and was looking to prove I still had “it”, both to myself and to potential employees.

Considering the blogs “real” start then, I’ve been thinking of a way to give back to others who may be in the same situation I was in. And this was the frame of mind I was in when I was contacted by someone asking if I knew of any remote Atlassian Administrator opportunities. So why not feature them on the blog!

On that note, I’d like to introduce you to John Fry, who is looking for a remote Atlassian Administrator role. He has been working as an Administrator of Atlassian Tooling since 2016, but has a further 5 year’s experience in System Maintenance and Administration. He is also ACP certified with his ACP-JA (ACP-100) and AC-JPA (ACP-600). He also has experience with the following supporting architectures:

  • Linux
  • Windows Server
  • AWS EC2
  • VMware VSphere
  • Ansible
  • MySQL
  • PostgreSQL

For a full listing of his qualifications, I’d refer you to his resume below:

And if he looks like someone you’d be interested in having on your team, please reach out to him on LinkedIn. I know he’d be happy to speak with you!

I don’t think at this time I’ll do a job hunter feature in every post, but it’s something that I’d like to do every now and again. Just another way to give back to the wonderful Atlassian Community!

In speaking of Communities

So, last week I happen upon a post in the JIRA subreddit asking about an Atlassian chat – someplace people can go to chat or ask questions that’s not a threaded forum style like Atlassian Community. Someone posted a slack link, but no way to get into the slack, and I had found a discord server. However – the discord option appeared to be all but dead. NO literally, the only admin had not logged on in so long that his account was deleted.

So, I did what any sane* person does, and start my own! Come hang out, ask questions, talk with other Atlassian admins, and see what’s up!

https://discord.gg/mXuRsVu

But until next time, my name is Rodney, asking “Have you updated your JIRA Issues today?”

*may be using a loose definition

A JIRA Guy’s New Years Resolutions

HAPPY NEW YEARS! I hope you had a good 2019 and look forward to a great 2020!

As you know, 2019 was at times….rocky, but all in all it wasn’t terrible. This blog has been one of the bright spots, actually! Hearing from readers out there about how much they are getting from the blog really just makes my day every time!

Where I live, it is a tradition that we resolve to improve at least one aspect about ourselves over the new year. So, that got me thinking, as JIRA Admins, what can we resolve to improve about how we work and how we run our instances. So without further adieu, here we go!

I resolve to not make any config changes without notifying all users first.

This one is easier said than done. But this one will save you so much headache in avoiding unexpected impacts from a change.

The challenge here is there are a lot of changes that you think will have no impact on user experience, and it’s tempting to just rush in and change it. Especially when explaining what you are changing and why feels like writing a light novel. I know, I’ve been guilty here too!

But giving yourself a chance to pause to explain what you are doing and why you are doing it will give both you and your users some perspective. If you are having trouble stating why you are making a change in a way that normal users can understand, do you really understand the change you are about to make? And if that’s the case, why are you making a change you don’t fully understand?

Now another thing here is this requires some lead time. If you send out a rushed email than immediately make a change, you haven’t really notified anyone. It’s the giving it time for users to digest the information and send in the feedback that will show the true power of this resolution.

I resolve to clean up Custom Fields from JIRA.

I see this one all too often. JIRA went through a “wild west” period where either a) all user requests for new fields were automatically stamped “Approved”, or b) everyone had admin rights and just added fields without a care in the world. It’s nothing to be ashamed off, but it is something you should resolve to fix, as an over-abundance of custom fields can cause system performance problems.

Now I’m not going to lie, this is a political quagmire if ever there were one. Users LOVE their custom fields, especially Project Managers. So if it were me, I’d start with the low hanging fruit. In this case, that would be duplicate fields. This one is easy for users to see why it can be a problem. Try doing a JQL search on a field that shares it’s name with another. Which field is which? Which has the data you need? Who knows!?

This does lead to the problem of what to do with the information contained in whichever copy you are getting rid of. Not going to lie, that is not an easy question to answer in Vanilla JIRA, and rightfully deserves a post all it’s own. However, the ever helpful folks at Atlassian Community has a few pointers to get you started.

If you manage to clean up those fields, then comes the next easiest category: Those that are “close” to each other in purpose or meaning. For example, lets say you have the following list of fields:

  • Dev Customer
  • Customer
  • Customer (Accounting)
  • UX Customer
  • Customer Number
  • Customer ID

You now have six fields, which all contain essentially the same kind of information. In an ideal case, any custom field you create should be “generic” – that is to say it should be general enough you can drop it in any project where it’s needed and it makes sense. In this case, I’d work with five of these groups and migrate them all to use the “Customer” field. It’s generic enough that the meaning can be used for all of these applications, and gets rid of five fields in one go.

I resolve to gain and/or regain control of my JIRA instance.

So this one isn’t as universally applicable, but for those of you dealing with it, it can be a hassle. You do the work, get things cleaned up in JIRA and the system working smoothly, just to have some guy – who lets be honest should NOT have JIRA Admin rights – come in, create 20 new projects with 40 new fields.

It’s a story that does happen. That is why you should strive to regain control over your instance, and be the gate-keeper for any such changes. Do you really need 20 projects, or because they are all short lived, could you do with one and utilize Versions/Releases to organize that work?

Now, I’m not going to say this will be easy. Anybody with JIRA Admin rights that aren’t you might have some clout – or at least the ability to complain very loudly to the right people. You will need to defend your decision to take away their rights by showing how the changes they are making are not following best practices, and are actually having a detrimental affect on the instance. But remember, YOU are the JIRA Admin. The health of the instance is ultimately your job, so state that clearly. And remind them that you are open to requests, but you will guide the discussion to something that is better for both the users and the platform.

I resolve to make myself as much of a priority as my systems.

I get it. Your teams and users depend on you to keep the system running and updated. You know what makes it easier to depend on you? Not burning out.

I’ll see it on reddit from time to time where a Sysadmin has passed away from a heart attack, or otherwise burned out and is switching careers. They are always the type who hardly ever took vacation, never took personal days, and felt like the weight of the company is on their shoulders. I’m telling you now – don’t be that guy. I mean I play around with these systems for fun in my spare time, and I still have to unplug every once and a while!

So if this sounds like you, just relax. And if you are at a company that would fire you for taking a few days off every now and again, you’re at the wrong company! Every company should be concerned about burn out, and if they aren’t that isn’t a healthy environment, and you should start looking now for a better year ahead.

Again, Happy New Years!

So, what are your JIRA Admin Resolutions? Are you doing one of the ones I listed here, or are you doing something different! Please let me know. Next week I’ll be reviewing a app (or plugin for us curmudgeons) that literally blew my mind when I saw what it could do. But until then, I hope you have a great start to 2020! I’m Rodney, asking, “Have you updated your JIRA Issues today tomorrow?” Happy New Years Everyone!