Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add platform team definition of done #59993

Merged
merged 5 commits into from
Apr 16, 2020
Merged

add platform team definition of done #59993

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
088a006
add platform team definition of done
mshustov Mar 12, 2020
b041d00
add link to ToC
mshustov Mar 12, 2020
a65bb87
add suggestions from Josh
mshustov Mar 19, 2020
1ccac27
add tooling
mshustov Mar 24, 2020
24f08d8
add testing note
mshustov Apr 15, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 37 additions & 11 deletions src/core/CONVENTIONS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,15 +1,41 @@
# Kibana Conventions

- [Kibana Conventions](#kibana-conventions)
- [Organisational Conventions](#organisational-conventions)
- [Definition of done](#definition-of-done)
- [Technical Conventions](#technical-conventions)
- [Plugin Structure](#plugin-structure)
- [The PluginInitializer](#the-plugininitializer)
- [The Plugin class](#the-plugin-class)
- [Applications](#applications)
- [Services](#services)
- [Usage Collection](#usage-collection)
- [Saved Objects Types](#saved-objects-types)

## Plugin Structure
- [Naming conventions](#naming-conventions)

## Organisational Conventions
### Definition of done
Definition of done for a feature:
- has a dedicated Github issue describing problem space
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't that more in the 'Definition of Ready'?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, do we want to have a separate document? We can keep it here for the time being.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keeping it there for now is fine.

- an umbrella task closed/updated with follow-ups
- all code review comments are resolved
- has been verified manually by at least one reviewer
- can be used by first & third party plugins
- there is no contradiction between client and server API
- works for OSS version
- works with and without a `server.basePath` configured
- cannot crash the Kibana server when it fails
- works for the commercial version with a license
- for a logged-in user
- for anonymous user
- compatible with Spaces
mshustov marked this conversation as resolved.
Show resolved Hide resolved
- has unit & integration tests for public contracts
- has functional tests for user scenarios
- uses standard tooling:
- code - `TypeScript`
- UI - `React`
- tests - `jest` & `FTR`
- has documentation for the public contract, provides a usage example

## Technical Conventions
### Plugin Structure

All Kibana plugins built at Elastic should follow the same structure.

Expand Down Expand Up @@ -60,7 +86,7 @@ my_plugin/
- More should be fleshed out here...
- Usage collectors for Telemetry should be defined in a separate `server/collectors/` directory.

### The PluginInitializer
#### The PluginInitializer

```ts
// my_plugin/public/index.ts
Expand All @@ -75,7 +101,7 @@ export {
}
```

### The Plugin class
#### The Plugin class

```ts
// my_plugin/public/plugin.ts
Expand Down Expand Up @@ -130,7 +156,7 @@ Difference between `setup` and `start`:

The bulk of your plugin logic will most likely live inside _handlers_ registered during `setup`.

### Applications
#### Applications

It's important that UI code is not included in the main bundle for your plugin. Our webpack configuration supports
dynamic async imports to split out imports into a separate bundle. Every app's rendering logic and UI code should
Expand Down Expand Up @@ -175,7 +201,7 @@ export class MyPlugin implements Plugin {
}
```

### Services
#### Services

Service structure should mirror the plugin lifecycle to make reasoning about how the service is executed more clear.

Expand Down Expand Up @@ -226,7 +252,7 @@ export class Plugin {
}
```

### Usage Collection
#### Usage Collection

For creating and registering a Usage Collector. Collectors should be defined in a separate directory `server/collectors/`. You can read more about usage collectors on `src/plugins/usage_collection/README.md`.

Expand Down Expand Up @@ -263,7 +289,7 @@ export function registerMyPluginUsageCollector(usageCollection?: UsageCollection
}
```

### Saved Objects Types
#### Saved Objects Types

Saved object type definitions should be defined in their own `server/saved_objects` directory.

Expand Down