← Back to team overview

launchpad-dev team mailing list archive

Re: velocity slides on VCS <-> deployment of webapps

 

On Fri, Jul 2, 2010 at 5:44 AM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> wrote:
> On Fri, Jul 2, 2010 at 8:25 PM, Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx> wrote:
>> What do you mean by "broken?"  If you mean "test failure," buildbot
>> catches those.  If you mean, "something does not now work on Launchpad
>> as it should," then I'm not sure I agree that entirely avoiding that
>> condition should be a prerequisite for continuous deployment.  That
>> seems a separate issue, regardless of deployment method.  But maybe
>> you're thinking something else entirely?
>
> So it will depend on what we mean by trunk - and what the slides that
> prompted this thread meant.
>
> If we mean 'stable' or 'db-stable' then by broken I mean 'things that
> we find in QA on edge'. If we mean 'devel' or 'db-devel' then I also
> mean test failures.
>
> Perhaps we'll just accept the risk - I don't think thats unreasonable,
> particularly if we also have rollback mechanisms that are more
> effective than we have today; but I don't think we could do it without
> considering the risks either.
>

Yes, I agree.  That's exactly what I'm arguing -- that the 'things we
find in QA on edge' is an acceptable risk, that we need better
mechanisms for hiding this from lpnet users, that we should find a way
to cut from edge to lpnet anytime we want with confidence.  That's
what I mean about "always ship trunk" and whether we do it by
literally converging on one branch or by some improvement to our
current system is less important to me.  Like Stuart said in his mail,
I think we're actually pretty close now.

Where I think we fail miserably is that we structure everything around
the word "release" and put the weight on the shoulder of the developer
to track where the change is at in the release process.  Is it on
edge, staging, ready for lpnet, or actually on lpnet now?  It's this
that I want to change with the "always ship trunk" mantra.  A
developer should only be thinking -- has my change landed or not?  The
change itself could be a change for a beta tester or something ready
for production, which I think developers can easily mentally track.

Cheers,
deryck



-- 
Deryck Hodge
https://launchpad.net/~deryck
http://www.devurandom.org/



Follow ups

References