Quick overview of mozilla.com publishing process
(apologies in advance to anyone without an LDAP account. A lot of the links here point to content behind authentication. If you're really curious about what's going on back there, you're welcome to check out the Kubla source.)
Over the past couple of days I've felt a growing confusion about how the web infrastructure works on www.mozilla.com. People are beginning to use Kubla (it's started with a small set and is steadily growing), and they're asking some good questions that hopefully I can help answer here:
Firstly, I think everyone with access has already seen this diagram, but bear with me:
Fresh changes are committed to the first (top) tier - also referred to as "trunk". If you're making the change yourself you're actually affecting this tier. You can preview any of the changes from the first tier on www-trunk.stage.mozilla.com.
The second tier (also known as "stage" or "staging") is where changes are previewed before they are pushed live. When something is pushed from trunk to stage it will be on this second tier and viewable at www.stage.mozilla.com. To get to this tier, a change needs to be approved by a human (a publisher in Kubla). If you have access and you want to see the differences between trunk and staging, look at the staging queue.
The final tier is our live site (or "production"). Anything pushed on to this tier will be on www.mozilla.com within an hour, automatically. To get to this tier, a change needs to be approved by an admin in Kubla. The differences between the staging site and the live site can be seen in the production queue.
One of the main things to remember is that changes are not instantaneous. Moving a change from trunk to stage and stage to production both require human interaction. The staging site and the production site are updated periodically (Kubla shows an estimated time to next update on the left hand menu when you log in). For production particularly, this is definitely an estimate. The updates still need to rsync to our servers and then the aggressive caching in front of them needs to expire. Generally that's an additional 15 minutes.
For changes that need to go out together or at a specific time we can speed up some of this process, but it becomes less automatic the faster we want it to go. For most updates the automatic systems should work fine. As always, I'm happy to answer questions if you have them, either about this process or Kubla itself.