Created with Sketch.
The Admins of Atlassian Podcast
40 minutes | 3 years ago
E13 – Upgrade Best Practices
In This Episode In this episode, I bring on special guests Matt Shelton and Jennifer van Leeuwen to share some upgrade best practices that you can use to upgrade Jira, Confluence, Bitbucket and more! Products This episode focuses on the following products: All products Episode Credits This episode is hosted by Mark Williams, Jennifer van Leeuwen and Matt Shelton. The episode is 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. Show Notes & Links Welcome – 0:02 Guest Introductions – 1:16 Why upgrade? – 1:59 Upgrade cadence – 3:08 Supported Platforms – 5:25 Upgrade planning – 7:14 Staging & Test platform – 9:06 Data mirroring – 10:49 Testing steps – 14:40 Jira workbook tips – 16:17 Jira Strategy Workbook Testing external integrations – 17:54 Backups – 18:56 Focus and communication – 22:40 Upgrade schedule – 26:32 App/add-on upgrade – 27:51 Test apps/add-ons – 31:39 Create read-only instance – 33:26 Planning and disaster recovery – 35:07 Standard & Premier support – 36:14 Atlassian Support Offerings Atlassian partners – 38:17 Atlassian Partners Closing – 39:13 The post E13 – Upgrade Best Practices appeared first on The Admins of Atlassian Podcast.
3 minutes | 3 years ago
E12.5 – In The News
In This Episode A quick update on the latest Atlassian releases. Products This episode focuses on the following products: Jira Crowd Confluence Links Confluence 6.5 release notes Jira Core 7.6 release notes Jira Software 7.6 release notes Jira Service Desk 3.9 Release Notes Crowd 3.1 Release Notes 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. Blogscript In The News I hope everyone had a great Thanksgiving. There will not be a main topic episode this week, but I figured I would hop behind the mic and share some news with you. Confluence 6.5 Release Improvements made to database setup wizard for new administrators as well as refinements to the Confluence error startup page and indexing improvements for attachments. See Confluence 6.5 release notes. Jira Core & Jira Software 7.6 Release Finally! If you wanted schemes for Priorities, rejoice! No longer do you have to follow Low, Medium, and High priorities for your project. You can now create custom priorities and schemes and apply to one or many projects. Also in this release is the ability to drag and drop sub-tasks. You will no longer suffer the pain of hitting that arrow button thirteen times to get it to the top of the list. Check out the Jira Core 7.6 release notes and Jira Software 7.6 release notes for details and more. Jira Service Desk Server 3.9 This release includes improvements to canned responses that now allow you to add variables to your response templates such as the Jira issue key. See Jira Service Desk 3.9 Release Notes for details and more. Crowd 3.1 Release In Crowd 3.1, you can now automatically assign groups to an application. This is a big help to admins that want to add a bit more automation to their user login process. Also included in this release is support for Microsoft SQL 2016 and PostgreSQL 9.6. See Crowd 3.1 Release Notes. Closing And that’s it! Join me in two weeks as I will have an awesome episode where two special guests share their Upgrade Best Practices. Be sure to subscribe to the podcast on Apple Podcasts, Google Play Music, or through your favorite podcast app to be the first to listen when it drops. Until next time. The post E12.5 – In The News appeared first on The Admins of Atlassian Podcast.
8 minutes | 3 years ago
E12 – Ensnare Your Admins
In This Episode In this episode, I share how I made my Jira project and Confluence space admins part of my team. Products This episode focuses on the following products: Jira Confluence 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 Intro What exactly does ensnare your admins mean? When you are small, there is a level of support that can be done by you. I know every situation varies, but you may typically start out with creating a few JIRA projects or Confluence spaces. You’ll take some support requests when the unexpected happens. But overall, you are able to manage the level of work that needs to be done. As you grow, or even if you’re small, the activity of your instance increases, so does the requests for customizations and support requests from your users. When upgrades happen you find that you now have more to test. You’ve added apps or macros and they are in portions of the app you don’t use. You tell yourself, I don’t really need to test all of these projects. I don’t really need to check all of these spaces. Maybe you do, or maybe you don’t. But I needed help. When it was just myself and another administrating the app, we wished for more eyes. And so, we ensnared our admins. For JIRA and Confluence, you have a concept of Administrators. Or for accuracy, you have JIRA project administrators and Confluence Space administrators. You, as the supreme administrator, have created a JIRA project or a Confluence space and you’ve bestowed these chosen few to be the administrators of their respective space or project. In JIRA, this lets them manage the project roles, components, versions, and certain agile features under JIRA Software. For Confluence, they can manage the space permissions, look and feel, and more. These admins could also have a closer view of the work and the teams that are using JIRA and Confluence. So, why not bring them to your side? Here is what I’ve put forth when managing Confluence and JIRA: Administrator Requirements First, admins knew what they were signing up for. How? I told them! When I would receive a request for a JIRA project or Confluence space, I would always request a backup admin and I would then inform them that as administrator, they are now part of the Atlassian team. They were now an Admin of Atlassian. Right? OK, I had to say that. So, what did they do? What were the requirements? Training For Confluence, I did not roll this requirement out, but it was always on my list of things to do. I found with Confluence that many who were space administrators are power users already. For JIRA however, administrators were required to go through training. Yes. I had recorded a demo of all the administrator functions in JIRA detailing what an admin could and could not do. I detailed how components worked, how versions worked, roles, and shared tips and best practices. The recording was then wrapped into a section by section training video with a 10 question test at the end. Seriously. I wanted the project admins to be the first line of defense for user questions. For starters, they were already a lead person on their team or someone that their fellow co-workers went to. Often, they managed any customization requests such as workflow changes or custom fields, and they just knew their team’s process. So when something happened or didn’t look right, the users would go to their project or space admin and if it was something that they couldn’t figure out, that admin would then come to me. Therefore, having the project administrator trained helped immensely. Upgrades & Testing As my instances grew and more plugins were added as well as customization whether it was HTML to a Confluence Space, or custom workflows and scripts in JIRA, it became increasingly difficult to test. What I mean is that at some point with over 100 spaces or over 100 projects, I could not reach every corner and function of the customization to ensure it worked. And if the team members performing that upgrade, they may not be intimately aware of what the customization is supposed to do. Why? Well, I will dive into that in a future episode. When it came to upgrades, the Administrators were responsible to test their space or project and let me know if anything was out of order and then sign-off once their testing was completed while I tested the core functionality and other integration points. Administrators would then post questions or problems they found on a Confluence release notes page that I built. Most were usage questions and others were related to plugins or a bug that was encountered. What this did was give me more eyes in testing and upgrades. It allowed the Administrators to get a first look at the next version of the application. They could then confirm for themselves if a reported bug was resolved or not. And with having a hands-on experience with the new features and a new version of the app, they could better prepare their team for what was changing. Overall, it was a great way to keep our community of users involved in the process. Another way to do that was through evaluations. Evaluations One of the great things about the Atlassian products is the ability to extend the functionality. I talked about plugin evaluations and how I evaluated them in previous episodes though I wasn’t the only one to do so. When we received requests for plugins or customizations, we would place this on a lower platform to test. After my team evaluated the plugin and invited the requester to evaluate the plugin or customization, we sent out the invitation to all of our Administrators and invited them to test the plugin or customization as well and provide their feedback. As mentioned, doing this made our users feel involved and take ownership of the platform. Another reason for this was that just because 1 person requested a plugin for customization, didn’t mean that others didn’t have this need as well. Pulling the Administrators into this helped get their feedback and maybe more buy-in as some responded: “hey, this is exactly what I’ve been needing”. Closing So, what do you think? Do you think this is something you could use to keep your users engaged? Do you think this is a good way to extend your base of support? I’d love to know. Thanks for listening to this episode of Admins of Atlassian. I’m Mark Williams. If this is your first time and you like what you hear, subscribe to the podcast in Apple Podcasts, Google Play Music, or your favorite podcast app. Until next time The post E12 – Ensnare Your Admins appeared first on The Admins of Atlassian Podcast.
16 minutes | 3 years ago
E11 – Jira Project Structure
In This Episode In this episode, I share how I structured my Jira projects as a newbie admin and share tips that you can use when structuring your Jira data. Products This episode focuses on the following products: Jira Links What is a JIRA project? JIRA Project Types Jira applications and project types Jira Core overview Dev – Tutorial creating a project template Mark’s 2012 Community Question Bitbucket Server 5.5 Release Notes Confluence 6.5 Beta Release The Human side of scaling Jira Software 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 Intro I’m hunched over, boxed within the make-shift walls of my cubicle. Jira is installed on a spare machine backed into the corner of my cube. Each whir and click of the machine begs for more resources. I perk up at the email notification in the top right of my screen. It’s another email from a developer. Another request to use Jira. I log in to Jira and navigate to my projects screen. The scrolling doesn’t stop. There are projects upon projects. Each project correlates to a developers source repository and I keep being asked to create more. It has never been more apparent, that I need organization. I need a way to control this chaos. And so, I asked myself, and I asked the internet “What is a Jira project?” and “How do you define it?” JIRA Project Structure Welcome back, to another episode of the Admins of Atlassian podcast. Today’s topic is all about project structure and defining exactly what a project is or at least I share how I defined it for the Jira instance I administrated. I hope that by the end I would have given you some ideas or at least prompted you to think about how you’ve structured or will structure your Jira projects. When starting out, Jira was being used strictly by my development team. In the early pilot of Jira with developers, I simply set up a Jira project for whoever requested it and for whatever codebase it was for. This lead to many, many projects and I could see how quickly things could spiral out of control. And so, I began searching online, and I found that there was only 1 recommendation. That was to define the Jira project for however best your organization works. This was a given, but I needed to see HOW others did it. So, I kept digging online and I would ask others at Atlassian User Groups. What I found was that no one had a structure! I’m sure there were people out there that devised a structure for their Jira project organization but all that I found were others doing the same as me, chaos. Ultimately, I decided to ‘go with what I know’ and looked within for my much-needed answer and decided to structure my Jira projects based on how the code bases were set up. We were using Jira for bug tracking and later development, and support teams were interested in using it as well so I started with two categories in Jira; Development & Support. These categories would be what I would assign a new Jira project to. There was also the added benefit of being able to search by category as well if we needed to generate any stats. Next up were projects. Mark’s Project Structure First, the term projects in Jira confused many. In our world, projects meant development projects or a project to organize a cabinet. In Jira world, that wouldn’t apply. If I created a Jira project to match whatever project was active in the organization, you wouldn’t be able to find anything! I ultimately decided that Jira projects would be defined as an application, product suite, or service provider. Let’s break that down. Application First application. I would create a Jira project for each application. For example, if my application was Amazon, then I would have a Jira project called Amazon. So when developers worked out of the Amazon code base, they would tie their code commits against the issues from JIRA project Amazon. This would also mean that when releases for the Amazon code base occurred, there were no other dependencies. Everything was 1 for 1 in a sense. Everything you needed for the Amazon application existed in that singular JIRA project. But what if your code was modularized or its many different pieces made up a whole? That is when I would use the Product Suite definition. Product Suite A JIRA project for a product suite contained one too many applications. These were all tightly integrated. Maybe not in sharing the same code base but maybe sharing the same core and they also had interdependencies amongst each other. This meant that they shared the same release cycle as well. They weren’t released independently, you couldn’t release product a without product b. Because of this, I would create a JIRA project for the product suite. For example, I will have a JIRA project called Tesla Model S. This is not going to be a good analogy but hang in there with me. I have a JIRA project called Tesla Model S. Now, to build this car, lots of different components need to be built and then assembled together before I can ship the car, right? The wheels are designed and built. The seats are shaped and clothed, the windows are cut to specific measurements, the dashboard is inserted. The car goes down the line, each piece separately developed are then added to the whole. Ok, not a good analogy but I hope that puts into context of what I would call a product suite. Using the product suite concept not only helped reduce the number of projects that I had, but it made life easier for release managers or build engineers tracking changes. Because they shared the same JIRA project, we would use components to split out the application affected and the area of the app. The versions, because it was all released together, was used for them all, meaning one place to maintain components and versions. If the applications were split across 5 JIRA projects, then that will be 5 JIRA projects to maintain components and versions for searches and reports. Not to mention workflows and other project and issue type customizations that may have been needed. So, if it met the criteria, product suite was the best fit. Service Provider Lastly, there were the service providers. This generally referred to support and other non-development teams. If you received a request to complete a task, then you were a service provider. A lot of the requests were in a silo. There was no other related work done by other areas and often a particular team or department was solely responsible. In other times, multiple teams did the same work or touched the same piece of work. This became a great discovery process and some teams were ultimately consolidated to a singular support project in JIRA. What if you are not a support team and you are HR or Finance, or Marketing? A user isn’t submitting a request for you to complete a task, you’re defining your work and projects? It’s ok, this works as well. You can have a JIRA project for HR, for Finance, for Marketing, for Audit, for Internal Projects, it doesn’t end. The most important part is to look at your structure and ask, where does it fit. Is this now a new category of organization in JIRA? Mark’s Project Types Earlier I noted that I created two categories in JIRA, Development & Support. In my structure, Application and Product Suite fit into the Development section of my project categories while service provider varied. it could be Support or Finance. It was a great way to organize my JIRA projects but did I do anything more with it? Yes, I did. When JIRA projects were being requested, my team and I would ask all sorts of questions, the most important being “What and How will this project be used?” These questions helped us determine how it would fit within JIRA and depending on their response to other targeted questions, we would know if the project needed to follow a template. In JIRA we kept project templates. These were empty projects that were outfitted with the necessary workflow schemes, field config schemes, and screen schemes for that category of work. If it was a Development related project, then it received the Development Template. This ensured certain requirements were put in place such as how we handled or tracked for Bugs. If it was a Support project, then it was generally more lax or lacked any required configuration. It received the out-of-the-box workflows, screens, and field configurations. If it was support for development, again, it followed a strict workflow for certain issue types, and changes were limited. Having project types in this manner helped streamline project creation and configuration. I went from chaos to structure. What About Official JIRA Project Templates? But, what I just outlined to you was how I set up, defined, and organized my JIRA projects. This was all defined and massaged from the early days of JIRA 4.x to JIRA 6.x. What about JIRA, now? Over time, JIRA has been adding templates to its suite of functionality. This came from specifying a scrum template via the old Agile plugin to specifying if you were a business, software or service desk template. Each gave you differing underlying changes. Business Templates Let’s start with the business templates. You have three options: Task Management – The simplest template. You get a very basic workflow and screen here as the focus is on basic task management with a To Do and Done workflow status. Project Management – This adds an In Progress workflow status and a few more fields to the issue. This is intended for long-running issues with estimates. Process Management – This is t
10 minutes | 4 years ago
E10 – 404 App Not Found
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. The post E10 – 404 App Not Found appeared first on The Admins of Atlassian Podcast.
9 minutes | 4 years ago
E9 – Atlassian Verified Apps
In This Episode In part two of this three-part mini-series, we talk about Atlassian Verified Apps. ** Plugins/Add-ons are now called Apps. Products This episode focuses on the following products: All products. Links Plugins are now Apps – Community Verified Plugins Program Atlassian Supported Apps Bitbucket Server 5.4 Release Notes 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. Blogscript Wait, What Is This ‘Atlassian Verified’ You Speak Of? Built for the marketplace, the Atlassian Verified program is a set of Atlassian standards that vendors are held to as customers consume their products. These standards are in place to help apps gather traction, ensure timely support and vendor reliability. To become eligible for this program, vendors must submit an application and if approved, their apps will be marked with an ‘Atlassian Verified’ badge in the marketplace. See Atlassian Supported Apps. What Are The Requirements? Below is a table of requirements that a vendor must meet in order to apply and be approved for Atlassian Verified status. Requirement Details Sell at least one paid via Atlassian app The Verified program requirements apply to paid via Atlassian apps. You must sell at least one paid via Atlassian app to become a Verified Vendor. Your paid via Atlassian app versions are installed in at least 500 active instances At least 500 actively used product instances must report installation of your paid via Atlassian app versions. This is measured by the Universal Plugin Manager (UPM), which reports actively used host products (like Jira or Confluence) that have your apps installed. Provide documentation for all paid via Atlassian apps Provide a documentation URL for all paid via Atlassian apps. Provide a support URL for all paid via Atlassian apps Customers should be able to access your support URL and see a clear way to get support for your app — file a ticket, email your support team, or other ways to contact you. Your support URL should be hosted under your vendor name domain. Offer support at least 8 hours a day, 5 days a week in your local time zone for all paid via Atlassian apps Support hours can be any time, relative to your local timezone. Publish and adhere to an SLA statement Publish and adhere to a service level agreement (SLA) outlining your support and service level terms, available via URL. Your SLA should include: Support hours that match what you have listed on the Marketplace Holidays Response time expectations Use an issue tracker like Jira to resolve and track customer-reported bugs and feature requests, for all paid via Atlassian apps You don’t need to use an Atlassian product to track your issues, but some kind of tracker to keep on top of customer-reported bugs and improvement requests. Provide Atlassian with 24/7 emergency contact information Provide an email address and phone number to Atlassian just in case we need to contact you for emergency support issues, such as those involving customer data loss or downtime. This information will only be used by Atlassian and will not be shared with customers. If something goes wrong, we should be able to reach you via this contact information 24/7. This information will be verified when reviewing the application. Your site, Marketplace listing, and support documentation is available in English The documentation should be spell checked and easy to understand. See table and other requirements at Atlassian Verified Program. As you can see, a lot of the requirements are set to ensure that you have support and that you have somewhere to go if you have issues with your paid app. The requirements are designed so that when you purchase an Atlassian Verified app, you know that you are covered in the support department. Should Apps That Aren’t ‘Atlassian Verified’ Be Avoided? Of course not. There are tons upon tons of great apps in the marketplace and I encourage everyone to try and use what fills their need. Even so, the goal for many could very well be to become Atlassian Verified but they need YOU to give them a chance. This is where you can get in on the cutting floor to become instrumental to the developer and help them build their product if they are new, especially if no one else does what they do. When Should You Care About Verified Apps? This was a question I’ve received at Atlassian User Groups when users were trying to figure out what verified apps were and why or when they should care about it. The Small Team When you are a small team or you have a small instance such as JIRA, you may be more flexible with the apps you install or try out. This is fine. I’ve been there. You have a ravenous base of users and they want to see what else the product can do. Your first stop is to the Marketplace to see what’s out there. You find your app and install. Everyone now loves you and gives you pats on the back. You are now their favorite admin! The Enterprise As your instance grows and matures your perspective shifts. You will now become more critical of what apps your user’s request. You will now become more wary of what apps you install. You ask yourself “Is there documentation?”, “Is the documentation good?”, “What is their support like?” This is the point where many make the transition from being the hero to their users to being branded as “no fun.” When I made the switch, I was tightening my platform. I also needed to ensure that the apps that I was evaluating had good support behind it. And that is when I began to include Atlassian Verified as a recommendation in my evaluations. Why not a requirement? If I made it a requirement, there would be very beneficial apps that I would have had to pass on. While keeping it a recommendation, I was able to weigh the other requirements and needs of the app higher should they provide more value. In The News Before we go, here are some updates that you should be aware of. Bitbucket Server 5.4 has been released. In this new update, Webhooks has now been added. You can use Webhooks to integrate into other applications such as a build system to trigger new development builds once a commit is made. Now, you can make team member contribution easier. 5.4 allows you to add a markdown file to your repository. This file will include your guidelines on how to work in this repository. Such as links to your best practices or team members page. Lastly, the Support Tools plugin has been renamed to Atlassian Troubleshooting and Support tool. Please, be sure to check out the release notes in this episodes show notes at adminsofatlassian.com or the very app you’re listening to. Closing Thanks for listening to The Admins of Atlassians podcast, I am your host, Mark Williams. Be sure to check out the show notes for links to all the information I talked about. If you are new, be sure to subscribe to the podcast in your favorite podcast app, if you are on iTunes, be sure to leave a review. Tweet us @AdmnofAtlassian. Cheers The post E9 – Atlassian Verified Apps appeared first on The Admins of Atlassian Podcast.
11 minutes | 4 years ago
E8 – Evaluating Plugins
In This Episode In this three-part mini-series, we talk about how to evaluate plugins. Products This episode focuses on the following products: All products. Links Atlassian Marketplace Atlassian Community Verified Plugins Program 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 Intro You’re working away and a user reaches out to you and asks “Can JIRA do this?” or “I found this plugin to do this for Confluence. Can we install?” You go to Google, Atlassian Answers, or the Atlassian Marketplace to see if there is anything that matches the request of your user. And as you peruse the list of plugins available for your application, overwhelmed at all the amazing choices you have before you, you stop and ask yourself “Which one do I install?” In this 3 part mini-series, we are going to talk about plugins aka add-ons. We will discuss verified plugins, what they are, what to look for when evaluating plugins, and what you can do if you don’t find what you’re looking for. All this and more on Admins of Atlassian, I am your host Mark Williams and coming up first in this plugin mini-series “Choosing your plugins and what to look for”. <Intro Music> When I first started out managing Confluence and JIRA, I did what admins normally do, I found a plugin and installed it to Prod. I didn’t realize at the time that I was creating this view that all you had to do was ask, and I would install any plugin you requested. When listening to other admins at Atlassian Summit and Atlassian User Groups, everyone was doing the same. And this practice, which is so common in new installations, soon find itself coming to a halt as the system matures. So, what do you do when you find yourself tightening control over what plugins to install? And if you are new and have yet to install your first plugin, then this is the episode for you. After getting experience under my belt, whenever a user requests a plugin I counter with a question of my own “What are your requirements?” Requirements Now, this is a loaded question depending on your experience with JIRA, Confluence, or the Atlassian suite. Asking for the requirements, you are asking the user about what they want the application to do. From the user’s response, I move the request into two buckets – the first being application training and the second is further analysis. Application Training Why application training? Often times I would receive requests and it was functionality that the application already had. I then used this opportunity to bolster documentation and share functionality with users. This was also empowering to users as they learned something new, learned the application better, and was able to continue on without any roadblocks. Further Analysis For those that were not training moments, they fell into the further analysis bucket. This is where I would gather more detail on what the user was trying to do and what they expected the application to do. Based on the user’s response, we could move on to identifying a plugin to evaluate. For those that didn’t progress to a plugin, evaluation became identified as a process replacer. Process Replacer What is a process replacer? The second type of add-on requests was to try to fix a process or add a Band-Aid to a broken process. What I mean here is that a plugin is being requested to do something for the sake of doing it or because it has always been done that way. When I would migrate teams from other tools or non-existing tools to JIRA, I would get requests for plugins or requirements that JIRA had to do X. When I would ask why the answer was “because we’ve always done it this way”. If you dig deep enough, you will find that some processes are developed from a lack of functionality in another tool. For these users, I would tell them “You have a blank slate. You can make things simpler and easier. Let’s use it out of the box and then chat about what you believe is missing.” For some, it reverted back to training. Using the application out of the box satisfied their needs. The hands-on experience eliminated the perceived need for extra. For others, their requests morphed into something wildly different and mostly involved custom workflows as opposed to a custom add-on. For those that didn’t fit in either category of application training or process replacer, we then pulled up our sleeves and began our plugin evaluation. Plugin Evaluation What’s in a plugin evaluation? The easy answer? Whatever you require. To help get you started, here is what I did for plugin evaluations. Requirements First, requirements. We have to go back to the requirements. After the user’s request passes my sniff test I would create a Confluence page, for documentation, and a JIRA issue to track the work for doing the evaluation. At this step I would also cross compare other add-on requests to see if any of the requirements were the same if so, I would link the issues together and if an evaluation was performed, I would investigate our results. Marketplace & Community Next was the marketplace and Atlassian Answers (Community) search. I would look at the requirements and make a list of plugins that had that functionality. Once the list was compiled, I would take notes about each plugin. I would notate: Who was the developer? When did the development company start? When was the plugin first introduced? When was the last update? How often does the vendor update? What is their support like? What is their documentation like? What are the plugin reviews? What are the known outstanding issues of the plugin? Is it an Atlassian Verified plugin? This information helped me understand how long the plugin has been on the market, if the documentation is good, what users think, and how well it is supported. These were questions I developed over time as my user base in JIRA and Confluence grew. One bad plugin could make 4k people unhappy. Scheduling & Testing The next step was scheduling time to install each plugin on the Test platform for review. Once I defined the schedule, I would send this out to the person(s) that requested the plugin, along with JIRA Project Administrators or Confluence Space Admins. Why? These Admins were my first line of defense, and they knew their teams. It may have been possible that their team could have been struggling and just maybe, this plugin could help them out. So we made it a requirement to include our Admins in this type of activity. After the schedule has been built and shared, on install day, I would load the add-on to a development platform. I would spend 1 week testing the plugin from every aspect I could, along with basic JIRA or Confluence functionality. I would try to break it. I would compare the plugins features to that of my requirements and check off any that were met spot on and make notes of those that were close. After my testing was done, I would then look back over the plugin and make note of any changes to the UI. New menu’s, or drop-downs. This step was important as it determined HOW we would communicate to our users before they started asking “What’s this thing here? I’ve never seen it before.”. After the shakedown on the development platform was complete, I would promote it to the Test platform and then reach out to those that requested the plugin and our Admins for testing. The testers would add their feedback to a Confluence page about what they liked, didn’t like, and if it met their requirements or not. This process would be repeated for each plugin and the users would rank which plugin they liked better, and which was the easiest to use. Based on this feedback, along with all other gathered facts, my team would render a decision to purchase or pass. Closing It may seem like a bit much to simply pick and install a plugin, but I believe it really helps in understanding WHAT the users are trying to accomplish and to review all the offerings that is available to me. I believe that user feedback is essential for adoption and if my users agree that are particular plugin is easy to use, and satisfies their requirements, then they will be much better off and much more productive in their day-to-day. That’s it for this first part of the plugin mini-series. In part two, we talk about Atlassian Verified Plugins and what they are. Be sure to check out the release notes for this episode on AdminsofAtlassian.com for links to anything that I’ve discussed in this episode. If you are new to Admins of Atlassian podcast, be sure to check out our previous episodes and if you enjoyed this episode, be sure to subscribe on iTunes (Apple Podcasts), Google Play Music, or through your favorite podcast app. Thanks for listening, cheers. The post E8 – Evaluating Plugins appeared first on The Admins of Atlassian Podcast.
2 minutes | 4 years ago
In This Episode Admins of Atlassian Podcast is resuming and I quickly share where I’ve been. 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. The post Hello Again appeared first on The Admins of Atlassian Podcast.
12 minutes | 5 years ago
Episode 7 – JIRA License
Resources Balsamiq Licensing Atlassian Developer Market Pricing Blog Version Of Podcast Software licensing. This has always been an interesting topic. Some are simple, and some are overly complicated. How does JIRA, and the Atlassian landscape check out? The Dark Side Of Licensing I’ve supported applications in the past in which the licensing was overly complicated and, I believe, designed to nickel and dime the customer. Whenever there was a need to review the licensing and or consolidate the licenses, several people had to be involved to figure out what was what. You had seat licenses, concurrent licenses, named licenses, state licenses, local licenses, US licenses, global licenses, or international licenses. The ONLY difference was licenses dedicated to a specific user (seat, named) and concurrent licenses (released at timeout or exit of application by user). The others were designed with made-up scenarios of users existing within the United States. Or users existing internationally. Each cost more than the other. The kicker, for most systems, is that you took all these license keys and threw them into a single license server where they are pooled together. Therefore, you would have no idea what license type was really being used. Buying these software licenses often means that a procurement or other software purchasing, finance, team would work with the sales team for the product you were buying and haggle through contracts, upgrades, splits, you name it. Not a fun process at all. This process could take weeks as both go back and forth until they could come to an agreement on price. The Light Side Of Licensing Along came Atlassian. Bootstrapped for resources, they used the “shopping cart” method by allowing you to choose your license bundle type (10 users, 100 users, etc.) and then buying online with a credit card. No back and forth with contracts or haggling down the price. You paid the price that they set. For established companies, this is definitely a change from what they are used to. Even to this day, I explain that there are no sales people to butter-up for a lower price. The price is already low! For Atlassian products, they sell licenses based off their user tiers. Below is an example of the JIRA Software for server user tier pricing. For the server installation, this is a one time price that is paid and includes 1 year of support. Through Atlassian’s Marketplace, up to 3 years can be purchased. Maintenance is typically half the cost of your purchased license tier. What About Plugins? Good question. If you are looking to purchase plugins for your JIRA instance, such as Portfolio or Tempo timesheets, your plugin license tier MUST match your base JIRA license tier. This means that if you have a 2,000 user license for JIRA Software, your license tier for a JIRA plugin MUST be a 2,000 user tier. Plugins must match the base license tier. If you use other Atlassian products such as Bitbucket server OR Confluence, their license tiers DO NOT need to match your JIRA license tier. What About JIRA Applications? In E6, I talked about JIRA Core and JIRA Software. In it, I discussed how JIRA is now a platform with applications built on-top. Those applications being JIRA Core, JIRA Software and JIRA ServiceDesk. Their licensing is handled differently in that it appears that you can have mixed licensing models per your need. You can have 2,000 JIRA Core license bundle and also have a 500 JIRA Software license bundle. This is because the license to these applications is managed via JIRA groups. The Annoying Side Of Licensing With A Glimmer Of Hope While Atlassian has eliminated the hassle of haggling and other annoyances with purchasing software licenses, there is one that remains for them OR rather made apparent. This is the fact that the plugin license tier MUST match the base software license tier. Let’s use the JIRA Portfolio plugin as an example. If you have a 2,000 JIRA Software user license tier, that means you must buy the same tier for JIRA Portfolio plugin even if you will have less than 50 people using the Portfolio plugin. This licensing model creates two issues: Inflexibility in Marketplace licensing Inability to maintain access to certain plugins and functionality. If the Portfolio plugin doesn’t seem like a good fit, how about a plugin that simply adds post functions to workflows. How do you apply a license tier to something an end-user will never see nor interact with? Can Vendors Sell Their Own License? Why, yes! Yes, they can. One such vendor, that I’ve had experience with, is Balsamiq for Confluence. They provide their license via the Atlassian Marketplace and via their own website. The key difference is that if you purchase the licenses managed by the vendor themselves, you can buy a lower license tier that is closer to the actual count of users. Access for this plugin is then provided by a specific group in Confluence called “balsamiq-users”. This means that if you are not in the access group for Balsamiq, then you will never see the options to use the mockup editor. Overall Atlassian has made licensing their software easier, but there are still some hurdles from a consumer standpoint. With the explanation of how licensing works with JIRA Core and JIRA Software, the next question that I have received was “Do plugins work the same way now?” There does seem to be flexibility to have plugin licenses reside in a different tier if the vendor is the seller of the license. Though, as we see, if the license is purchased from the Atlassian Marketplace, that flexibility is lost due to how license management is handled via the tool. With the advent of JIRA Core and JIRA Software, could the foundational work be made to allow license flexibility in the plugin arena? If so, how will this affect vendors? Would those that passed on purchasing a plugin jump at the change to have a different licensing tier choice? Or would vendors suffer? Let me know your thoughts! The post Episode 7 – JIRA License appeared first on The Admins of Atlassian Podcast.
18 minutes | 5 years ago
Episode 6 – JIRA Core and JIRA Software
In This Episode I share my thoughts about JIRA7, JIRA Core, and JIRA Software. Resources Mentioned JIRA 7 Migration Hub (IMPORTANT!) Podcast Music – The Boss Intro (remix) – MDAJ (Me) Social Twitter Facebook Blog Version Of Podcast Not a transcript, but a standalone blog post of the podcast if you are unable to listen. Enjoy! Overview With JIRA 7.0 came the breakout of JIRA from being an application itself to being a platform. What sits on top of this new platform are the applications: JIRA Core, JIRA Software, and JIRA Service Desk. Here are some things that I found from my early testing and documentation. JIRA Core This is JIRA. If you had JIRA before JIRA 7.0 then JIRA Core will carry on that moniker with some changes. This application is aimed at business teams with project schemes and workflows aimed towards business solutions. When creating a project, you can choose from business templates that focus on Task management, Project management, or Process management. Each option will have it’s own workflow style suited for those work styles. When selecting one, each project will have its own Issue Type Scheme, Screen, Screen Scheme, Workflow scheme and Workflow. The field configuration is left at default. You may also choose to opt for a shared configuration for projects that are similar. Groups First is the change from “jira-users” to “jira-core-users” for group management. Users will be added to this group by default to login and to be able to access the JIRA Core application. This does allow you to associate other groups for access permission and to define a default should you have more requirements regarding security. JIRA Software JIRA Software combines JIRA (Core) and the previously known, JIRA Agile. With this “merger”, JIRA Agile is no longer available for you to download in the marketplace. The downside is that the Agile functionality cannot be updated separately. This was something I liked to keep the improvements coming to my development teams throughout the year without the need of doing system upgrades. Now, to provide those new features, the entirety of the application must be upgraded. With JIRA Software, you gain access to everything you had before. You will have access to the Boards for scrum planning or kanban. The release hub is available as well as developer tool integrations. And with that, this is what users of JIRA without Agile lose out. If you were a team that used JIRA for development, but opted NOT to buy the Agile plugin, with JIRA Core you do NOT gain access to the release hub NOR the integrations. Meaning you cannot view commits on the issue as that is part of JIRA Software application functionality. Dashboard gadgets such as Road Map or Version Report are hidden from JIRA Core users as well. Groups The new group to give access to JIRA Software is called “jira-software-users”. Like JIRA Core, if you are upgrading to this version, then those users that had permission to use JIRA via the “JIRA Users” group will be assigned to this new group so that they may login and access the application. Applications With JIRA as a platform, applications were introduced. JIRA Service Desk is now an application instead of a plugin. Installation of this is now done through the Applications tab instead of the Add-ons. JIRA Portfolio may follow in the future, so you may want to stay tuned. Licenses Licenses now fall under each application that you have installed. You may ask yourself “If they are applications now, can I have more than one installed?” Yes. You can have JIRA Software licenses while simultaneously having JIRA Core licenses. Example: If you have a business team that has no interest in the “Agile” or Software development features of JIRA, then they can be assigned the JIRA Core license only. JIRA Software users DO NOT need to be assigned to the JIRA Core user group. JIRA Software users automatically inherit JIRA Core features in addition to the Software features. Pricing There should be no change in licensing for existing users. JIRA > JIRA Core pricing remains the same. JIRA + JIRA Agile > JIRA Software pricing remains the same as well. “Wait, I just check the cross reference and the price increases from what I pay for JIRA + JIRA Agile?” You’re right. Though, Atlassian has stated that pricing will remain the same for existing users while the listed price will be for new users going forward. Final Thoughts JIRA 7 is a big release and I’ve only dipped my toe in it. Like you, I will have to think about how my existing security structure works and how it will work in JIRA Software going forward. Potentially, how does my licenses work if I have a mix of business and development. Can I break it out as per application? Or Just stick with JIRA Software. Not only do admins and users have a new UI to deal with (if they skipped 6.4), but we will need to understand the new structure of JIRA so that we can manage this new platform going forward! The post Episode 6 – JIRA Core and JIRA Software appeared first on The Admins of Atlassian Podcast.
13 minutes | 5 years ago
Episode 5 – Atlassian Summit 2015 Thoughts
I share my last thoughts about the Atlassian Summit 2015. The post Episode 5 – Atlassian Summit 2015 Thoughts appeared first on The Admins of Atlassian Podcast.
12 minutes | 5 years ago
Episode 4 – Last Thoughts On Getting Started With JIRA
In This Episode I share my last thoughts on getting started with JIRA and what you should think about to get JIRA going within your team or organization. The post Episode 4 – Last Thoughts On Getting Started With JIRA appeared first on The Admins of Atlassian Podcast.
18 minutes | 6 years ago
Episode 3 – JIRA On Windows Or Linux
In This Episode JIRA On Windows Or Linux - I talk about a few things to consider when deciding on the operating system for JIRA. The post Episode 3 – JIRA On Windows Or Linux appeared first on The Admins of Atlassian Podcast.
15 minutes | 6 years ago
Episode 2 – JIRA On Physical Server Or Virtual Server
In This Episode I share a few news items from this week and then I dive into the featured topic and share some info about going with a virtual or physical server for JIRA. The post Episode 2 – JIRA On Physical Server Or Virtual Server appeared first on The Admins of Atlassian Podcast.
17 minutes | 6 years ago
Episode 1 – JIRA Cloud Vs JIRA Server
In This Episode JIRA Cloud or JIRA Server? JIRA issue tracking is a great issue tracking tool, but getting started depends on the needs of your team. The post Episode 1 – JIRA Cloud Vs JIRA Server appeared first on The Admins of Atlassian Podcast.
11 minutes | 6 years ago
Episode 0 – The Introduction
In This Episode In Episode 0 of the Admins of Atlassian Podcast, I simply introduce myself and give you a history of me. I also share why I started the AoA podcast and the topics Admins of Atlassian will cover. So sit back and take a listen and I hope you enjoy! The post Episode 0 – The Introduction appeared first on The Admins of Atlassian Podcast.
Terms of Service
Do Not Sell My Personal Information
© Stitcher 2021