A look at JIRA Software 8.7…and Service Desk 4.7 too!

So it’s that time again. And this time only two weeks behind!

Atlassian released JIRA Core and Software 8.7, as well as JIRA Service Desk 4.7, a few weeks ago. Unlike JIRA 8.6, this only only has a few new features, with most of them relegated to JIRA Service Desk, but I figured I’d take a look at them all the same.

As I mentioned in my last release review, JIRA Server and Data Center are released in discrete releases. As an admin, you should always review each one. Even if you are staying on Enterprise Releases, it will give you ideas of what features to look forward to and promote when you do your next upgrade.

If this release has a theme, I feel it is Privacy and Security. Almost every new feature touches on one of these two ideas in one way or another. There is only a few new features in JIRA Software and Core, with Service Desk having more. So we’ll cover all the universal new features, then go over what’s new in Service Desk.

GDPR Anonymizing

I’ll admit, other than some audit headaches, GDPR hasn’t impacted me too much. However, I’m still a fan of the rules and are hoping something similar is adopted over here in the United States.

However, for those of you who are subject to GDPR Rules, Atlassian is helping you out. You can now anonymize any information tied to a user that can identify them upon request. This is a one way process, with no way to undo it, but that is kind of the point.

Courtesy Atlassian Knowledge Base

Included is a wizard that will search that user, show you any items in JRIA that stores that user’s personal information, then let you Anonymize them. Honestly, it looks great and it’s one less headache at my next audit, so I like this one!

PostgreSQL 11 Support

This one is big. As you may know, Atlassian products can run on a number of Database architectures. However, what you may not know is that they run best on PostgreSQL. Now I’m personally still partial to MySQL, but when it comes to getting every bit of performance I can out of these applications, knowing that I have this as an option is always nice.

However, until JIRA 8.7, the most recent PostgreSQL supported was PostgreSQL 10, and the only PostgreSQL 9 with continuing support being 9.6. So it’s always nice to have them add another version in. Now here’s hoping they can get around to MySQL 8 before 5.7 is end of life’d.

OpenID Connect for Data Center

And a feature coming to Data Center instances with this release is OpenID Connect. This gives you another tool to connect with various Identity Providers. Another arrow in the quiver when trying to integrate JIRA is always appreciated.

However, for JIRA Core and Software, these are all the new features. However there was a number of bugs also fixed, so that might also be something you will look at when determining if a particular version is right for you.

New Service Desk Features

Keeping your requests Private

The first new Service Desk feature is really a change to a default option. As of Service Desk 4.7, any request made through the Customer portal is Private by default. You can choose to share them with people in your organization, but if you don’t change any settings, it will be private.

Image courtesy of Atlassian Knowledge Base

Requests originating from an email still is shared by default, but you as an admin now have the ability to change the default behavior within Administration > Applications > Jira Service Desk configuration.

Verifying Customer’s Email

For those of you who have enabled public signup through your customer portal, you can also add a step to have them verify their email address. This should make it easier to get in touch with your customers, as you’ll know that the email they signed up with actually belongs to them.

Agents are well…agents

This one has aggravated me. When commenting on issues or acting as an approver, your agents were treated as customers by JIRA. This would muck up all sorts of things, from SLA’s to automation – which was my headache. It could even confuse customers – which is the last thing you want. So they are changing it so agents are well…agents! Novel concept I know.

So….should I upgrade to this?

Well….That’s a whole big bag of “It Depends.” If you are not currently on an Enterprise release, it would be tempting to just get the latest bug fixes. But ultimately I think this question comes down to is the question, “Do I need the new features?” Some of you may see the GDPR features and go “Yes”. Others will be able to wait for the next Enterprise release. Ultimately it is up to you to look at the features and see if the value justifies the time it will take to do an upgrade cycle.

And that’s it for this week!

A bit of a shorter article this week, but it’s been a busy week. My wife and I are getting ready for a long weekend trip together, and I’ve still got a lot of getting ready to do.

As I told you guys last week, I recently helped out with the Q & A section of a webinar my company put on. Well, I also helped out on the write-up of the questions and their answers afterwards. So if you have some free time and want some good answers to questions people had about Atlassian Cloud, please check it out!

Don’t forget to subscribe below to get notified about new blog posts, and also about our Atlassian Discord Chat. While unofficial, it’s a good place to get help, discuss things, and connect with your fellow Atlassian Admins. https://discord.gg/mXuRsVu

But until next time, my name 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?”

Why you should care about Enterprise Releases

So, confession time. I normally like to have a post written in advance of a release so that I have time to go back to it with fresh eyes and edit it. This week however, I haven’t been able to figure out what to post. I originally thought about doing something around dressing up your instance for Halloween, but then I remembered something very, VERY important. I’m going to be brutally honest with both myself and you for a moment…

I am VERY terrible at web design…

This is perfectly alright. When I go to brand (or rebrand) a JIRA instance, I’ll usually reach out to Marketing or the website team, coordinate with them on color palette, and try out several variations. I’ve even been known to mock up a few palettes, put together a poll, and put it to a user vote. Your users have to use this platform every day. They should have some say in how it looks.

