Hi! I'm Cameron Deatsch, enterprise enthusiast and Head of Server at Atlassian. AMA!

[Cameron Deatsch]

Hey team!

I'm Cameron Deatsch, Head of Server at Atlassian. At our European Summit just a few weeks ago, I spoke about the latest regarding our Server and Data center products and our approach to prioritizing our development efforts across customer success and customer scale. 

Customer success is all about delivering the new capabilities you're requesting to make administration easier, end users happier and our products more flexible to meet your business needs. Customer scale is focused on ensuring our products are reliable and performant as you standardize your mission-critical processes on top of our products. PS: If you want to go a little deeper, watch the State of the Union: Investing in Your Future With Atlassian Server & Data Center, by Keshav Puttaswamy, Head of Product, Server and Data Center 

I spoke to a lot of enterprise customers at Summit, but also realize that not everyone can attend, so I wanted to keep the conversation going here! Shoot me your questions, upvote others' questions and stay tuned as I'll be answering anything and everything that's on your mind about how we're setting you up for the next chapter of growth with Atlassian.

Start submitting questions now below (yes, it says answers ;-)) and tune in Monday, September 24th from 1 to 5 pm PDT when I'll be answering questions live.

Cheers,

Cameron

[Walter Buggenhout]

With the recent price changes bringing Server so close to Data Center in terms of cost, where lies the future of the Server Platform in - like - 3 to 5 years from now?

[P_D_ Foerster]

I was thinking exactly the same.

[Mark Lang]

I'd like to add to this question - with the cost increase to Server will the feature developments be made to Server or will the trend continue in Data Center even though the costs increases were not made there?

[Cameron Deatsch]

Hi Walter,

Please see my response to Gregory below regarding the commitment to the server platform. 

When it comes to pricing, you're right to point out that with the recent price increases in Server, we've closed the gap with Data Center pricing for many of our customers (specifically with those below 1,000 users). This is by design. While we continue to sell server licenses and support server customers with thousands of users, we are not shy about recommending Data Center to those customers. The simple fact is, if you're running our products in a mission-critical environment where uptime, performance and increased administrative capabilities are a requirement, we recommend you use our Data Center products. 

The reason we've kept our 500 user Data Center license so affordable when compared to our server products is we believe there are a variety of server customers with less than 500 users that desire Data Center capabilities and we believe the current pricing accommodates those customers quite well. 

[Cameron Deatsch]

Hi Mark,

Data Center is and will continue to be a focus of significant investment for the team. 

[Mark Lang]

I agree with that answer.  However the communication for the reason to increase server products license costs does not seem to jive.  Anyway - thank you for taking the time to answer the questions here!  It is much appreciated. 

[Gregory Van Den Ham]

First, huge thank you for your commitment to the server platform.  From the Chicago perspective, I hear a lot from Financial institutions and other organizations that have Jira, Confluence and other Atlassian applications on-premise to meet compliance, security, and other requirements.  Some of these organizations have deeply integrated application tie ins, customizations, high user counts, and large data sets that have stopped them from going cloud.

Many of them are also feeling left behind by cloud first innovations.  I think what we'd love to have you chat more about is the commitment to server platforms, its evolution, and some of its roadmap.  Perhaps how the trials and errors in cloud have helped shape what gets deployed in server and if we see the products converging or splitting in some of its functionality.

[Armando Leon]

Hi, I second this question!  One specific irritant is the addition of Slack integration to Confluence Cloud without giving it to Server as well.  I guess with the discontinuation of HipChat I worry that you might drop Confluence Server altogether at some point in the future, or that it'll end up looking like a vastly different product from the Cloud offering, where the cloud offering will feel and function in a much more modern manner with better integrations.

Also, I either don't know where to look (and I've looked!), or it seems like I can't find any guidance on what the roadmap looks like for either Server or Cloud.  Like, for instance, when do you imagine putting out a version 7, and what will that offering look like?  I want to feel confident that you're continuing to invest in the Server product, and without much information about a roadmap, I have to take that on faith.

Here's my question: Can you please share some specifics on the Server vs Cloud roadmaps?

Thanks!

[Cameron Deatsch]

Hi Greg, 

Thanks for your question! As Mike spoke about at Atlassian Summit in Barcelona, Atlassian's future depends on the company becoming a best of breed provider of cloud technology. However, a significant portion of our customer base are, as you already mentioned, long-time users of our server products. We realize that it's the passion of our server customers that helped make Atlassian what it is today, so whatever we do in order to speed our innovation in the cloud, we have to make sure our server customers are well taken care of. Until 3 years ago, we were still managing our cloud and server products from a single code base and this created some real problems. 

The reality was, by continuing to develop our products for the cloud and server on a single code base we were forced to make tradeoffs that in the end were suboptimal for either deployment. In other words, we realized we would never be a best of breed cloud company if our code always required 100% fidelity with our server deployments. Additionally, our server ( and more recently data center) customers, had new demands that were fundamentally at odds with our cloud deployments. Many of our largest customers were standardizing and consolidating their critical business processes on Atlassian products and were rightfully demanding investments in enterprise scale and control. High availability, disaster recovery, performance improvements and most of all, assurances that Atlassian would scale to meet the ever-increasing demands of their businesses. 

So we made a choice. We decided to split the development of our cloud and server products into independent teams with independent roadmaps. This was not an easy decision but in the end it was the right one. This one decision has enabled us to completely rearchitect our cloud technologies on top of AWS taking advantage of a new microservices based architecture that provides incredible performance, scale and speeds feature development. 

This decision has also allowed us to focus on our server customer needs. We've gone back and delivered some of our customers' most long-lasting, highly voted feature requests. In fact, since we made this decision we've delivered features that represent over 30 thousand votes from our community. Additionally, it's allowed us to really dive deep into the core of our server and data center applications, addressing long-term technical debt, allowing us to modernize our applications and set them up for long-term success in our customer environments. 

With all this said, the server teams do work with the cloud teams to understand what new features are coming to cloud and if they will be applicable to the server base. Native mobile apps and collaborative editing in Confluence are two examples where we delivered largely the same experience in server as in cloud. However, often times we borrow capabilities from cloud in more subtle ways. For example, recently we modernized the entire UI in Jira Software and Confluence Server borrowing many of the same design elements from our cloud products. However, we stopped short of redesigning the entire user experience as we believe it would be too large of a change for our customers to handle in a single upgrade. Most importantly, we prioritize all of these efforts against the long list of feature requests we receive from our server customer base which we believe in the end, provides the best experience possible for those customers. 

To summarize all of this, we are committed to the Server platform and prioritize our efforts based on the requirements of our server customer base. Customers should expect to see us continually deliver new capabilities in our server and data center products, some borrowed from the cloud, and some designed purely for our server and data center customers. 

[Cameron Deatsch]

Hi Armando,

We are working with the Slack team to scope out integrations with Confluence Server now. We understand that the end of life of HipChat could cause concerns about the future of Atlassian's other server and data center products but rest assured, we're continuing to invest in our server and data center products.

We don't publish roadmaps for our products but I suggest you check out my presentation from our Summit conference in Barcelona a few weeks ago:

https://www.youtube.com/watch?v=EE22Ll6LIME&feature=youtu.be

Go to the 22:40 mark.

And for a more in depth overview of all our Server and Data Center imrovements please view the presentation with Server's Head of Product Management, Keshav:

https://www.atlassian.com/company/events/summit-europe/watch-sessions/2018/featured/state-of-the-union-investing-in-your-future-with-atlassian-server-data-center

[Armando Leon]

Awesome, thank you!

[April]

Hi there! I'm also in Chicago, in Greg's Atlassian user group. At my company, we've been feeling left behind by issues we've voted for and watched for years being resolved only for Data Center. Yet, since Data Center only supports redundancy within a single location, no one here sees it as an actual enterprise (global) solution worth purchasing. 

We'd love to know if the code base will continue to diverge, and how you perceive the difference between Server and DC customers.

[Cameron Deatsch]

Hi April,

I feel like I need a trip to Chicago. I'd love to make it out there to your AUG one of these days.

To help answer your question in July, our Head of Product Management posted a blog on how we prioritize features for Server vs Data Center that can help clarify this for you.

Data Center was created based on feedback from customers such as yourself. Data Center is more than just about high availability, although that is certainly one of the benefits. It is also for enterprise customers who are looking for performance at scale, deployment flexibility, and administrative control. 

Regarding your desire to have Data Center products scale across multiple dispersed Data Centers please see my response to Craig below. In short, it's something we're looking at.

As we look ahead, you will continue to see capabilities for team productivity (e.g. mobile, search) in both Server and Data Center. Capabilities that target scaling your infrastructure and administration (e.g. read-only mode, archiving, custom field optimizer)  will more likely be in Data Center.

I don't know how many users your company has, but you can see in my response to Walter above that we've purposefully kept the lower tiers of Data Center affordable for those customers who might now have thousands of users but desire the capabilities that Data Center provides. However, if your company does have thousands of users on our products, we do recommend you move to Data Center.

What were the highly voted features that you feel you're missing?

[April]

Hi Cameron,

I'm very glad you are looking at geographic failover! That's the 'killer app' which would prompt a DC purchase from us.

Thanks for your other questions :)

I only have ~1100 users, so I'm not feeling any performance pain or need for local load balancing. Nevertheless, I am the sole Atlassian admin here, and I have other responsibilities to customer facing systems besides just these internal applications.

I am looking for basic functionality, like administrators being able to see and manage all objects including Portfolios, search filters, and dashboards (JRASERVER-15900 and JRASERVER-41269), and for group management delegation (CWD-5251). Basically, if a user can make it, I need to see it, without resorting to 3rd party apps or time-wasting cludges, similar to Confluence.

For me, filter management is the most painful because filters are used in Agile boards, and if I disable a user who owned that filter, the board breaks, and must be recovered via SQL hack. We are big enough to have DBAs who see hacking vendor products in this way as a Very Bad Thing (and spare no opportunity to badmouth Atlassian to everyone here), yet we're not big enough to add staff who could assume the endless task of auditing owned objects and hunting down people to take ownership or approve deletion. It is nice that the user can share and allow editing by a group now, but what if I'm not in that group?

As a senior engineer, I really don't want to spend my day running SQL queries to get the list of departed-user-owned objects, then starting the relevant email chains, then marking a follow-up date in my calendar because nobody I thought to try responded but I must get the users cleaned up before Compliance comes after me... That's a great big pile of Drudge with extra Boring on top!

Managing all groups isn't a whole lot more fun, but apparently only Data Center customers deserve help with this. My only other option would be to make all desktop support staff into Jira and/or Crowd admins... how well do you suppose that would work out?

Project + Group administration would be the beginning of a 'Junior Admin' role that I could use to safely start teaching others how to admin Jira, and allow me the opportunity to focus on building new things and providing faster service for real problems.

I truly believe you have great products that are highly useful and extensible, and if you could just round off some of these rougher edges, maybe my coworkers and management chain would see you the same way that I do :)

Thanks!

[Gregory Van Den Ham]

We should talk next week at AUG Lunch.  I'm curious about the group memberships.  I simplified and without Crowd, pulled in SAML Claims to take in my AD groups.

Might be a few other things we can kick around.

[Craig Castle-Mead]

The DC product line doesn’t support geo-redundancy - which as a global enterprise would be a huge benefit, both performance in various locations and for HA/DR. While I’m sure there’s many technical changes that would need to happen to, I’d see the most crucial blocker is that all the DB tables run off auto incrementing IDs, not GUIDs. Where is this conversation up to within Atlassian for the various products?

CCM

[Craig Castle-Mead]

