Fabfilepy default procedures » History » Version 2
Alex V Koval, 08/09/2012 03:25 PM
1 | 2 | Alex V Koval | h1. fabfile.py automation for repeating maintenance tasks |
---|---|---|---|
2 | 1 | Alex V Koval | |
3 | In our company we have automated a lot of project life cycle repeating actions. Most of them are straightforward & easy to use. |
||
4 | |||
5 | h3. get_db, reinst_db |
||
6 | |||
7 | In most of projects we implement get_db and reinst_db scripts. First one downloads the most recent copy of the production database, |
||
8 | 2nd command installs it. Typically the end user-developer needs to run this to get his project fully updated: |
||
9 | |||
10 | <pre> |
||
11 | hg pull -uv |
||
12 | fab get_db reinst_db depup patch |
||
13 | </pre> |
||
14 | |||
15 | And usually in most of projects all this gets combined in a single command: |
||
16 | <pre> |
||
17 | fab up |
||
18 | </pre> |
||
19 | |||
20 | which implements the following: |
||
21 | - *hgup* - (hg pull --update) - update to most recent source code |
||
22 | - *get_db* - download latest production database |
||
23 | - *reinst_db* - drop & reinstall current database from latest backup made |
||
24 | - *depup* -update external source dependencies |
||
25 | - *patch* - apply migration patches to the project |
||
26 | |||
27 | And so Fabric abstracts it on a higher level, and makes developer life easier. |
||
28 | |||
29 | h3. produp |
||
30 | |||
31 | Additionally on every production server the 'produp' procedure gets implemented. It is very similar to |
||
32 | 'up' procedure explained above, but it also includes step to reload / restart production service software |
||
33 | and update required files (for example static files). |
||
34 | |||
35 | And so, <pre>fab produp</pre> consists from: |
||
36 | |||
37 | * hgup |
||
38 | * depup |
||
39 | * patch |
||
40 | * prod_reload |
||
41 | * ./manage.py collectstatic |