Closed Bug 495326 Opened 15 years ago Closed 15 years ago

set up a parallel production site for the mozilla.com/3.5 launch

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Platform:
All
Other
Type:
task
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jslater, Assigned: oremj)

References

(
URL
)

Details

As discussed offline, we'd like to set up a parallel production site for mozilla.com to make the 3.5 launch go smoother. Instead of pushing a batch of new files to the existing site, we'd rather set up a parallel site and then point the servers to it when it's time to launch 3.5.

This is in response to some of the hiccups we had with the 3.0 launch last year...as part of the launch post-mortem it was agreed that this would be a good thing to do.

As I understand it, Steven Garrity will set up a new branch for all the new content, and then when that's ready oremj will work his magic.

Steven, I'll go with your recommendation as to the timing of getting the new branch set up. Just let us know what you advise for that, and please post any updates here.

Thanks all-
I should note that I don't have the permissions to create an SVN branch (tag?), so I'll need help from a web-dev wizard at Mozilla for this.
Assignee: server-ops → oremj
Assigning to webdev for comment 1.
Assignee: oremj → nobody
Component: Server Operations → Webdev
QA Contact: mrz → webdev
There is a firefox3.5 tag.  Jeremy probably needs to grant permissions.
Assignee: nobody → oremj
Just found out that, due to release scheduling, we need to have this parallel site live by tomorrow (6.25).

Jeremy, Steven - how do we make that happen? Also, we need to make sure Pascal has commit access so he can manage the l10n side of things.
Severity: normal → critical
Is this with webdev still or should it move over to server-ops?
My understanding is that's ready for IT.
Component: Webdev → Server Operations
QA Contact: webdev → mrz
(In reply to comment #6)
> My understanding is that's ready for IT.

It's not, though. There's nothing in http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/tags/firefox3.5/ yet. oremj has nothing to set up...
Reed, can you help us out - I'm not sure we know who has to actually setup the tag. I don't think I have permissions to do it.
(In reply to comment #8)
> Reed, can you help us out - I'm not sure we know who has to actually setup the
> tag. I don't think I have permissions to do it.

Sure, one sec. Who all needs access?
Myself, and probably anyone who has access to Stage.
I need access to this new tag too so as to commit files for localizers and fix general issues for locales
Thanks Reed. We should also make sure Kohei and Jack (cc'd) have access as well, since they'll be building the Japanese and Chinese versions of the site.
(In reply to comment #12)
> Thanks Reed. We should also make sure Kohei and Jack (cc'd) have access as
> well, since they'll be building the Japanese and Chinese versions of the site.

They need read/write access or just read access?
read/write, please
Yo. Access me likey.
(In reply to comment #15)
> Yo. Access me likey.
That means "I'd also like access" in en-CA.
Hey - questions:
- why is there a special tag
- can second vhost just checkout trunk
- after launch we could svn switch to tags/production (after merging trunk)
(In reply to comment #17)
> Hey - questions:
> - why is there a special tag
> - can second vhost just checkout trunk

Good questions. That might work. I think they key goal is to ensure that we're testing exactly what will be live (both in terms of configuration and code).

> - after launch we could svn switch to tags/production (after merging trunk)
I'm off to look up how "svn switch" works.
Another way to go about this is to manually update to a specific revision and avoid having to merge the entire tree over and over.  Probably easier to do than switching.

For example, everyone would agree on r1337, and IT would do svn co -r 1337 /blah/trunk /blah/docrootonprod/
The goal is to have something with real 3.5 download links and version numbers (set in includes/product-details/firefoxDetails.class.php) for QA.

I was thinking something like this (pardon my SVN terminology)

1. Trunk gets pulled Production-3.5
2. Production-3.5 gets setup for QA to test (browsable on a subdomain, LATEST_FIREFOX_VERSION set to 3.5, etc.)
3. A fun weekend of testing...
4. On launch-day, Production-3.5 replaces Production

Does that make sense?
Sure, I'm ok with just copying stuff onto that tag, if that's what you guys want to do -- it'll just take a while to copy over then merge any changes from trunk -> prod-3.5.
(In reply to comment #21)
> Sure, I'm ok with just copying stuff onto that tag, if that's what you guys
> want to do -- it'll just take a while to copy over then merge any changes from
> trunk -> prod-3.5.

Won't prod-3.5 already match trunk?
Hi all. Thanks for the work on this so far. Can anyone give me an ETA of when this will be ready? The mechanics of making it happen are beyond me, but this is critical for the 3.5 launch so we need to start testing on the new site by tomorrow.

Are we still on track for that? What still needs to happen to make that happen?

Thanks much-
Am following up with a few folks offline...let's get this resolved tomorrow morning.

Thanks-
Severity: critical → blocker
Comment 22, should I use trunk or prod-3.5. I'm going to lower the severity on this, so it doesn't page oncall tonight. I'll plan on working on this in the morning.
Severity: blocker → critical
We're going in circles here.  In the morning let's check trunk onto the second vhost since that is simpler and makes it easier to make quick changes than having to do a merge every time there's an update.
Can't reach a consensus about using trunk so:
http://svn.mozilla.org/projects/mozilla.com/tags/firefox3.5/
does it mean that any 3.5 fix to files should be done on /tags/firefox3.5/ now and no longer on trunk? Or both ?
Do them on trunk like usual.
http://mozilla:firefox@ff3-5.mozilla.com/en-US/


Updating from the branch in comment 27.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Thanks!!
(In reply to comment #29)
> Do them on trunk like usual.

Changes should be made in trunk, but will have to be merged to the 3.5 tag as well, right?
Yes. Since we have the special tag anything done on trunk will have to be merged onto the 3.5 tag then updated manually by IT.
This was done; verified fixed.
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.