[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dealing better with CD releases

On Thu, Apr 16, 2009 at 01:28:56PM +0200, Gerfried Fuchs wrote:
>	Hi!


>* Steve McIntyre <steve@einval.com> [2009-04-15 15:36:57 CEST]:
>> We currently potentially have a window of a few hours of breakage, as
>> the web pages that point directly to the old images stay around for
>> quite a while. Even if they are updated directly in $VCS as we do a
>> release, the website is only rebuilt periodically from cron.
> It's not that big of a deal to trigger a manual rebuild of the webpages
>if one of the webmasters is contacted and around for the time, it
>doesn't need to wait for the periodically rebuild from cron. Involving a
>webmaster also solves the problems that we had at lenny release with
>respect to not-tested commits resulting in build problems and not only
>delaying the issue until the next periodically cron run but the one
>after the problem got noticed and fixed.

OK. How long does it take for the web mirrors to update after a cron
run? I'm thinking of *trying* to make all versions of the pages work
for a while if we can...

Yes, I know I'm being awkward. :-)

>> 2. Possible solutions
>>    a. Stop linking directly to the images, and go through a set of
>>       symlinks instead. Potentially messy, and people may get mixed
>>       sets. Probably difficult to set up on mirrors too?
> Yeah, symlinking from hell might solve the issue of broken links but
>raise a lot of other issues indeed - I guess broken links are rather a
>much lower issue than those.

Yup, exactly.

>>    b. Stop linking directly to the images, and go via redirects. Could
>>       maybe be a central cgi, maybe even with intelligence to redirect
>>       to good/close/fast/up-to-date mirrors. Could work, but needs
>>       implementing. :-)
> Sounds like a path that would work very well; but yes, requires work.


>>    c. Do things in stages:
>>       * Copy the old release to the archive area a few days before
>>         release. Add a warning to users that a new build is due, and
>>         they should be careful that their downloaded images are all
>>         from one version.
>>       * Once that archive copy is live, update the links to point to
>>         the archive copy and push the new website.
>>       * On the day of release, release as normal and update the web
>>         pages in $VCS to point to the new release in "release". Remove
>>         the "new build due" warning and add "new build just happened".
>>         After the website is built, new users will see the new images.
>>       * A few days/weeks later, prune the images in the old tree under
>>         "archive". No current pages should be looking here, so we're
>>         just dealing with stragglers.
> Staging is usually a quite save approach but requires better
>coordination which seems to have been problematic the last releases from
>what I perceived. I though would be happy to be proven wrong. ;)

This is what I'm going to try for the next few point releases, I
think. How much effort would it be for the web team to make changes
like this?

Steve McIntyre, Cambridge, UK.                                steve@einval.com
"C++ ate my sanity" -- Jon Rabone

Reply to: