[DISCUSS] Developer pain points

[stacey-gammon]

Lets identify difficulties and roadblocks engineers or contributors face when attempting to write code to Kibana, so we can figure out how to improve the process.

To start off, I'll throw some into the mix:

• Documentation (More on this here: [DISCUSS] Where to put development docs? #21269)
  • Unclear where to search for documentation.
  • Often out of date.
• Flaky CI is disruptive to seasoned Elastic engineers, it would be even more so to contributors who could be forced to spend a lot of time digging into failures only to eventually realize they are flaky.
• Writing functional tests is not easy or intuitive. Some examples:
  • Many different styles used throughout existing code because some of it is very out of date.
  • Inconsistent use and unclear role of timeout (retry.tryForTime(), retry.try(), retry.tryMethod(), common.sleep())
  • Services vs page objects confusion

cc @trevan, @fbaligand, @havidarou - care to add your experiences?

[havidarou]

Hi all,

I would say the two biggest roadblocks I face while developing are:

• Lack of documentation.
• Fast rate of code change.

I would say both are related as you are changing several core things in Kibana, thus making documentation a somewhat futile effort.

For me, aside of adding clearer documentation, also including what is deprecated and a general sense of where is certain aspect of Kibana heading to would greatly aid to write code.

Hope that helps.

Regards.

[trevan]

I agree with @havidarou on the "Fast rate of code change". This has been problematic for a long time with Kibana. Sometimes, the exact same piece is refactored every single release (big number metric vis, anyone?).

[bgaddis56]

I just started contributing code and have had a few issues myself. First I have to say my background is using Microsoft visual studio on windows using VB.net and IIS so going to developing on a Mac using visual studio code and node.js with some angular and react thrown in could be the reason for some of my issues.

I started with the the contributing to kibana document and was able to get my development environment up and running relatively easily but had simple issues like the link to install Yarn tells me to install homebrew which there is no mention of in the documentation. A simple note that says use homebrew would help.

Once I had the development environment set I tried to set up server side debugging in Visual Studio code and was able to get it partially working, I could set breakpoints in some files but not others. I was never able to get this working so I fell back to logging to the console using logger.debug. Having the ability to debug server code would help tremendously allowing me to look at the call stack and see where the call came from and step though to see where its going. Without this I need to know where to put my logger calls and following the code via the folder structure and finding where calls came from and are going to has been difficult.

My next step then was to try and figure out where my change would go so I started with the generate PDF button on the dashboard/reporting page and found that the code was posting a URL to the server. It should have been simple to figure out where a URL goes but not knowing node.js well I had to do some research and found that routing seemed to be the way node.js got you to the starting code for a URL. So I did a search for routing and got 38 results in 36 files. So not understanding routing i wasn't able to figure it out. So some documentation on how kibana handles routing and how to get from a URL to a location in the code would be great.

Since I wasn't able to find my starting location in the code I started searching the code for generate PDF and found where the code was eventually getting to and added logging into this to see what properties were available and what they were. Again the ability to debug real time and see these properties real time would help tremendously.

I then started to try and find all references that called a particular method or to see what properties were were used where and since most properties and methods are not typed this didn't seem to consistently work well. So having everything typed would help as well.

Then I reverted back to searching for method and property names and found files that seemed to be pertinent but only a few of the files had any documentation in them saying what the file was used for or what a method or property was used for. Some documentation in the files would help here as well.

At this point I think I have found where my change should go on the server and will now start looking at the client code to see where I can pass in my new parameters. This is where I have to start learning something about react and angular.

Sorry for the long rant but thought it might help future contributors.

[mattkime]

I broke out testing issues into its own issues, sidestepping flaky test - #24863

[fbaligand]

Hi,

As a plugin developer, here are my pain points:

• I have to publish a plugin package for each <major.minor.patch> Kibana version. As I keep compatibility for each 6.x version for my plugin, I have to generate dozens of package on github each time I release the plugin (Example here: https://github.com/fbaligand/kibana-enhanced-table/releases/tag/v0.8.1)
  Given that each patch releases does not bring breaking changes (contrary to minor releases), this would be great that Kibana requires only a plugin version for each Kibana minor version!
  For example, one plugin version for all Kibana 6.5.x versions.
  This would be less painless for plugin developers and less disturbing/complicated for plugin users.
  BTW, not all plugin developers take the time to release a plugin for each Kibana patch version, that can frustrating for Kibana users, and forces them to get stuck with one Kibana version.

• Second point: Kibana compilation time. To build Kibana, it takes about 10 minutes on my computer, which is quite long.

• Regularly, Kibana considers all files should be reloaded, which led to a big waste of time (issue [dev mode] Kibana regularly considers (wrongly) that all source files have changed and continuously restart #22859)

• Finally, at each minor version, there are several breaking changes, that imply to have a branch per minor version if a plugin developer want to maintain his plugin for each minor version. This is lot of work. And this could discourage some plugin developers to create or maintain a plugin.

[mattkime]

This thread is asking 'where does it hurt?' - which will largely be influence by what people have worked on recently and what they "own." This will differ greatly from person to person, as it should, but it can hard to find direction from it.

Alternatively, we could form a definition of what it means to develop Kibana and focus on refining various workflows. The work on CI is a good example of refining a particular workflow aspect.

What would be a good 'Hello world' for working on Kibana? Do the existing tools and docs help to facilitate those tasks?

[jinmu03]

@stacey-gammon would you like to close this issue? Platform and Operations are tracking Kibana developer-experience related issues here: #70733. It is a very thorough list.

[stacey-gammon]

Sg!