So this week has been an interesting one. Today’s post will be short. I know I promised you an article this week based on how you guys voted in last week’s poll, but you see…
Something came up.
After I got done with last week’s article, I went to have some testing done to find the root cause to some health problems I’ve been having. And well, we found the problem. It was bad enough that the doctor had me go to the ER.
What she found was a very large amount of fluid around my heart. As a result, I’ve unfortunately spent six days in the hospital. Because of where this fluid was, they couldn’t remove it the normal way, so I had to have surgery last Thursday, where they removed 600ml from around my heart! I don’t recommend that as recreational activity. So not fun…
It’s been almost a week now since the surgery, and I am recovering nicely. I cannot describe what it’s like to have that much fluid removed at once, but it was a definite difference I can feel. I’ve had a busy week trying to build back my strength and recover.
Which means, as much as I don’t want to disappoint you guys, I do need to be honest with you and say that I wasn’t able do a full article this week. I’m really am sorry – I was looking forward to this article too. But priorities are priorities.
I have opted to keep the poll open for another week though, so if you didn’t vote last week, you still have a chance!
However, some other news this week.
Look, at the point I was in the hospital, I had pretty much ruled out Summit this year. No way my doctors would let me travel so soon.
But that’s okay. Due to concerns about COVID-19, Atlassian has decided to cancel the in-person Summit this year and take it virtual instead.
the scariest thing about COVID-19 is that it looks like a JIRA ticket
While I had some surprises planned if I could attend, I cannot fault Atlassian for it’s overabundance of caution. To sign up for the now free virtual event, follow the link below.
So, this week appears to be the week of the unexpected. I do apologize for not having this week’s article ready, but one of my resolutions was to take care of myself, so here we are. Until next time, this is Rodney, asking “Have you updated your Jira Issues today?”
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?”
So last week we took a dive into upgrading JIRA Server. So naturally this week it stands to reason that we will go over it’s big brother, JIRA Data Center. To be fair, doing an upgrade in Data Center isn’t much different than in Server. There are minor changes though that take full advantage of Data Center’s architecture, and those are what we’ll be focusing on today. We can sit here jabbering about it for a while, or we could get into it.
Zero Downtime Upgrades
So one of JIRA Data Center’s super-powers is the ability to stay online and completely functional while you are doing an upgrade! Called “Zero Downtime Upgrades” by Atlassian, this is the technique we will review today.
This seemingly superhuman feat takes advantage of the fact that JIRA Data Center runs on multiple nodes. Zero Downtime Upgrades allows you to put JIRA in a special “upgrade mode”, which allows nodes to be on different versions, then only bring down one JIRA node at a time while you perform the update. After the upgrade, you take it out of “upgrade mode” and let it start humming along on it’s new version!
Here is the doc we will be following that explains the what and how of doing a Zero Downtime Upgrade:
So, just because Data Center has fancy features, doesn’t absolve you from your own responsibilities. You will still need to go out and research what version makes sense for your instance, make sure it won’t impact any Apps, make sure your support systems are still supported under the new version, etc.
And I shouldn’t have to say this (I mean, I’ve pretty much said it the past two weeks now), but it is on you to thoroughly test each upgrade before putting it into production. JIRA is not a system that protects you from yourself. That is on you to do.
Also, “Zero Downtime” does not mean “Zero Risk”. It is still on you to make sure you have a good backup of the shared home, the database, and each node prior to upgrading the system. Remember our rule of thumb with upgrades:
“ALWAYS give yourself a path back to before you changed anything.”
Entering Upgrade Mode
So, you’ve selected your version, have everything ready to go, but where do you start?
To Enter the mythical “Upgrade Mode”, Head on over to Applications -> JIRA upgrades in the admin section (or hit “g” twice, then type JIRA Upgrades into the search bar that pops up).
That DB Collation Error will be taken care of shortly….
Click the “Put JIRA into upgrade mode” button, and you are off!
Upgrading each node
After putting JIRA into Upgrade mode, it’s time to do each node. Depending on the number of nodes you have, this can take a long time. Just remember, for this to be truly zero downtime, at least one JIRA Node must be up at a time.
I should also point out that every JIRA node that is still up will be getting the load of the nodes that are down for the upgrade. To me, if you have the capacity, it makes sense to build out extra nodes before a JIRA upgrade to make sure that no single node becomes overloaded while some part of them are down.
I won’t bore you with how to do the upgrade on each node – because I already covered it last week. At this point you treat each node like an individual JIRA server, download the installer onto each one, upgrade that system, then make any filesystem changes you need to.
If you have any customization in the JIRA install directory, you will need to copy these over as well. Remember, you can backup and restore the modified file – but during an upgrade that does carry a chance of breaking that node. It’s always a better idea to make a diff between the old and new files, identify the differences from your edits, and apply those edits to the new version of the document.
As each node comes back up, test it by bypassing the proxy and going to it’s IP directly. If you have customizations, you will get the warning about that, but then it should pop up with it’s new version.
Also check back at the proxy (System -> System info) to make sure each node is connected back to the cluster after upgrading.
Complete this for all remaining nodes, then continue on.
After you’ve upgraded all nodes
Once you’ve completed the install for all JIRA nodes, go back to Applications -> JIRA upgrades in the admin section. Here you will see a new button lit up, “Run upgrade tasks”. Go ahead and click it.
This will do all the edits necessary to the Database and Shared Home to get you running fully on your new version. As this is an important step, DO NOT SKIP IT!
Once complete, this will take you out of “Upgrade Mode” and return JIRA to normal operation.
Take this time to do your normal tour of the health checks, Apps, and basic functionality to make sure it is all working as expected on every node. Once you are satisfied, you’re done! All without any end-user interruption!
And if something went very wrong?
Well, depending on when it went wrong, you’ll change what you do.
If you have entered upgrade mode, but have not modified any nodes yet, you have the option to cancel out of upgrade mode. No harm, no foul.
If you’ve already started working on a node – but have not brought any nodes online under the new version, simply restore that node to the previous version, then cancel out and go back to test.
If – however – you do have nodes online under the new version, and want to back out fully to the old version, you are in for a bad day.
This is the point of no return for the upgrade, which means in order to return, you are going to have to bring the whole cluster down. Afterwards, you will need to restore the database, restore the shared home, and then restore each and every node that is running a new version. Then you can bring your cluster back online. Then write an email to all stakeholders explaining why you just brought JIRA down when they weren’t expecting it.
And this is why I keep telling you to test until you are confident. It won’t catch everything, but it will catch far more than not testing.
So, Listen – we have, like, a lot of nodes. Like, A LOT.
So, you are wondering if you can automate this on nodes somehow. Well….
You can automate a JIRA upgrade using tools like Ansible, Salt, etc. I actually have an Ansible job running of my Jenkins (sorry, no Bamboo here) which keeps my personal Confluence up to date without me having to upgrade it every time. However, I do not recommend you do this for production.
Atlassian is changing things all the time, and they don’t always get into the nitty gritty of what they are changing. That Confluence Upgrade job in Ansible I mentioned? It was actually broken for four months because Atlassian changed the URL you download from, and Ansible couldn’t make sense of the redirect, and I didn’t have time to debug it.
Humans are much better to adapting to these small changes. That’s why I prefer to always keep a human somewhere in the loop for a production upgrade on each node.
But, if that doesn’t dissuade you, I guess I can’t stop you. Just know I won’t be the one to tell you how to do it, just that it can be done.
And that’s Upgrading JIRA Data Center!
I hope you got something useful out of this guide. I think I’m done with upgrades for a while though – between work and the blog, I’ve upgraded 5 nodes across 4 instances in the past two weeks. So yeah – we’ll be covering something new next week.
Don’t forget to hop onto our discord community! There you can chat with fellow Atlassian Admins, get help, and see what’s new! https://discord.gg/mXuRsVu
And until next time, this is Rodney, asking “Have you updated your JIRA issues today?”
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.
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?
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?”
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!
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?”
