Services/Sync/Server/ReleaseProcess: Difference between revisions
Tarek.ziade (talk | contribs) |
Tarek.ziade (talk | contribs) |
||
| Line 17: | Line 17: | ||
* some Python packages. Right now just one called "weave.server" | * some Python packages. Right now just one called "weave.server" | ||
= Proposal = | = Proposal 1 : release-based = | ||
One simple way to release the weave server is to create a source distribution with all the packages and the ini file, for each version. | |||
This distribution can be installed by the Ops using a distutils-compatible installer like Pip, or the built-in installer Python provides. | |||
The application is installed in the virtualenv-ed Python's site-packages, and the .ini file in /etc/sync.ini, so other apps can use it when needed. | |||
This solution removes the dependency the server to install has with the mercurial repository : an installation is done with static files. | |||
== Release process == | == Release process == | ||
| Line 45: | Line 45: | ||
== Open questions == | == Open questions == | ||
= Proposal 2 : repository based = | |||
XXX see zamboni process (repo based) http://github.com/jbalogh/zamboni-lib/tree/master/packages http://jbalogh.github.com/zamboni/topics/packages/ | |||
Revision as of 10:16, 22 July 2010
Background
Python uses a built-in packaging system that allows packages to get installed in a specific folder called "site-packages", loaded at Python startup. Several installers exists for this. One of them being Python itself.
You can also specify arbitrary folders when a Python application starts, making it possible to group Python packages an application uses in a specific location.
To go further, virtualenv allows you to create a new Python interpreter copied from the main one. This creates an isolated Python environment somewhere on your system. In other words, every package that will be installed by a Python interpreter created by virtualenv, will be installed under a specific tree and not interfer with the main Python installation.
Ideally, the Weave application should be installed in a virtualenv-ed Python in /var/sync for example.
Weave application structure
The Weave application we are building will be organized in three parts
- an .ini file used by the application to start up. It contains all the configuration needed by the weave server, like the location of the DB, etc.
- a .wsgi file used by Apache to run the application
- some Python packages. Right now just one called "weave.server"
Proposal 1 : release-based
One simple way to release the weave server is to create a source distribution with all the packages and the ini file, for each version.
This distribution can be installed by the Ops using a distutils-compatible installer like Pip, or the built-in installer Python provides.
The application is installed in the virtualenv-ed Python's site-packages, and the .ini file in /etc/sync.ini, so other apps can use it when needed.
This solution removes the dependency the server to install has with the mercurial repository : an installation is done with static files.
Release process
Steps to prepare a release:
- run "python setup.py test" to check all tests pass
- tag the version in HG
- run "python setup.py sdist mozupload"
These steps create a .tar.gz release (done by "sdist") and is placed into a shared folder all servers can see (done by "mozupload".)
Installation
Steps to install a release on a server:
- run "pip install path/to/realase/WeaveServer1.1.4.tgz"
- restart apache (or hot restart mode with apache)
Open questions
Proposal 2 : repository based
XXX see zamboni process (repo based) http://github.com/jbalogh/zamboni-lib/tree/master/packages http://jbalogh.github.com/zamboni/topics/packages/