BUT – maybe this is not a lesson I’m qualified to write up…at least not yet. But this left me a day away from post time and no article. Then, while downloading a new version of JIRA for a test I was running, I noticed this:

A new JIRA release – but not just any kind of release – but an Enterprise Version.

So, why should I care about an Enterprise Release?

To understand this, first we need a bit of a history lesson.

While at VMware, we were fortunate enough to have both Atlassian TAMs and Premiere Support from Atlassian. I cannot speak highly enough of these teams – without them and learning from them, I don’t think I’d have gotten as far as I have as an Atlassian Admin.

One of the key benefits of Premiere Support is something called a Health Check. You would be able to submit your Support Zip to the team at Atlassian, and they’d take a look at it and see if there are any changes or tuning adjustments you can make to improve performance. This quickly allowed our instances to become some of the best maintained and performing instances inside VMware.

It became our policy to submit a health check prior to any upgrade we planned to make sure we were on a good footing. Often during our health check, Premiere Support and our TAMs would advise us of what they considered “Blessed” versions. That is, versions of their software that had undergone testing by Premiere Support and were considered stable enough to recommend to large enterprise clients.

Shortly before I left VMware, this concept morphed into an Enterprise version. This version was something of Atlassian’s take on Long Term Support versions. The plan is that any bugs will be backported to this Version.

What do you mean? Isn’t a version a version?

Eh – this gets sticky if you haven’t worked in software.

Software versions are something of a code. Lets take Atlassian’s releases. They often are encoded with three numbers separated by a period. For example: 8.5.0

The first number, Eight, in this is the Major or API Version number. In most software companies, they don’t increment this unless they have made major architectural changes – in lay mans terms that is to say they pretty much rewrote major parts of the code. That is why going from v1 to v2 is a big deal for them.

For Atlassian, a change in this number means they have made changes to either the underlying JAVA API or the REST API. When this changes is when I start worrying whether plugins or integrations will break. They can break on other releases, sure, but they are more likely to break when this changes.

The second number, five, is Feature Release Number. When this changes is usually when Atlassian will add new features to their products. This can sometimes either break or render obsolete plugins, but as I said that is more likely when the API Version changes. This is typically what I mean by version.

The third and final number, zero, is the Bug fix number. This is when Atlassian will fix bugs in their products, but add no new functionality. This is where the magic in Enterprise Releases comes in. For Enterprise releases, any bug fixes Atlassian makes for future versions that also affect the Enterprise Release, Atlassian will back port to the Enterprise Release. That is why most Atlassian releases will only get to a bug fix number of 3 or 4, but Enterprise releases will get to a bug fix number of 10 or 11.

This also gets to my advice about never installing software ending in Zero. These versions have not had a bug fix release yet, which means they are statistically more likely to have bugs than other versions. Don’t get me wrong, ALL software has bugs, but at least those not ending in zero have had some fixed.

Bug fix releases are also *generally* safer upgrades than Feature Releases or API Releases. That is to say, going from 8.5.0 to 8.5.1 is *generally* safer than going from 8.4.x to 8.5.0 or 7.6.6 to 8.5.0. HOWEVER, never trust things as infallible, and always test your upgrades in a pre-production environment.

But I’ve seen Atlassian back port security bugs to non Enterprise Releases? What’s up with that?

Yes, this is true. Some bugs are so insidious, so dangerous to security that Atlassian will do the work to back port them to as many versions as are still supported. You should always pay attention to Security Advisories and plan your upgrade cycles accordingly. But that being said, for an Enterprise Release you’re also going to get other bug fixes on top of the security ones, so why not go with that?

Is that the only benefit?

Not. Even. Close. Atlassian will also do performance testing on their Enterprise Releases, and tell you the result.

This can help you in your decisions around scaling and whether an upgrade is worth it. You might even be able to use this to sell the upgrade to your user base. I have yet to meet the user who didn’t appreciate a faster JIRA.

They also prepare an REST API Change log so if you are hopping from Enterprise Release to Enterprise Release, you can prepare your integrations for the upgrade that much easier

Also, to prevent you from going page by page to collect all the changes from previous versions, they also do a full change log between Enterprise releases here.

So, yeah, Enterprise Releases. They really are a good thing.

Every upgrade is a decision. Sometimes you have to have a new feature or bug fix and cannot wait until they next Enterprise Release to get it. It happens – I’ve been there. That being said, for the long term support you get, if you are limited on upgrade cycles, you don’t have a lot to lose by going with an Enterprise Release. So it’s definitely something to consider as you are going through the release notes to figure out a target version.

So for next week I’m still not sure what to write about either. However, I did have an interesting challenge on LinkedIn from last week’s post that I’m honestly considering…

That might be interesting. I still have the VM I did that on, so it might be a thing. Until then, My name is Rodney, asking “Having you updated your JIRA issues today?”