Build/Deploy revision numbers for couchapps

[Ryan Ramage]

This maybe of interest to general couchapp developers, but maybe more
for couchapp tools (pun intended).

I have reupholster now working so it can be used in a CI server to do
checkout, deploy and test a couchapp.
During couchapp development, I now have a sequence of events that
affect the _design/app revision number. It goes like this:
(I show the rev number of the single design doc in each stage, I hope
you follow)

1.Making a new couchapp
Local Couch | Test Couch | Release Couch |
Users Couch |
_design/app 420 | |
| |

2. Check in. CI server creates a test db, and pushes app. Runs tests. Passes.
Local Couch | Test Couch | Release Couch
| Users Couch |
_design/app 420 | _design/app 420 |
| |

3. Tag and release App
Local Couch | Test Couch | Release Couch
| Users Couch |
_design/app 420 | _design/app 420 | _design/app 420 |
|

4. User Downloads, installs, and begins a pull replication to get
latest updates
Local Couch | Test Couch | Release Couch
| Users Couch |
_design/app 420 | _design/app 420 | _design/app 420 |
_design/app 420 |

5. Dev deletes a bunch of files because of refactoring. On 'push' to a
clean db, the rev is lower.
Local Couch | Test Couch | Release Couch
| Users Couch |
_design/app 390 | _design/app 420 | _design/app 420 |
_design/app 420 |

6. Check in. CI deletes and recreates test couch, and pushes app. Test Pass.
Local Couch | Test Couch | Release Couch
| Users Couch |
_design/app 390 | _design/app 390 | _design/app 420 |
_design/app 420 |

Ok. At this point I would like guidance on what the best approach. We
want the end users couch to get the update, so the revision number
will have to be higher than 420. So to move the couchapp to the
release couch should I have a process that jacks up the revision
number to n+1, and then replicate to the release couch?

Also, a user could also be doing stuff to their _design/app that
increments their revision number and that is out of our control. Any
suggestion on how to detect that scenario?

Thanks for any guidance.

Ryan

[Ryan Ramage]

(I apologize for the poorly formated last email. This approach may be better)

This maybe of interest to general couchapp developers, but maybe more
for couchapp tools (pun intended).

I have reupholster now working so it can be used in a CI server to do
checkout, deploy and test a couchapp.
During couchapp development, I now have a sequence of events that
affect the _design/app revision number. It goes like this:
(I show the rev number of the single design doc in each stage, I hope
you follow)

1.Making a new couchapp
Local Couch : _design/app 420
Test Couch :
Release Couch :
Users Couch :

2. Check in. CI server creates a test db, and pushes app. Runs tests. Passes.

Local Couch : _design/app 420
Test Couch : _design/app 420
Release Couch :
Users Couch :

3. Tag and release App

Local Couch : _design/app 420
Test Couch : _design/app 420
Release Couch : _design/app 420
Users Couch :

4. User Downloads, installs, and begins a pull replication to get
latest updates

Local Couch : _design/app 420
Test Couch : _design/app 420
Release Couch : _design/app 420
Users Couch : _design/app 420

5. Dev deletes a bunch of files because of refactoring. On 'push' to a
clean db, the rev is lower.

Local Couch : _design/app 390
Test Couch : _design/app 420
Release Couch : _design/app 420
Users Couch : _design/app 420

6. Check in. CI deletes and recreates test couch, and pushes app. Test Pass.

Local Couch : _design/app 390
Test Couch : _design/app 390
Release Couch : _design/app 420
Users Couch : _design/app 420