Following on from globally distributed performance, there's no officially supported CDN approach, but with reverse engineering and a bunch of testing, we implemented a configuration that helps significantly (https://community.atlassian.com/t5/Jira-discussions/CDN-CloudFront-and-Atlassian-Server-apps/m-p/731230#M2361), but due to the varied URL structure for files that have the same content (unique strings in paths / timestamps in querystrings etc), it's nowhere near as efficient as it could be, meaning our servers are dealing with traffic they provide no real value for. While there's obviously a LOT of dynamic data that has to go back to the origin, and being able to reliably ensure newly generated content (add-on updates etc) are deployed is important, it feels like the current approach is still far from the right balance. Are there any active/planned projects to improve the caching process?

CCM

[Cameron Deatsch]

Hey Craig,

It's been a while since we caught up. I hope to be in New York soon and would love to catch up if I do.

In response to your question, in Bitbucket Data Center, you can achieve something like this type of redundancy using mirrors. In fact, we use this feature extensively internally with our different development sites around the world to mirror the various codebases to save time for our teams.  However - you are correct, we don't currently support this in the other Data Center products. This is something that we are considering from various angles such as using a distributed caching proxy for static resources.  And yes - you are correct again, there are a lot of technical challenges with making this work properly, the database just being one. 

So, put simply, conversations are happening in relation to this and understanding exactly what we need to solve for, but our plans are not ready for primetime yet and we don't have a timeframe.

[Craig Castle-Mead]

Hey Cameron,

Thanks for the reply, and good to hear there’s at least conversations. I’m sure there’s many competing priorities and juggling them all is a challenge. 

Would be great to catch up again next time you’re in town. I have a bit of travel coming up, but if/when you have dates yell out and hopefully the stars align.

CCM

[Walter Buggenhout]

A great improvement in Jira 7.12 is the new custom fields view. We all know the impact of custom fields on instance performance can be really serious. Especially when they are not configured in the best way. Data Center now even has a custom field optimiser, just because of that. Excellent feature, btw!

I am wondering how this aligns with the trend to give more and more power to the user. As we've seen in Cloud, every user is encouraged and enabled to start creating his own custom fields. By the time this feature comes to server/DC, what magic will be done under the hood to make sure to reconcile these - apparently - contradictory developments?

[Cameron Deatsch]

Hey Walter,

Happy to hear you appreciate our latest changes to custom fields in Server and Data Center.

You are right - our approach to custom fields in Cloud and Server/Data Center is different. This is dictated by the needs of our customers. Whereas Cloud customers seek autonomy on the team level, many of our server and data center customers are looking to consolidate and standardize how teams work in their environments. 

For many customers, the proliferation of custom fields has created significant performance issues and this is why we've focused on helping customers clean up and optimize their custom field configurations.

This doesn't mean that we're not working on providing some autonomy for users in Server/Data Center. Our introduction of delegated administration in Jira a while back is an example of where we try to improve the balance of team/admin control.

I cannot speak to what exactly will change under the hood in the future but our ultimate goal is to make sure Jira Software Data Center can scale to meet the growing needs of our customers. If scaling custom fields will be one of them - we will go this way.

I'd love your opinion here. If performance wasn't an issue, would you like to enable every team to create their own custom field in your Jira environment?

[Walter Buggenhout]

Hey @Cameron Deatsch,

Thank you very much for the open and detailed answers over here. There is more to it than just performance. From an administrator perspective and when your goal is to standardise, giving all users the ability to create their own custom fields just sounds like a nightmare.

Suppose there was no performance issue anymore, and let's even assume that giving flexibility to users is fundamentally a good thing, at least the following should be tackled as well:

• custom fields can be created with the same name. If 500 users (I am not going into the really high user tiers on purpose) have the power to create their own fields, how many category, type, department, amount etc. fields will we end up with? This has impact for the administrator(s) of the instance, but also for every single user in cross-project JQL search, reporting and dashboarding and so on.
• custom field context is a key concept in current Jira configuration, but it is not easy to understand at first sight and definitely not something to open up to users to administer the way it is now.
• Fields play an important part in workflows. The more you share workflows and the conditions / validators / post functions in them, the less flexibility remains towards your end users. The right balance of control versus autonomy should always be considered.

In my ideal world, it should be possible to define the standards the organisation agrees upon. And in addition, users could have the flexibility they need to work without impediments and have fun while doing that. For that to happen, they should be properly trained to know what the impact of their actions is (but I'm afraid that's not a realistic scenario) or the tools should support them in such a way that accidents only lead to minor damage. Their actions should not be destructive to performance or key standard configuration in any way, nor should they have a negative impact on the usability of the tool to other users or themselves. I guess.

[Cameron Deatsch]

Thanks for the response Walter. This is great feedback.

Have you been able to try this new approach in our Cloud offerings? Does it achieve the control/autonomy balance you are looking for?

[Mirek]

@Cameron DeatschI must say that I totally agree with Walter.

