2016-02-16 01:29:43 +08:00
|
|
|
# crankshaft
|
|
|
|
|
|
|
|
CartoDB Spatial Analysis extension for PostgreSQL.
|
|
|
|
|
|
|
|
## Code organization
|
|
|
|
|
2016-03-09 02:35:02 +08:00
|
|
|
* *doc* documentation
|
|
|
|
* *src* source code
|
|
|
|
* - *src/pg* contains the PostgreSQL extension source code
|
|
|
|
* - *src/py* Python module source code
|
2016-03-11 02:13:46 +08:00
|
|
|
* *release* reseleased versions
|
2016-03-16 01:48:46 +08:00
|
|
|
* *env* base directory for Python virtual environments
|
2016-02-16 01:29:43 +08:00
|
|
|
|
|
|
|
## Requirements
|
|
|
|
|
2016-03-09 02:35:02 +08:00
|
|
|
* pip, virtualenv, PostgreSQL
|
2016-03-11 02:13:46 +08:00
|
|
|
* python-scipy system package (see src/py/README.md)
|
2016-03-09 02:35:02 +08:00
|
|
|
|
|
|
|
# Working Process
|
|
|
|
|
2016-03-16 01:48:46 +08:00
|
|
|
We use the default `develop` branch as the basis for development.
|
|
|
|
This branch and `master` are maintained by the *Release Manager*.
|
|
|
|
The `master` branch is used to merge and tag releases to be
|
|
|
|
deployed in production.
|
|
|
|
|
|
|
|
In addition to these two permanent branches, temporal *topic*
|
2016-03-16 22:45:13 +08:00
|
|
|
branches must be used for all modifications.
|
2016-03-16 01:48:46 +08:00
|
|
|
|
2016-03-09 02:35:02 +08:00
|
|
|
## Development
|
|
|
|
|
2016-03-16 22:45:13 +08:00
|
|
|
For any modification of crankshaft, including adding new features,
|
|
|
|
a topic branch must be created out of the `develop` branch
|
2016-03-16 01:48:46 +08:00
|
|
|
and be used for the development process; see src/py/README.md
|
2016-03-16 22:45:13 +08:00
|
|
|
for further details about the Pyhton package development.
|
2016-03-11 02:13:46 +08:00
|
|
|
|
2016-03-16 01:48:46 +08:00
|
|
|
Modifications are done inside `src/pg/sql` and `src/py/crankshaft`.
|
2016-03-11 02:13:46 +08:00
|
|
|
Take into account:
|
|
|
|
|
2016-03-16 22:45:13 +08:00
|
|
|
* Test must be added for any new functionality
|
|
|
|
(`src/pg/test`, `src/py/crankshaft/test`) as well as for
|
|
|
|
detected any bugs corrected.
|
2016-03-11 02:13:46 +08:00
|
|
|
* Add or modify the corresponding documentation files in the `doc` folder.
|
|
|
|
Since we expect to have highly technical functions here, an extense
|
|
|
|
background explanation would be of great help to users of this extension.
|
2016-03-16 22:45:13 +08:00
|
|
|
* Convention: snake case(i.e. `snake_case` and not `CamelCase`)
|
|
|
|
shall be used for all function names.
|
|
|
|
Prefix function names intended for public use with `cdb_`
|
2016-03-11 02:13:46 +08:00
|
|
|
and private functions (to be used only internally inside
|
|
|
|
the extension) with `_cdb_`.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-16 22:45:13 +08:00
|
|
|
Once the code is ready to be tested, update the local development installation
|
|
|
|
with `sudo make install`.
|
|
|
|
This will update the 'dev' version of the extension in `src/pg/` and
|
2016-03-16 01:48:46 +08:00
|
|
|
make it available to PostgreSQL.
|
|
|
|
It will also install the python package (crankshaft) in a virtual
|
|
|
|
environment `env/dev`.
|
|
|
|
|
2016-03-16 22:45:13 +08:00
|
|
|
The version number of the Python package, defined in
|
|
|
|
`src/pg/crankshaft/setup.py` will be overridden when
|
|
|
|
the package is released and always match the extension version number,
|
|
|
|
but for development it shall be kept as '0.0.0'.
|
|
|
|
|
|
|
|
Run the tests with `make test`.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-16 01:48:46 +08:00
|
|
|
To use the python extension for custom tests, activate the virtual
|
|
|
|
environment with:
|
|
|
|
|
|
|
|
```
|
|
|
|
source envs/dev/bin/activate
|
|
|
|
```
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-16 01:48:46 +08:00
|
|
|
Update extension in a working database with:
|
2016-03-09 02:35:02 +08:00
|
|
|
|
|
|
|
* `ALTER EXTENSION crankshaft VERSION TO 'current';`
|
|
|
|
`ALTER EXTENSION crankshaft VERSION TO 'dev';`
|
|
|
|
|
|
|
|
Note: we keep the current development version install as 'dev' always;
|
|
|
|
we update through the 'current' alias to allow changing the extension
|
|
|
|
contents but not the version identifier. This will fail if the
|
|
|
|
changes involve incompatible function changes such as a different
|
|
|
|
return type; in that case the offending function (or the whole extension)
|
|
|
|
should be dropped manually before the update.
|
|
|
|
|
2016-03-16 22:45:13 +08:00
|
|
|
If the extension has not previously been installed in a database,
|
|
|
|
it can be installed directly with:
|
2016-03-09 02:35:02 +08:00
|
|
|
|
|
|
|
* `CREATE EXTENSION crankshaft WITH VERSION 'dev';`
|
|
|
|
|
2016-03-16 22:45:13 +08:00
|
|
|
Note: the development extension uses the development python virtual
|
2016-03-16 01:48:46 +08:00
|
|
|
environment automatically.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-16 22:45:13 +08:00
|
|
|
Once the tests are succeeding a new Pull-Request can be created
|
|
|
|
to the develop branch. CI-tests must be checked to be successful.
|
|
|
|
|
|
|
|
Before proceeding to the release process peer code reviewing of the code is
|
|
|
|
a must.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-16 22:45:13 +08:00
|
|
|
When the code is accepted by the peer reviewing (and CI tests succeed)
|
|
|
|
a request for release will be send to the Release Manager.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-11 02:13:46 +08:00
|
|
|
## Release
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-11 02:13:46 +08:00
|
|
|
The release process of a new version of the extension
|
2016-03-16 22:45:13 +08:00
|
|
|
shall be performed by the designated *Release Manager*.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-16 01:48:46 +08:00
|
|
|
Note that we expect to gradually automate more of this process.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-16 01:48:46 +08:00
|
|
|
Having checked the topic branch of the PR to be released it shall be
|
|
|
|
merged back into the `develop` branch to prepare the new release.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-11 02:13:46 +08:00
|
|
|
The version number in `pg/cranckshaft.control` must first be updated.
|
|
|
|
To do so [Semantic Versioning 2.0](http://semver.org/) is in order.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-16 01:48:46 +08:00
|
|
|
Thew `NEWS.md` will be updated.
|
|
|
|
|
2016-03-11 02:13:46 +08:00
|
|
|
We now will explain the process for the case of backwards-compatible
|
|
|
|
releases (updating the minor or patch version numbers).
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-11 02:13:46 +08:00
|
|
|
TODO: document the complex case of major releases.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-11 02:13:46 +08:00
|
|
|
The next command must be executed to produce the main installation
|
2016-03-16 01:48:46 +08:00
|
|
|
script for the new release, `release/cranckshaft--X.Y.Z.sql` and
|
|
|
|
also to copy the python package to `release/python/X.Y.Z/crankshaft`.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-11 02:13:46 +08:00
|
|
|
```
|
|
|
|
make release
|
|
|
|
```
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-11 02:13:46 +08:00
|
|
|
Then, the release manager shall produce upgrade and downgrade scripts
|
|
|
|
to migrate to/from the previous release. In the case of minor/patch
|
|
|
|
releases this simply consist in extracting the functions that have changed
|
|
|
|
and placing them in the proper `release/cranckshaft--X.Y.Z--A.B.C.sql`
|
|
|
|
file.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-16 01:48:46 +08:00
|
|
|
The new release can be deployed for staging/smoke tests with this command:
|
|
|
|
|
|
|
|
```
|
|
|
|
sudo make deploy
|
|
|
|
```
|
|
|
|
|
2016-03-16 22:45:13 +08:00
|
|
|
This will copy the current 'X.Y.Z' released version of the extension to
|
|
|
|
PostgreSQL. The corresponding Python extension will be installed in a
|
|
|
|
virtual environment in `envs/X.Y.Z`.
|
2016-03-16 01:48:46 +08:00
|
|
|
|
|
|
|
It can be activated with:
|
|
|
|
|
|
|
|
```
|
|
|
|
source envs/X.Y.Z/bin/activate
|
|
|
|
```
|
|
|
|
|
|
|
|
But note that this is needed only for using the package directly;
|
|
|
|
the 'X.Y.Z' version of the extension will automatically use the
|
|
|
|
python package from this virtual environment.
|
|
|
|
|
|
|
|
The `sudo make deploy` operation can be also used for installing
|
|
|
|
the new version after it has been released.
|
|
|
|
|
2016-03-16 22:45:13 +08:00
|
|
|
To install a specific version 'X.Y.Z' different from the current one
|
|
|
|
(which must be present in `releases/`) you can:
|
|
|
|
|
|
|
|
```
|
|
|
|
sudo make deploy RELEASE_VERSION=X.Y.Z
|
|
|
|
```
|
|
|
|
|
2016-03-16 01:48:46 +08:00
|
|
|
TODO: testing procedure for the new release.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-16 01:48:46 +08:00
|
|
|
TODO: procedure for staging deployment.
|
2016-03-09 02:35:02 +08:00
|
|
|
|
2016-03-16 01:48:46 +08:00
|
|
|
TODO: procedure for merging to master, tagging and deploying
|
|
|
|
in production.
|
2016-03-16 22:56:19 +08:00
|
|
|
|
|
|
|
## Relevant tasks available in the Makefile
|
|
|
|
|
|
|
|
```
|
|
|
|
* `make help` show a short description of the available targets
|
|
|
|
|
|
|
|
# Development tasks
|
|
|
|
|
|
|
|
* `sudo make install` will generate the extension scripts for the development
|
|
|
|
version ('dev'/'current') and install the python package into the
|
|
|
|
development virtual environment `envs/dev`.
|
|
|
|
Intended for use by developers.
|
|
|
|
|
|
|
|
* `make test` will run the tests for the installed development extension.
|
|
|
|
Intended for use by developers.
|
|
|
|
|
|
|
|
# Release tasks
|
|
|
|
|
|
|
|
* `make release` will generate a new release (version number defined in
|
|
|
|
`src/pg/crankshaft.control`) into `release/`.
|
|
|
|
Intended for use by the release manager.
|
|
|
|
|
|
|
|
* `sudo make deploy` will install the current release X.Y.Z from the
|
|
|
|
`release/` files into PostgreSQL and a Python virtual environment
|
|
|
|
`envs/X.Y.Z`.
|
|
|
|
Intended for use by the release manager and deployment jobs.
|
|
|
|
|
|
|
|
* `sudo make deploy RELEASE_VERSION=X.Y.Z` will install specified version
|
|
|
|
previously generated in `release/`
|
|
|
|
into PostgreSQL and a Python virtual environment `envs/X.Y.Z`.
|
|
|
|
Intended for use by the release manager and deployment jobs.
|
|
|
|
```
|