Confirmed users
927
edits
Services/Sync/Server/ReleaseProcess: Difference between revisions
Jump to navigation
Jump to search
→Proposal 2 : repository based
Tarek.ziade (talk | contribs) |
Tarek.ziade (talk | contribs) |
||
| Line 65: | Line 65: | ||
Ideally, the simplest way would be to have a small app to switch to, that would return X-Weave-Backoff to all requests (or maybe a new header X-Weave-Maintenance) while the real server is being updated. | Ideally, the simplest way would be to have a small app to switch to, that would return X-Weave-Backoff to all requests (or maybe a new header X-Weave-Maintenance) while the real server is being updated. | ||
= Proposal 2 : repository based = | = Proposal 2 : repository-based, like Zamboni = | ||
Zamboni uses a repo-based strategy in a virtualenv-ed Python, where the production does "hg pull -rTheRightChangeset" to get everything in the local folder (the app code and the dependencies) and then runs a "pip install" in it. | |||
Dependencies are pushed in a specific vendor repository: http://github.com/jbalogh/zamboni-lib and are pulled like the application. | |||
See also http://jbalogh.github.com/zamboni/topics/packages for more details. | |||
This strategy means that every node has to have an access to the repository, and run hg. The big advantage is that Sync will be like SUMO and AMO, from an OPs point of view. | |||
Although, maintaining the vendor repository is a bit tedious, knowing that the dependencies we will use already have ready-to-install distributions. | |||