Project

General

Profile

DjHDGutilsPatchManager » History » Revision 5

Revision 4 (Alex V Koval, 08/09/2012 03:09 PM) → Revision 5/7 (Alex V Koval, 08/09/2012 03:11 PM)

h1. DjHDGutilsPatchManager 

 h2. patch 

 h3. Introduction 

 PatchManager makes it easy to support large scale project migrations in the well controlled manner. 
 Patches can be different types, namely: 

  * .sql 
  * .py 

 and they are run in sequentual manner one after one. The migrations are made that way that several developers 
 in a different branches can run their patches, merge them without conflicts (a random number at the end of the 
 patch name makes it low probability to patch names to interfere) and test well before going to production. 

 h3. Patch names 

 Patches can be named automatically that is for *next* command is made: 

 <pre> 
 (env)djyp $ ./manage.py patch next 
 File /someproject/migrations/00636-avk-654.sql has been created 
	 size: 0 
 </pre> 

 Filename consists from: 

  * 00636 - patch number 
  * avk - developer name 
  * 654 - the random part to ensure that patch names do not interfer with same developer different branch 

 h3. Commands 

 * *list* - list pending patches 
 * *install* - install PatchManager track model table 
 * *up* - update project to latest migration 
 * *skip* - skip specific patch 
 * *next* - auto-generate the next available patch name 

 h3. Compare to other systems 

 Most of other systems differ by their primary usage. South for example mainly used for distributed project support. Our system 
 is simple and straightforward to use, we always know what patch is going to be installed on a production database. 
 And so our advantages: 

  * Very simple, robust, reliable application 
  * No conflicts during merge 


 h3. Typical migrate session 

 In a typical usage session you do 2 things:  

  * expect what patches are pending 
  * apply them 

 Or even just directly apply them, as we usually do in our upgrade scripts. 

 <pre> 
 ./manage.py patch list 
 ./manage.py patch up 
 </pre>