Re: Dealing better with CD releases
On Thu, Apr 16, 2009 at 01:28:56PM +0200, Gerfried Fuchs wrote:
> Hi!
Hey!
>* 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.
Yup.
>> 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: