launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #04069
Re: Releasing features when they are done
On Tue, Aug 3, 2010 at 11:40 AM, Robert Collins
<robert.collins@xxxxxxxxxxxxx> wrote:
> This one time, at weekly catchup call, Francis and I spoke about this
> plan ... :)
>
> We both think that its going to take significant time to get all the
> pieces in place, so we're proposing to make this whole thing even more
> incrementally adoptable.
>
I'm going to try to condense this to see if I understand properly.
I'll indent my own clarification questions.
1. Set up a daily staging environment which has stable branch and
production schema.
Kind of like our current staging, but without the unreleased
database changes?
2. Rollout stable to just the appservers only when it's completely QAd
How do we know it's completely QAd?
Is there a facility to roll out just the QAd stuff?
This depends on fixing a deployment icing issue, right?
Does this also depend on a one-button rollout to all appservers script?
3. Get rid of edge. Set up a redirect for legacy edge URLs. Rely on
feature flags to hide in-development features.
Now at this point, how often will we be rolling out production
appserver-only changes? How much downtime does such a rollout cause?
...
> The next steps after that are to iterate on the reliability of doing
> backend rollouts - cronscripts, single points of failure etc - until
> we have just a single revision everywhere.
>
I recommend setting up a bug tag for that.
> At that point, we can start working on the database patch deployment
> story - but expect that to be 2-3 months away for now.
>
It'll be nice to sit at UDS-N and look back over all this work and
know that we've only got the DB left to go.
> I will (honestly!) update the wiki page tomorrow, but I wanted to get
> this proposal out to you guys asap, so you can tell me how its broken!
>
Can't wait :)
jml
Follow ups
References