Skip to content

Commit 73200e9

Browse files
committed
Procedure and documentation for release process
Also, minor cleanup of other docs.
1 parent fbcd4b1 commit 73200e9

File tree

3 files changed

+82
-20
lines changed

3 files changed

+82
-20
lines changed

docs/devel/README.md

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2,5 +2,6 @@
22

33
The developer guide is for anyone wanting to contribute code to Dashboard
44

5-
## Setup
6-
* Getting started ([getting-started.md](getting-started.md))
5+
## Index
6+
* Getting started guide ([getting-started.md](getting-started.md))
7+
* Release process ([release.md](release.md))

docs/devel/getting-started.md

Lines changed: 45 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,10 @@ This document describes how to setup your development environment.
44

55
## Architecture Overview
66

7-
Kubernetes Dashboard project consists of two main components. They are called here the frontend and the backend. The frontend is a single page web application that runs in a browser. It fetches all its business data from the backend using standard HTTP methods. The backend implements UI-business logic and fetches raw data from the various Kubernetes APIs.
7+
Kubernetes Dashboard project consists of two main components. They are called here the frontend and
8+
the backend. The frontend is a single page web application that runs in a browser. It fetches all
9+
its business data from the backend using standard HTTP methods. The backend implements UI-business
10+
logic and fetches raw data from the various Kubernetes APIs.
811

912
## Preparation
1013

@@ -23,45 +26,60 @@ $ npm install
2326

2427
## Run a Kubernetes Cluster
2528

26-
For development it is recommended to run a local Kubernetes cluster. For your convenience, a task is provided that checks out the latest stable version, and runs it inside a Docker container. Open a separate tab in your terminal and run the following command:
29+
For development it is recommended to run a local Kubernetes cluster. For your convenience, a
30+
task is provided that checks out the latest stable version, and runs it inside a Docker container.
31+
Open a separate tab in your terminal and run the following command:
2732

2833
```
2934
$ gulp local-up-cluster
3035
```
3136

32-
This will build and start a lightweight local cluster, consisting of a master and a single node. All processes run locally, in Docker container. The local cluster should behave like a real cluster, however, plugins like heapster are not installed. To shut it down, type the following command that kills all running Docker containers:
37+
This will build and start a lightweight local cluster, consisting of a master and a single node.
38+
All processes run locally, in Docker container. The local cluster should behave like a real
39+
cluster, however, plugins like heapster are not installed. To shut it down, type the following
40+
command that kills all running Docker containers:
3341

3442
```
3543
$ docker kill $(docker ps -aq)
3644
```
3745

38-
From time to time you might want to use to a real Kubernetes cluster (e.g. GCE, Vagrant) instead of the local one. The most convenient way is to create a proxy. Run the following command instead of the gulp task from above:
46+
From time to time you might want to use to a real Kubernetes cluster (e.g. GCE, Vagrant) instead
47+
of the local one. The most convenient way is to create a proxy. Run the following command instead
48+
of the gulp task from above:
3949
```
4050
$ kubectl proxy --port=8080
4151
```
42-
kubectl will handle authentication with Kubernetes and create an API proxy with the address `localhost:8080`. Therefore, no changes in the configuration are required.
52+
kubectl will handle authentication with Kubernetes and create an API proxy with the address
53+
`localhost:8080`. Therefore, no changes in the configuration are required.
4354

4455
## Serving Dashboard for Development
4556

4657
It is easy to compile and run Dashboard. Open a new tab in your terminal and type:
4758
```
4859
$ gulp serve
4960
```
50-
Open a browser and access the UI under `localhost:9090`. A lot of things happened underneath. Let's scratch on the surface a bit.
61+
Open a browser and access the UI under `localhost:9090`. A lot of things happened underneath.
62+
Let's scratch on the surface a bit.
5163

5264
Compilation:
5365
* Stylesheets are implemented with SASS and compiled to CSS with libsass
54-
* JavaScript is implemented in ES6. It is compiled with Babel for development and the Google-Closure-Compiler for production.
55-
* Go is used for the implementation of the backend. The source code gets compiled into the single binary 'dashboard'
66+
* JavaScript is implemented in ES6. It is compiled with Babel for development and the
67+
Google-Closure-Compiler for production.
68+
* Go is used for the implementation of the backend. The source code gets compiled into the
69+
single binary 'dashboard'
5670

5771

5872
Execution:
59-
* Frontend is served by BrowserSync. It enables features like live reloading when HTML/CSS/JS change and even synchronize scrolls, clicks and form inputs across multiple devices.
73+
* Frontend is served by BrowserSync. It enables features like live reloading when
74+
HTML/CSS/JS change and even synchronize scrolls, clicks and form inputs across multiple devices.
6075
* Backend is served by the 'dashboard' binary.
6176

62-
File watchers listen for source code changes (CSS, JS, GO) and automatically recompile. All changes are instantly reflected, e.g. by automatic process restarts or browser refreshes. The build artifacts are created in a hidden folder (`.tmp`).
77+
File watchers listen for source code changes (CSS, JS, GO) and automatically recompile.
78+
All changes are instantly reflected, e.g. by automatic process restarts or browser refreshes.
79+
The build artifacts are created in a hidden folder (`.tmp`).
6380

