DjHDGutilsPatchManager » History » Version 1
Alex V Koval, 08/09/2012 11:53 AM
| 1 | 1 | Alex V Koval | h1. DjHDGutilsPatchManager |
|---|---|---|---|
| 2 | |||
| 3 | h2. patch |
||
| 4 | |||
| 5 | h3. Introduction |
||
| 6 | |||
| 7 | PatchManager makes it easy to support large scale project migrations in the well controlled manner. |
||
| 8 | Patches can be different types, namely: |
||
| 9 | |||
| 10 | * .sql |
||
| 11 | * .py |
||
| 12 | |||
| 13 | and they are run in sequential manner one after one. The migrations are made that way that several developers |
||
| 14 | in a different branches can run their patches, merge them without conflicts (a random number at the end of the |
||
| 15 | patch name makes it low probability to patch names to interfere) and test well before going to production. |
||
| 16 | |||
| 17 | And so advantages of this system: |
||
| 18 | |||
| 19 | * predictable & reliable |
||
| 20 | * allows development in multiple branches in team |
||
| 21 | * easy to use |
||
| 22 | |||
| 23 | |||
| 24 | h3. Patch names |
||
| 25 | |||
| 26 | Patches can be named automatically that is for *next* command is made: |
||
| 27 | |||
| 28 | <pre> |
||
| 29 | (env)djyp $ ./manage.py patch next |
||
| 30 | File /someproject/migrations/00636-avk-654.sql has been created |
||
| 31 | size: 0 |
||
| 32 | </pre> |
||
| 33 | |||
| 34 | Filename consists from: |
||
| 35 | |||
| 36 | * 00636 - patch number |
||
| 37 | * avk - developer name |
||
| 38 | * 654 - the random part to ensure that patch names do not interfer with same developer different branch |
||
| 39 | |||
| 40 | h3. Commands |
||
| 41 | |||
| 42 | h1. DjHDGutilsPatchManager |
||
| 43 | |||
| 44 | h2. patch |
||
| 45 | |||
| 46 | h3. Introduction |
||
| 47 | |||
| 48 | PatchManager makes it easy to support large scale project migrations in the well controlled manner. |
||
| 49 | Patches can be different types, namely: |
||
| 50 | |||
| 51 | * .sql |
||
| 52 | * .py |
||
| 53 | |||
| 54 | and they are run in sequentual manner one after one. The migrations are made that way that several developers |
||
| 55 | in a different branches can run their patches, merge them without conflicts (a random number at the end of the |
||
| 56 | patch name makes it low probability to patch names to interfere) and test well before going to production. |
||
| 57 | |||
| 58 | h3. Patch names |
||
| 59 | |||
| 60 | Patches can be named automatically that is for *next* command is made: |
||
| 61 | |||
| 62 | <pre> |
||
| 63 | (env)djyp $ ./manage.py patch next |
||
| 64 | File /someproject/migrations/00636-avk-654.sql has been created |
||
| 65 | size: 0 |
||
| 66 | </pre> |
||
| 67 | |||
| 68 | Filename consists from: |
||
| 69 | |||
| 70 | * 00636 - patch number |
||
| 71 | * avk - developer name |
||
| 72 | * 654 - the random part to ensure that patch names do not interfer with same developer different branch |
||
| 73 | |||
| 74 | h3. Commands |
||
| 75 | |||
| 76 | * list - list pending patches |
||
| 77 | * install - install PatchManager track model table |
||
| 78 | * up - update project to latest migration |
||
| 79 | * skip - skip specific patch |
||
| 80 | * next - auto-generate the next available patch name |
||
| 81 | |||
| 82 | h3. Compare to other systems |
||
| 83 | |||
| 84 | Most of other systems differ by their primary usage. South for example mainly used for distributed project support. Our system |
||
| 85 | is simple and straightforward to use, we always know what patch is going to be installed on a production database. |