Cloud is currently not an option for a lot of enterprise customers that have many issues, objects in JIRA and are using many extensions (addons) since we all know that even same plugins exists on cloud and server those are not the same products (like Cloud and Server JIRA for example). And many customers do not want to pay per user, per application, per year just to allow access to their instances so that customer can view progress of a project. So we need Server. Period. And not sure why everyone is pushing so heavily to cloud solutions which are not for enterprise. Enterprise needs stability and cloud change so often and it is not super stable (what you can see on https://status.atlassian.com/). That is why you also introduced Enterprise releases, right? To keep many customers on stable position.

I am an experienced admin and over the years struggling with many annoying JIRA limitations. Instead of making life of an admin easier it is more of a pain. Giving too much for the users mean more objects, bigger clean up, worse performance etc. .. and who will struggle with that? Of course JIRA admins.

Let me give you an example of wrong roadmap decisions.. Extended Project Administration. Fine. This give ability to people to edit their workflows and screens. Sound like a perfect solution. Admins can now go on vacation, right? Wait, but there are the limitations that project need to have unique schemes and cannot be share with other project ... so if you follow most of the best practices (and those are also underlined on official Atlassian University videos) you know that most of the objects should be shared if possible.. Now you have an enterprise instance and 1000 projects share same workflow scheme or field configuration and screens. Then an admin of course need to make a lot of effort to make the schemes unique and after time there would be a total chaos in the instance ending up with 100x object only because some admins wanted to do a small workflow or screen change... In addition this project admin wanted a change and second did not and how to know who did wat? There is not detailed audit log per project so nobody knows who did what. Someone reordered a field or removed it from the screen even it was required in the workflow?.. project not working after that?.. business affected?.. JIRA admin to the rescue again since only those people can edit other things like for example conditions, validators or post functions.. In addition to that after JIRA upgrade the Extended Project Administration was enabled for all projects and there was no bulk option to disable that. So admins would need to open every permission scheme and disable that manually. Helpful feature? I think not..

Second quick example a new project creation experience.. It is nice to create a project with a single click of a button without the need of switch schemes after that (which was for many years) . But what happen after? Project is created but new unique schemes are created also with unique naming (with project key as prefix).. So now please imagine (because you plan to give also project creation! to users and that was announced) what would happen if users would create projects even they want 10 or more projects to use the same configuration?.. Answer is simple. Then they would need to do the same things 10 times on every change.. Modify workflow.. modify fields.. Drag and drop.. again and again. They cannot share the configuration because of the limitation that schemes need to be unique if they want to modify workflows and screens.. So we do a round circle.

Is this really the path that we would like to go?

Those are only a few examples. JIRA admin should be a gatekeeper to make everything stable. Making things open and enabled by default make life worse. It is like giving someone a loaded gun without knowing for sure if that person know how to shoot. That is why we are doing those Certificates, right? To be sure what we are doing when modifying thing..

If you can give us a feature first that I can easily use on JIRA to know what is going on on the instance.. who is doing what (with details).. what changes are being made.. what objects are duplicated.. easily consolidate schemes or split them with a single click.. then maybe I can believe that I would be still be able to handle user actions done on workflows, screens and projects overall. Some things simply should be restricted to admins and if you introduce a new feature please make it optional and let admin decide to enable it or not.

Thank you.

[P_D_ Foerster]

@Mirek

[Dan]

@Cameron Deatsch thanks for taking these questions.

Currently the entry level user tier for DC stands at 500 users for most Atlassian products (Bitbucket is the exception with 25 users being the entry point). Is there any chance that this number could come down sometime in the future?

I work for a large enterprise that is currently piloting the Atlassian stack in the cloud environment and am trying to convince decision makers that DC is the way to go long term. That being stated, the scope of this pilot program is just shy of 100 users and it would be nearly impossible to justify having almost 400 unused licenses while we demonstrate the best features the tools have to offer.

Thanks!

[Steffen Opel _Utoolity_]

Have just been about to ask the same - I honestly never quite understood why DC has been introduced for large user tiers only, and still remains positioned as such for Jira/Confluence, with the Bitbucket reduction being a highly welcome exception.

As for specific use cases, there are e.g. many regulated industries with considerable HA and DR requirements that still prefer to or even require working in high velocity agile yet small teams within isolated bounded contexts, think finances for example. These teams absolutely want to have their own Atlassian instances, and while one might argue they should be in a position to pay higher price points (and generally are), as Atlassian is well aware of, many of this comes down to psychology and it would be easier to sell Atlassian products (and esp. applicable Data Center approved apps on top of them) without this perception of 'paying considerably more for unused seats'.

[Cameron Deatsch]

Hi Daniel,

Please see my response to Walter above regarding pricing of Data Center with respect to server.

First, I'd love to hear why our Cloud environment is not serving the needs of your company long term. While we're more than happy to have you on our server or data center products, if you're piloting in Cloud, why can't you stay in the Cloud?

If you are working in a large enterprise with requirements for performance and high availability then you're definitely correct in pursuing our Data Center offering. We do not currently have any plans to offer lower tiers but hope that the $12k price is not insurmountable for a large enterprise. How long of a pilot do you need? Our evaluation licenses provide 30 days at no cost whatsoever.

[Cameron Deatsch]

Hi Steffen,

Thanks for your feedback on the pricing of Data Center. I agree with your statement around the fact that psychology drives a lot of the decisions here. 

There is a bit of history here but the reality is that when Data Center was first introduced, we designed it specifically for larger customers that demanded HA and performance. Since that time, the offering has evolved and addressed the broader needs of any customers running our applications in mission-critical environments. While you're correct to point out that there are many customers with less than 500 users that may have HA requirements, our data has shown that $12k is an acceptable entry price for those customers. 

[Ravi GH]

i did not find any one customer enabling Git LFS with Bitbucket Datacenter  in SAML environment.

is it advisable to enable Git LFS on Bitbucket for an high critical Production Bitbucket instance.

Do you know any customer story who has enabled Git LFS on Bitbucket DC?

[Cameron Deatsch]

Hi Ravi,

I reached out to the Bitbucket product manager regarding this questions. Here is what he said:

"There are many customers using Git LFS with Bitbucket Data Center, and if I remember correctly, there is a customer using similar setup to what you've described. Bitbucket Server and Data Center officially support Git LFS. An embedded LFS object store is included so there shouldn't be any problem in using it. Using any external object store for LFS objects is possible but it may bring its own set of challenges.

I also understand that you have raised a support ticket related to Git LFS. Our team will continue to work with you on this."

[shyamjovals]

When can we expect the mobile version(android) for "bitbucket", because that would be highly convenient! :)

[Gregory Van Den Ham]

Ah, mobile versions of everything, ideal!

[Cameron Deatsch]

Hi Shyam,

Thanks for the question! Bitbucket Mobile isn't something we've heard from our customers very often. Our Bitbucket Server Team would be interested to know what kind of features you'd expect in a mobile app?

[Cameron Deatsch]

Hi Greg,

Jira Software Server mobile is coming. We're working on it now. Confluence mobile is already available.

[Kristian Walker _Adaptavist_]

Hi @Cameron Deatsch,

I missed this discussion on Monday but had a question if you are still able to answer it.

My question is that for Jira Cloud there is a Service desk report gadget which allows you to display you custom service desk reports on a standard Jira dashboard and this is really useful to view custom reports from multiple different service desks in one central location. 

