launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #03726
Re: velocity slides on VCS <-> deployment of webapps
On Fri, Jul 2, 2010 at 8:16 PM, Julian Edwards <ed@xxxxxxxxxxxxxxxxxx> wrote:
> On Friday 02 July 2010 11:44:50 Robert Collins wrote:
>> @Julian If we only rollout one branch, and we develop on the same
>> branch,and we have a DB change, where does it go, how does it get
>> controlled, how do we make it work? Not necessarily a hard problem,
>> but not solved just by having one branch.
>
> Sure, I didn't say it would be straightforward, I was just pointing out why we
> need to worry about maintaining 2 branches.
We would have two branches - devel and stable (we could do it with
one, but it is nice having a trunk guaranteed to have the tests
passing).
A branch with DB changes would land on trunk along with the code that
makes things work with the current production schema and the devel
schema.
The test suite would be run twice, once against the production db
schema and once against the devel schema. On success, devel is merged
to stable.
There would need to be some sort of mechanism of recording what code
needs to be removed after a given DB patch is rolled out. These
reminders would need to be followed up on in a timely fashion or we
drown in a tangle of legacy code.
Rollouts are done from stable. For any given rollout, it is optional
if DB patches are applied or not. If DB patches are applied, the
updated production schema needs to be backported to the tree.
I don't like this because it doesn't gain us anything. It would allow
us to rollout to some systems but not others, but I don't think we
have enough servers that this is necessary - we don't have hundreds or
thousands of servers, and if pushing code to systems and restarting
them is a hassle there are much simpler ways of making this less of a
hassle. It also increases the complexity of our code, and limits our
ability to make some changes (there will be cases where it will just
be impractical to have code work with both old schema and new schema,
so the desirable change gets compromised down to the practical
change).
I don't see anything stopping us from tossing our monthly cycle and
deploying stable or db-stable to lpnet more often - I think that is
just QA and LOSA time issues.
--
Stuart Bishop <stuart@xxxxxxxxxxxxxxxx>
http://www.stuartbishop.net/
References