Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Google Podcasts | RSS
In This Episode
In the final part three of this three-part mini-series, we talk about building your own Atlassian App (high level).
** This episode was recorded in advance. Plugins/Add-ons are now called Apps.
Products
This episode focuses on the following products:
- All products.
Links
- Rise of the SPI (Article)
- Codegeist
- Community – Codegeist 2017 Winners
- Developers.Atlassian
- REST API Browser | REST API Browser App
- Atlassian Connect
Episode Credits
This episode is hosted, produced, and music by Mark W.
Disclaimer
All thoughts, comments, tips, and best practices shared by the host and or guests of the Admins of Atlassian Podcast do not reflect the views of Atlassian nor do they replace procedures and steps officially provided in the Atlassian product documentation.
Transcript
We are in the home stretch of this 3 part mini-series about plugins. We talked about evaluating plugins and things you can look for in episode 8, followed by a deeper discussion about what Atlassian Verified Plugins are in Episode 9.
But what if you can’t find anything that meets your needs? What if you decide that you want to roll up your sleeves and code?
I am your host Mark Williams and coming up, we talk about custom plugins and how you can get started.
Source
In the early days, Atlassian made the source code available so that developers could hack away at adding new features and functionality to the app. Some of these changes made its away back to application as a standard feature. From this, the idea of a marketplace grew.
If you are a license holder, you may or may not know that you can get access to a products source code so that you can develop against it internally. Pretty cool, right?
Even better, you download the Atlassian SDK and begin to set up your development environment to start building the plugin that will solve your needs.
But before you start configuring IntelliJ and going through the developer documentation, you should make sure that developing your own plugin is the right step for you.
To start this series off, we talked about evaluating plugins and gathering requirements. Whether looking for a plugin to add functionality or building your own, this is an important step to help you understand if the application actually has the functionality itself, or that you are not trying to automate over a bad process.
Does It Already Exist?
A second point of interest, which has not been mentioned previously, is to check Atlassian’s public issue tracker. I can’t tell you how painful it would be to start and complete development of a plugin or extended functionality only to find that the particular functionality you added, is coming in an upgrade, or is already available on the marketplace.
Now, this is a challenge that a platform holder faces when developers can freely extend the functionality of the core application. It could be that your implementation adds something different or extra that may not be in the official release, or maybe your solutions solve something entirely specific to your needs as opposed to being generalized.
For example, in my days as a JIRA administrator, I would receive a lot of requests for plugins and added functionality. One such was a pretty small request, it was to add an original creator field to the JIRA issue and the search results screen.
I never actually investigated to see whether this was a requested feature, so I OK’d the development of this request.
The team toyed with the idea of a custom field plugin since we had experience doing so. We then shifted to using the Scripted Field from JIRA Script Runner plugin and also tested with using a Script Listener from the same plugin for the Created event, d populate a custom field with the user. Why test both methods? We wanted to see what the performance difference was between the two methods.
We chose our design, tested the change on lower platforms and set an implementation date and started drafting our announcement. One morning I checked my email and found that there was an update to a JIRA release notes page. As I read through, I saw mention of an original creator. It read that the creator of an issue is now recorded in the issue history.
After reading the JIRA 6.2 release notes, I terminated our implementation of the custom field and noted on our internal request issue that this would be available in version 6.2 of JIRA.
While a small example, and maybe a rare case, it hopefully shows that one must perform their due diligence to avoid unnecessary duplication of effort.
So, you have your requirements, and you know what you want to develop. Now it’s time to get started.
Your first option, depending on the requirements, is to choose the weapon that you will wield. Navigating through Developer.Atlassian.com, will showcase all that you can do for Cloud and for Server.
REST
With Cloud or Server installations, REST API calls are available for use. Often teams will use these to provide some quick one off functionality or automation of tasks within the tool. I’ve used it to bulk create users in JIRA for migrations, or to simply show issue data. To test against it, I’ve seen many use cURL calls to test the functionality. Whenever I needed to test a REST call, I used the app Postman. I personally like having a visual element to input the rest call and any data I am attempting to post.
Another tool that is very helpful is the REST API Browser plugin. This is an Atlassian Labs plugin, which means it is experimental and is unsupported. This plugin is available for JIRA Server, Confluence Server, Bamboo Server and Bitbucket Server. Sorry to all of my Cloud friends, there is no comparable offering for you that I can find.
What the REST API Browser does is allow you to search the API for the application. It will list the APIs that are available for you and you can search for keywords such as permission or user and you will see what APIs are available for you to use. You will also be provided documentation of the REST endpoint with examples that you can use. On top of that, you can even test the API calls against the app and view the output of the call.
Atlassian Connect for Cloud
Next up is Atlassian Connect. The Atlassian Connect framework allows you to build add-ons to extend the functionality in Atlassian Cloud applications such as JIRA, Confluence, Bitbucket and HipChat.
So, what is it? Atlassian Connect is essentially a web app that… you know what, check out this snippet from our Introduction video for Atlassian Connect:
<clip https://www.youtube.com/watch?v=rAskTn5ymJA >
That was from our March 2014 introduction video. The Atlassian Connector works by providing a descriptor to the Atlassian application to be seen as a plugin. With this, you can insert panels or custom fields into JIRA, macros in Confluence or even your own custom view and have it be seamlessly part of the application.
JAVA API
The last option is to use the JAVA Api for your respective application. Now, things get a little more heavy as you have to discern the classes and interfaces you’re using. While this is mostly used when building plugins, I’ve personally used the JIRA JAVA API through another plugin, that’s right, API inception. The Script Runner plugin uses the groovy language to allow you, the admin, to write scripts, or extend the java api, and that’s I did. Mind you, I didn’t write a full app, but it was very useful to perform small bite size pieces such as grabbing the current user or setting a field value based on a condition.
Wrap Up
That marks the end of this 3 part series where I shared tips in how I evaluated plugins. We talked about Atlassian verified plugins and what other options are available if you could not find the add-on you need. I hope that you were able to gain some info to make your life as an Admin, easier.
If you’ve enjoyed this episode, please be sure to subscribe through iTunes, Google Play Music, or your favorite podcast app.
Thanks for listening, cheers.
Leave a Reply