However Jira Server does not contain this same Service desk report gadget to allow you to place custom service desk reports on a Jira dashboard.

Do you have any plans to bring this gadget over to the server version in future?

Thanks

Kristian

[Sagar Dubewar]

Can Confluence Server be installed on the AWS instance? If yes, what configuration is recommended?

[Cameron Deatsch]

Hi Sagar,

Absolutely yes, in fact, many customers run Confluence Server in AWS today. For Confluence Data Center we provide a Quick Start guide which contains a CloudFormation template to make getting started easier. The CloudFormation template is also a good starting point for automating Server deployments.

There are a few things to consider when deploying Confluence Server to AWS. At a minimum, we recommend a c3.xlarge EC2 instance for hosting Confluence, either with or without Synchrony (for Collaborative editing) on the same instance. You have the choice of using an ALB for the load balancer or just running Nginx or the like with the EC2 instance. For the Database we recommend running this separately on a PostgreSQL RDS instance. File storage can either use the one included with EC2 (EBS or SSD), or a separate EFS instance.

[Dastin_Kuwałek__SoftwarePlant_]

Hey there @Cameron Deatsch :) I have two questions about the impact that Jira custom fields have on indexes and Jira reindexing time.

How does adding new Jira custom field affect Jira issue indexes in terms of the size of the index?

Does limiting access to a custom field using Jira Project Field configurations decrease the reindexing time?  

Let me know if you know the answer :D or where can I find this out :)

Dastin

[Cameron Deatsch]

Hi Dastin,

In Jira Software Server, every custom field is created with what we call 'global context' by default. This means that every new field is available in all issues from any project. This also means that Jira adds the value of that custom field to every existing issue. Usually, these values are empty. These values increase index size and this size increases the time of reindexing.

You can optimize both the size and reindexing time by setting the custom field's context to 'local' and selecting projects which will be using this field. This way, you will remove all unnecessary data from the fields outside of selected projects. This will decrease the size of the index and will improve the readability of your data. You can do it manually from Issues → Custom Fields → Configure.

Additionally, if you are using Jira Software Data Center, you can use the new Custom Fields Optimizer feature:

You can read more about the optimizer here: https://confluence.atlassian.com/adminjiraserver/optimizing-custom-fields-956713279.html

[Mark Lang]

This goes a little bit hand in hand with geo-redundancy.  One of the items that keeps us from considering data center is the need to be in multiple locations across the globe based on the developers location.  However, these developers want to at times still share and would like to integrate multiple Jiras to a single Bitbucket or vice versa.  Due to the application link bug/feature that won't allow for this without all the users to be licensed on all the instances connected, it forces us to have only a 1 to 1 integration between Bitbucket to Jira where we can connect multiple GitHub instances to a single Jira or multiple Jiras to a single GitHub.  When can you help get this feature prioritized so I can help promote Bitbucket integration again?

[Cameron Deatsch]

Hey Mark,

Sorry it took me 3 responses to realize that we spoke on the phone back in June. Let me ping the team and maybe we can setup a call to discuss this one.

And just so I'm clear, is your problem with the way licensing works in that every Jira users needs a Bitbucket license for the applinks to work?

[Mark Lang]

Hi,

No worries.  I just appreciate you taking the time to answer all of the questions as thoroughly as you can.  It is less about how every Jira user needs a Bitbucket license and more about links not working in the case where the user has one jira license and one bitbucket license but not the second (third+) jira instance license.  

I've been watching - https://jira.atlassian.com/browse/BSERV-4814 because it was tracking multiple aspects but one big part of the issue that seems to not be working for us is around https://jira.atlassian.com/browse/BSERV-4805.   That being said, that particular ticket has been marked as fixed as of 3.11 in June 2015 and we've seen the issue as of May 2017.  I'll work with our TAM to reconfirm once again and make sure it is properly updated.  It could be related to the same key being used but the problem is following the link.   

We just need to have a single Bitbucket Data Center that is connected to from multiple Jira instances and as long as you have a license to one Jira and to Bitbucket, the integration should work when clicking the links in the windows referencing the other tool.  

Thanks again for taking the time on all these questions.

Mark

[Cameron Deatsch]

No problem Mark. I'm happy to setup a call with our Bitbucket product manager as well. Just let me know.

[Mark Lang]

We rely on security fixes a good deal and therefore try to stay close to the Enterprise Release versions of Server.  Having once a year versions is not frequent enough for us.  Are you considering more frequent Enterprise Release Versions? And what are you doing to try and keep those versions in sync across the products (where needed)?

[Cameron Deatsch]

Hey Mark,

As you probably know, the Enterprise Release (ER) versions is a fairly new addition to the way we ship software. In fact, we've only shipped on Enterprise release so far. Our current plans are to continue to ship ER versions annually but as always, we can adapt based on customer needs. The good news is that we have proven that customers on ER versions of our products are more stable and submit less critical support tickets to our support teams. The bad news is that a large portion of our customer base is not as proactive as your organization and have yet to even upgrade to our current ER that we shipped at the beginning of this year. 

We're not in a position to change this program right now but we're always open to the feedback and you're not alone with this request. However, if you work in a large organization, I always recommend staying on the Enterprise release as the risk associated with downtime or performance degradations is nothing compared to the risk of waiting for a new feature. 

[Craig Blasberg]

The risk I see as staying up-to-date on security fixes which is one of the stated goals.

Using JRASERVER-67695 as a current example, how are you applying the critical fixes for the Enterprise Release clients?  I know it may not even be reasonable to backport the current Enterprise Release version, which is one reason for asking about having a faster cadence than annual.

I realize this is past the window you had for questions, but did want to highlight a concern with the execution and use of ER versions.  Thank you for taking the time to respond to all of these questions.

[Jamie Rogers]

Hi Cameron

I enjoyed your talks at Summit however I was hoping you could provide a further update as to when the new Jira Performance Tool will be available? 

No specific dates were mentioned other than later this year.

