723375 - Normalize dev/stage/prod branches/tags for www.mozilla.org content

Status: RESOLVED WONTFIX

(www.mozilla.org :: General, defect)

Description

[Jake Maul [:jakem]]

+++ This bug was initially created as a clone of Bug #721868 +++

Need to move www.allizom.org from mrapp-stage04 to bedrock cluster in phx1 (bedrock-stage, specifically). This should be good to go in Zeus already, and the staging nodes are ready to go as well... just needs the proper checkouts, config files, and DNS changes.

Note that it needs to get a www.allizom.org-django dir on bedrockadm as well.

The simplest way to do this is probably going to be to eschew mrapp-stage04 and just build this natively on bedrockadm by copying things from bedrock-prod or bedrock-dev, both of which are already set up and working there.

There are 3 repo checkouts total:

www.allizom.org - svn
www.allizom.org/org - svn
www.allizom.org-django/bedrock - git

Also note there are 3 config.inc.php files that need included/edited: includes/config.inc.php, org/includes/config.inc.php, org/thunderbird/includes/config.inc.php. There is also settings/local.py on the django side. All are best copied and tweaked from dev or prod... basically on the site name and dir changes in each one... a simple find/replace should do the trick.


I will look into this tomorrow.

Comment 1

[James Long (:jlongster)]

Updated titled.

Comment 2

[Jake Maul [:jakem]]

Note that www.allizom.org (stage) django side needs the GMAP_API_KEY setting from www-dev.allizom.org. Google cares about the 'allizom' part and prod's key won't work.

Comment 4

[Jake Maul [:jakem]]

I'm working on this now. What tags/branches should we be checking out for these 3 repos? 4 I guess if you count the svn locales repo too...

For the moment I'm just cloning bedrock-dev, but we can tweak it all as needed.

Comment 5

[James Long (:jlongster)]

Jake, there should be a tags/stage in all of those repos. Let me know if there's not.

Comment 6

[James Long (:jlongster)]

For the Python side, use master like normal.

Comment 8

[Jake Maul [:jakem]]

There is no tags/stage for the mozilla.org repo... as I recall now, that one is always off of trunk. It does have a branches/staging, but I have no idea how current that is. I've left it on trunk... that suits my memory of things better. :)


This is completed now. www.allizom.org should be fully functional. I have just set up the crons for it as well (identical to prod), so we may start getting emails on it any time now, if anything there is broken.

Comment 9

[Andrei [:sancus]]

branches/staging is current enough that the Thunderbird team uses it regularly to stage changes to that part of the site. Please hook it up :)

With trunk hooked up, there is literally no way to stage changes to the php part of the mozilla.org site without going directly live and I don't think that's okay.

Comment 10

[Jake Maul [:jakem]]

Then we have a problem. Dev and prod both pull from trunk... it doesn't make sense for staging to be different. By the time you get to staging, you should have already gone through dev, which means it's already in trunk, and thus already in prod.

@James, do you care to weigh in on this?


Perhaps it makes sense to move www-dev.allizom.org to use branches/staging as well... but if we want to start doing that then someone should make sure it's current enough for the whole of the branch and not just the /thunderbird/ parts.

Comment 11

[James Long (:jlongster)]

(In reply to Jake Maul [:jakem] from comment #10)
> Then we have a problem. Dev and prod both pull from trunk... it doesn't make
> sense for staging to be different. By the time you get to staging, you
> should have already gone through dev, which means it's already in trunk, and
> thus already in prod.
> 
> @James, do you care to weigh in on this?
> 
> Perhaps it makes sense to move www-dev.allizom.org to use branches/staging
> as well... but if we want to start doing that then someone should make sure
> it's current enough for the whole of the branch and not just the
> /thunderbird/ parts.

Using staging on www-dev sounds like a good idea. It shouldn't make any different to the people who commit straight to trunk, because they use the live site anyway to see those changes.

I'd recommend re-creating the staging branch based off of trunk, and periodically syncing changes in so that the dev site is somewhat kept up to date. sancus, does that sound good?

Comment 12

[Andrei [:sancus]]

(In reply to James Long (:jlongster) from comment #11) 
> I'd recommend re-creating the staging branch based off of trunk, and
> periodically syncing changes in so that the dev site is somewhat kept up to
> date. sancus, does that sound good?

Yep, that sounds fine to me. I have no problem with recreating the staging branch based on trunk. And I agree, I don't see any particular reason in having dev and staging pointing at trunk, because the people who are committing directly to trunk won't use these sites in the first place.

Alternatively, we could try to abolish committing directly to trunk ;)

Comment 13

[Jake Maul [:jakem]]

Okay, I've changed www.allizom.org to use branches/staging for that repo. A *lot* changed, a sync between trunk and staging will definitely be needed.

I want to do the same for www-dev.allizom.org now. Let me know when it's good to proceed with that... I suspect a lot of breakage, so you probably want to sync the branch up first.

Comment 14

[James Long (:jlongster)]

sancus, can you recreate the staging branch? You're better at SVN than me and I want to make sure all the tracking stuff is used correctly.

Once that's done, I say we switch over www-dev.

Comment 15

[Andrei [:sancus]]

Hmm, apparently I lost track of this. James: I'll look at recreating the staging branch next week.

Comment 16

[Kohei Yoshino [:kohei]]

Closing as WONTFIX as we are no longer using the SVN repo.