64-
After successful execution of `gulp local-up-cluster` and `gulp serve`, the following processes should be running (respective ports are given in parentheses):
81+
After successful execution of `gulp local-up-cluster` and `gulp serve`, the following processes
82+
should be running (respective ports are given in parentheses):
6583

6684
BrowserSync (9090) ---> Dashboard backend (9091) ---> Kubernetes API server (8080)
6785

@@ -72,14 +90,16 @@ The Dashboard project can be built for production by using the following task:
7290
```
7391
$ gulp build
7492
```
75-
The code is compiled, compressed and debug support removed. The artifacts can be found in the `dist` folder.
93+
The code is compiled, compressed and debug support removed. The artifacts can be found
94+
in the `dist` folder.
7695

7796
In order to serve Dashboard from the `dist` folder, use the following task:
7897

7998
```
8099
$ gulp serve:prod
81100
```
82-
Open a browser and access the UI under `localhost:9090.` The following processes should be running (respective ports are given in parentheses):
101+
Open a browser and access the UI under `localhost:9090.` The following processes should
102+
be running (respective ports are given in parentheses):
83103

84104

85105
Dashboard backend (9090) ---> Kubernetes API server (8080)
@@ -90,23 +110,30 @@ In order to package everything into a ready-to-run Docker image, use the followi
90110
```
91111
$ gulp docker-image:canary
92112
```
93-
You might notice that the Docker image is very small and requires only a few MB. Only Dashboard assets are added to a scratch image. This is possible, because the `dashboard` binary has no external dependencies. Awesome!
113+
You might notice that the Docker image is very small and requires only a few MB. Only
114+
Dashboard assets are added to a scratch image. This is possible, because the `dashboard`
115+
binary has no external dependencies. Awesome!
94116

95117
## Run the Tests
96-
Unit tests should be executed after every source code change. The following task makes this a breeze by automatically executing the unit tests after every save action.
118+
Unit tests should be executed after every source code change. The following task makes this
119+
a breeze by automatically executing the unit tests after every save action.
97120

98121
```
99122
$ gulp test:watch
100123
```
101-
The full test suite includes static code analysis, unit tests and integration tests. It can be executed with:
124+
The full test suite includes static code analysis, unit tests and integration tests.
125+
It can be executed with:
102126
```
103127
$ gulp check
104128
```
105129

106130
## Building Dashboard Inside a Container
107131

108-
It's possible to run `gulp` and all the dependencies inside a development container. To do this, just replace `gulp [some arg]` commands with `build/run-gulp-in-docker.sh [some arg]`. If you do this, the only dependency is `docker`, and required commands such as `npm install` will be run automatically.
132+
It's possible to run `gulp` and all the dependencies inside a development container. To do this,
133+
just replace `gulp [some arg]` commands with `build/run-gulp-in-docker.sh [some arg]`. If you
134+
do this, the only dependency is `docker`, and required commands such as `npm install`
135+
will be run automatically.
109136

110137
## Contribute
111138

112-
Wish to contribute !! Great start [here](../../CONTRIBUTING.md).
139+
Wish to contribute? Great, start [here](../../CONTRIBUTING.md).

docs/devel/release.md

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
# Introduction
2+
3+
This document describes Kubernetes Dashboard release procedure and version maintenance.
4+
5+
## Release procedure
6+
7+
So you want to release a new version of Kubernetes Dashboard? Great, you just need to follow
8+
the steps below.
9+
10+
1. Send a pull request that increases Kubernetes Dashboard version number in `build/conf.js`.
11+
The property name is `deploy.versionRelease`. Follow versioning guidelines.
12+
1. Get the pull request reviewed and merged.
13+
1. Create a git [release tag](https://github.com/kubernetes/dashboard/releases/) for the merged
14+
pull request. Release description should include changelog.
15+
1. Build and push production images to container registry. Use `gulp push-to-gcr:release`.
16+
1. Update addons on the Kubernetes core repository. Dashboard addon directory is
17+
[here](https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/dashboard). If
18+
the update is minor, all that needs to be done is to change image version number in the main
19+
controller config file (`dashboard-controller.yaml`), and other configs, as described in
20+
the header of the config. If the release is major, this needs coordination with
21+
Kubernetes core team and possibly alignment with the schedule of the core.
22+
23+
## Versioning guidelines
24+
25+
Kubernetes Dashboard versioning follows [semver](http://semver.org/) in spirit. This means
26+
that is uses `vMAJOR.MINOR.PATCH` version numbers, but uses UX and consumer-centric approach for
27+
incrementing version numbers.
28+
29+
1. Increment MAJOR when there are breaking changes that affect user's workflows or the UX gets
30+
major redesign.
31+
1. Increment MINOR when new functionality is added or there are minor UX changes.
32+
1. Increment PATCH in case of bug fixes and minor new features.
33+
34+
Versions `0.X.Y` are reserved for initial development and may not strictly follow the guidelines.

0 commit comments

Comments
 (0)