Other users have mentioned above regarding the cloud first approach when it comes to new features - is there any roadmap or feature alignment with server products that you could share?

Regards, Jamie 

[Cameron Deatsch]

Hi Jamie,

I'm glad you enjoyed the presentation.

Jira Performance Tests (JPT) beta tooling has been made available to app vendors and a select group of customers to try it out and provide feedback. We'd love to share it with everyone but this would lower our ability to respond to all questions, bugs, and suggestions in a timely manner. 

We don't have a date for public release yet but we're working to get it out as soon as possible. To be notified about the availability of JPT please watch this issue: go/jpt-release.

[Marlon Macatangay]

Reindexing is a critical action for ensuring data center performance. But this is currently triggered manually or outside. Will this be integrated into the system to be an automated system scheduled action?

What is the best Hardware configuration focused for Jira performance? Critical points to consider designing hardware preferences on which to prioritize, be it cores, hyperthreading, frequency, memory, and storage.

[Cameron Deatsch]

We're planning a set of improvements for our Data Center products to lower required frequency of reindexing. In parallel, we're also researching reindexing management capabilities that our customers would expect. Would you be willing to speak with us on this topic?

Let us know if someone from Product Management can reach out to you.

Regarding improving the performance of your reindexing, I suggest a couple of links:

https://enterprise-tam.atlassian.net/wiki/spaces/TC/pages/322077592/Jira+Lucene+Index+Q+A

https://enterprise-tam.atlassian.net/wiki/spaces/EA/pages/331219170/Jira+Indexing+Guidance

[Move Work Forward]

Hi Cam,

1. How can we co-promote our DC/Server Apps with Atlassian?

2. Is there any way to get hints of DC/Server functionality gaps that App devs like us can address?

Thanks!

[Cameron Deatsch]

I suggest you work with our marketplace team that can help you with promoting your app via Atlassian channels as well as via your own marketing. 

Let me know if you're not already connected with that team.

[Move Work Forward]

Hi @Cameron Deatsch

We are not connected. Could you help here please?

Thanks!

[Sonya Goldstein]

Hi Cameron, I have not been able to find any indication that Atlassian is planning to integrate "google analytics" type reporting and analytical tools that allow the ability to assess and measure the viewing and impact of a given article towards solving a customer's issues.  In other words, if I publish an article to the customer portal knowledge base, i want to assess how many customers find that article when they search for information or begin submitting an issue and view the article instead of opening a ticket.  I want to assess how helpful tags are.  If we cannot measure the impact of a given article as a helpful tool to customers, we have no way of assessing if it is making ANY impact or knowing where to make changes (tags, any configuration that increases that article's ranking in search results, what areas need MORE information).  We made a big investment, in part expecting that these analytics existed and it is quite a shock to find out that we cannot properly measure the ROI on our Knowledge Base! What plans are in place to make this available to the server product?

[Cameron Deatsch]

Hi Sonya,

I'd love to hear more about your use case here. Is this for a customer facing or internal knowledge base for your employees.

We realize that the native reporting capabilities may not fulfill all your needs in Confluence. However, there are a plethora of apps available in our marketplace that provide exactly what you're looking for:

https://marketplace.atlassian.com/search?query=confluence+analytics

There is also a good thread in this community where users recommend a few of these apps:

https://community.atlassian.com/t5/Confluence-questions/How-to-track-Confluence-page-views/qaq-p/430574

I hope this helps.

[Sonya Goldstein]

@Cameron Deatsch- Thank you for your quick response!  This is customer facing.  Limited by functionality needing to be available and compatible with DC.  Need to be able to measure impact of articles in those spaces and if selecting the self help article stops the viewer from submitting a ticket.  Also would liek to be able to assess search terms/key words.  Don't care about internal contributions to confluence or update activities so need tool that is geared for customer impact of knowledge base.  Appreciate info that you are able to provide or directions to pursue.  Frustrating that this very functionality was advertised as being "ready to be released soon" in Cloud last September as part of core product. From what i can see, it is a fairly pricey proposition to utilize Analytics for Confluence to address a need, if it does provide that functionality, for what would logically be core reporting functionality for a Knowledge Base that supports "customer portal".  ?  The key would be if "user" translates to external customer accounts aka no Confluence licenses.  

[Cameron Deatsch]

Thanks Sonya. I will admit that we've biased development of Confluence Server and Data Center to more internal use cases but I'll follow up with my teams regarding the functionality we've shipped in Cloud and if there are any thoughts around replicating the capabilities in our server environments.

And just so we're clear on how licensing works for apps, you have to purchase the user tier in apps that match your core product user tier. If the majority of the users of your customer-facing knowledge base are anonymous (not logged in), then you won't have to pay to license those users.

[Sonya Goldstein]

@Cameron Deatsch- I appreciate that.  Would love to discuss our use case with you in more detail.  As a company in the Healthcare IT arena, we are utilizing service desk to support our large clientele of customers in the healthcare arena in a HIPAA-compliant, stable fashion.  This means that the cloud product is not an option since Atlassian doesn't enter into BAAs and 24/7 performance and availability to our support team is crucial.  All customers are anonymous since they are accessing the knowledge base and not "logged into" Confluence for knowledge base but this was not desirable either.  We would like to limit our articles to viewing by our customer base only so that only those logged into our JIRA Service Desk portal can view those articles.  This also means that we are striving to make the portal a more truly friendly customer experience; able to search for issues by information that would reside in a customized field, ability for customers to actually sort on the columns made available on the portal.  The types of functionality you would expect from any good customer service tool.  If you have recommendations for plug ins for that as well, i am interested since this also does not seem to be part of core Service Desk product.  

[Jason Corbett]

We have 'Organizations' that create JIRA cases/tickets. We would like to be able to create a dashboard where we can display the number of cases/tickets against each organization. Currently, however, the organization field does not appear in the filter list on the Dashboards.

I see this as a fundamental requirement. Can you elaborate on why this is not possible, plans to make it possible and any workaround available?

Thanks,

Jason

[Cameron Deatsch]

Hi Jason,

I received this response from one of the Jira product managers:

"In Jira Software Server you can use the Issue Statistics dashboard gadget to display the number of issues for a given custom field. If the custom field is missing from the list of fields to choose from, it can be a free text type or configured with "None" in the Search Template Option available from the custom field edit screen.

You can read more in the article: Some fields are not showing in any dropdown menus in dashboard gadgets."

Does this solve your problem?

[Jason Corbett]

Hi Cameron,

The 'Organization' field is 'Locked' so I am unable to make the proposed changes to it to make it searchable.

Can you please advise, or ask your team, on a fix for this?

Our internal users have flagged this as a Critical issue for them and limits their visibility across the various Organizations.

Thanks,

Jason

[Cameron Deatsch]

Hi Jason,

Have you filed a support ticket?

[Vickey Palzor Lepcha]

Looks like I am late but how does Trello's future look like ?

[Josh Steckler]

Know I missed the AMA @Cameron Deatsch but curious about the roadmap for Service Desk Server. From what I can tell, none of the JAC suggestions suggest what the team may be working on. The three in progress suggestions are all documentation related, and the 3 of the 5 in Reviewing are documentation related as well.

The lack of information is a bit concerning because it makes it appear as if no work or further development is taking place for Service Desk Server.

[Cameron Deatsch]

Hi Josh,

We are continuing to invest in JSD Server this year and are planning to significantly expand the team over the next 12 months.

I asked our JSD Product Manager to give me some bullets on what we've delivered and what we're working on and here is what he provided:

• Over the past few JSD releases, we've delivered on some big improvements like Priorities per project , Archiving projects, IPv6 support that really help Jira Service Desk admins improve the overall experience of service and performance for their teams
• In addition, we've addressed the top request from JAC: Disabling verification/welcome emails for Jira Service Desk customers so your customers don't receive unnecessary sign-up email. We've invested in modern UI with our products and Jira Service Desk has received these changes. We shall continue to invest in portal improvements making it easier and cheerful for your customers to seek help
• Apart from product, we're also investing in areas of documentation & best practice guides that make finding the right instructions easy. Most recently we've improved and streamlined help notes to setup Jira Service Desk and Confluence. Check it out here.
• What's next: We're all in with our preparations for Jira Software 8.0 and Jira Service Desk 4.0. With tonnes of platform improvements, performance upgrades we're gonna make our products better, faster and more scalable for the future.

I hope this helps a bit. Do you have specific feature requests that you're most interested in?

[Josh Steckler]

Thanks Cameron.

Top of the list for me is JSDSERVER-1551 (does datacenter with SAML sso enabled resolve this?). I cannot (ever) enable Anonymous on my Confluence. And I want the entire company to be able to submit tickets and view KB articles without a license as advertised. But this double login and new tab it spawns is a blocker. People might not know or care what Confluence is, but I still want to serve them with KB.

• Others important features I'm interested in, in order:
  JSDSERVER-2015 / JSDSERVER-4258 - I very much want to be able to edit custom fields with automation rules. Use case: Need to have different approvers based on what the user has entered into fields.
• JSDSERVER-1914 - Having the customer request type field exposed to dashboards would make reporting easier. I can't today say how many tickets of each time I have had very easily. I'd either have to export, or build a report with lots of different series for each request types (I have 40+)
• JSDSERVER-194 - Being able to reset the SLA will make it so I can really build an inactive ticket reminder that can work more than once for each ticket. Sometimes we need clarification from customers several times and they do not respond timely.
• I can't find an exact JAC issue for this one, but I'd like to make the Help Center page more useful. I want it to show all of the different portals that are available to that user, and describe them, so the user can drill down into the right area. Recent request types is not so useful. Also I'd like to see better use of space. There's a lot of white background visible, but text is still being truncated (see below).

These are less important but would also be nice (in no particular order)
JSDSERVER-349

JSDSERVER-282

JSDSERVER-1107

I've also taken to using my nginx proxy to change some of the visual elements of the pages. See my comment here for what I've done to resolve JSDSERVER-330. I'm also using this to inject some CSS changes in a couple places, an example is to expand the number of characters allowed before truncation in the breadcrumbs. My group's portal name is 35 characters long.

The JRASERVER and JSWSERVER projects have been doing a good job of mentioning on popular issues what the dev team is working on and the new workflow seems to be helping. Would love to see JSDSERVER updated in the same way.

[Carol Jones]

Hi @Cameron Deatsch!  Thank you so much for this Q&A time, these are awesome!  I have a couple questions for you :)

1. Next Official Enterprise Marked Release
   Current is almost a year old.
   I've watched a couple recent full demos of new functionality provided in JIRA and am really excited to get to utilize them (specifically JIRA project archiving), however the Enterprise marked version of JIRA is still marked at v7.6 which was released almost a year ago.  I know Atlassian has stated that they will mark at least one version to be the official Enterprise release a year, so I would think this would be updated any day now.  Do you have any insight into when we can expect the next official Enterprise marked release?
   
   
   
2. JQL Functionality around Developer Integrations
   Expanding to date ranges.
   For JQL around development within Jira Software, I know you can filter for number of commits/pull requests/etc. when integrated within the developer section, but what about being able to filter against dates associated with the commits/pull requests/etc.?  Does Atlassian have plans to expand this integration more?  Use case: Our team is requesting a dashboard that pulls all tickets where associated code was pushed to within the last week based on the developer integration.
   
   
   
3. Data Center Apps
   Licensing Structure
   With the new push for Apps being Data Center Approved, we love the new approach as it includes additional testing to ensure performance and functionality are at their peak.  However, with this new approach, will the DC Apps now also follow the DC licensing tiers and pricing models (ex. full price each year instead of half price for renewals)?  This will potentially hit our budget hard and will impact what we can and can't move forward with, so need to plan it out carefully either way.

Thanks again!
Carol

[Cameron Deatsch]

Hi Carol,

3 questions in 1. Let's see how I do.

1. Next Enterprise Release

Communications around our next Enterprise Release are imminent. Please follow the Enterprise section in our community or connect with your Atlassian Technical Account Manager if you have one: https://community.atlassian.com/t5/Enterprise/gp-p/Enterprise

2. JQL functionality

I reached out to my product teams for an answer on this one.

3. DC Apps

Yes, DC apps will be licensed in the same way as our Data Center products. They will match the base product Data Center tiers and will be licensed via annual subscription (the same price every year). We understand that this may result in a price increase for many customers and have tried to give customers plenty of time to accommodate any price changes they may incur. Most importantly, there is no functionality in your products today that will all of a sudden shut down apps if they're not DC approved. My suggestion is you look at the pricing for the apps you use in the marketplace to estimate any future costs you might have. Additionally, if you have specific concerns with the way apps are priced, please reach out to those vendors directly. 

[Carol Jones]

Great, thank you!

Next Enterprise Release
I've just joined the Enterprise group and will watch it for additional information.  My team is trying to determine currently if the value is greater than the risk for moving back to installing the final bug fix release of a feature release more frequently instead of waiting a full year.  When we first moved forward with Enterprise Release earlier this year, it said at least one a year, but now it looks like it's focused on providing only one a year.  We've read through the below, but if there are additional risk analysis articles around this area to help us determine the correct approach, that would be great!

• Should I install an Enterprise release or the latest feature release?
• Bug Fixing Policy - Enterprise Releases

JQL functionality
I'm eagerly awaiting more information from your product teams around the extended JQL functionality associated with the developer integration.  Thank you so much!

[Carol Jones]

Adding @Monique vdB 🙂

[Sara Aghaeian]

Hi,

I purchased JIRA but I cannot install it because I cannot find server ID! I cannot find administration! WOuld you please advice?

Thanks,

Sara

[Sergey Malkov]

Hi, Sara!
You can find Server ID in System -> System Info (Jira info block), or when you setting it up, you will see server ID too

[Sara Aghaeian]

Thanks for your reply. I am using OS operation system. Jiran is running on this system/?

[Sergey Malkov]

We use Ubuntu Server, but i think Jira system info is same in all OS :) Try to find)

[Cameron Deatsch]

Sara,

You can find the server ID here:

Administration > System-> System Info tab 

If you continue to have issues, please submit a support ticket at support.atlassian.com

[Sergey Malkov]

Hello! 

We have a Crowd, that have all our users, 2 instances of Jira Software and 1 Jira ServiceDesk.

Crowd and ServiceDesk hosted in Server # 1. Jira Software instances is hosted in another 2 servers (Server # 2 and Server # 3)

ServiceDesk has application access for Crowd group "Support" and project permissions as shown in the Confluence link, but, our software users can not access to ServiceDesk, they just redirected to customers portal. My account, that I have, can't manage the project issues. How we can solve it?

And another question. We have an Application links for 2 Jira Software instances from ServiceDesk, when I try to create a link from the ServiceDesk to the Software Issue, I see just 2 Software projects instead 5, that I have (1st Software instance) and no one in 2nd Software instance .

I find answer to this question, but now, i can't understand, why ServiceDesk team can't access to Software project without application access? We just want to link customer issue to issue in project, we don't need to access jira software projects for service desk team

Please! Help us!

Thanks a lot!

[Bernhard Gruenewaldt]

@Cameron Deatsch Hi :) I have some questions about JIRA Server and Plugin Development.

First question is about Custom Field Context events (that seem to never get fired). Could you help me with that? => 955#M287949

My other question is about com.atlassian.jira.issue.CustomFieldManager.getCustomFieldObjects().

I am the developer of the Customfield Editor Plugin for JIRA and currently trying to fulfill the new "Data Center Approved" performance guidelines.

• (1) Is there a way to query for customfields and get a paginated version?
  • Currently it seems to fetch all customfields (even though that might be lazy loading) if someone has 1000000 customfields that is not so good.
    
    
• (2) Will there be any form of search API on customfields?
  • Cool would be:
    • Searching for IssueType => get related contextes with customfields
    • Searching for Projects => get related contextes with customfields
    • Searching for CustomfieldName, Description
    • Searching for ContextName, Description or ID => get related contextes with customfields

Are there any plans to implement such methods in the CustomFieldManager in the future by Atlassian?

You could hire me to do so too :D 

thx,

Bernhard

[Cameron Deatsch]

Hi Bernhard,

We're always hiring talented developers. You can always apply here: https://www.atlassian.com/company/careers

For answers to your questions I suggest you consider raising an issue in our service desk portal dedicated for ecosystem developers: 

 https://ecosystem.atlassian.net/servicedesk/customer/portal/14

[Sloan]

Thank you for giving us this opportunity @Cameron Deatsch! :)

When you test a new Confluence Server Release, do you only test with the standard theme or do you try if Themes available on the Marketplace work as well?

How much do you take marketplace apps in account generally when developing and testing Jira, Bitbucket and Confluence Server?

[Cameron Deatsch]

Hey Niklas,

Great question as testing and apps is a constant conversation with our vendors, like you, and our customers.

When we're working on new versions of our products, we test with the standard theme.  The high level of customization inherent in our products makes it hard for us to test every permutation so we focus on the things we control.

However, we do make many versions of our products available to marketplace vendors ahead of general release so they can ensure their apps remain compatible.  We do this when there is a significant change in the release so they have enough time to make any required changes to their apps. We have an early access program available for marketplace vendors for Jira Software 8.0 going right now.

We're always evolving our program with marketplace vendors. If you have specific suggestions I'd love to hear them.

[Sloan]

Hey @Cameron Deatsch

Thanks you so much for getting back to me and explaining how you work this at Server. 👍🏻

In the past our development faced sometimes changes that were not possible to theme even with access to the new versions ahead of public availability. I think communication and contact to dev-support is very important there. :)

For example; At the moment we are unable to theme the new search of Confluence 6.12. DEVHELP-1645, we are hoping they are working on it!

And CONFSERVER-53140 is teasing our customers for some time now.