| ... | ... | @@ -72,13 +72,15 @@ This is almost identical, except that we don't do as much. |
|
|
|
|
|
|
|
This is the process for releasing a hotfix to the CDN:
|
|
|
|
|
|
|
|
> pkra: perhaps we should revisit this. Creating a separate copy of the CDN (on Rackspace or elswhere) and switching the CNAME might be a better way of doing this.
|
|
|
|
|
|
|
|
1. Prepare and test a branch with the fixes as per our regular development process
|
|
|
|
2. Merge to master and the release branch at GitHub, e.g v1.1-latest
|
|
|
|
1. Copy the release branch to `mathjax/x.y-beta` on Cloud Files
|
|
|
|
1. Test
|
|
|
|
1. Announce it so people can test against it
|
|
|
|
1. Send warnings to the cdn-notify list 72 hours in advance
|
|
|
|
1. Just in case, check the max-age on the current point release directory (e.g. 2.0) and set it to 1h if it's higher. (Background: With Amazon, the usual max-age was 72h and for releases we reduced it to 1h to speed up progagation to CDN-endpoints. Since Rackspace doesn't charge for transfer from Cloud Files to CDN-endpoints, this is set to 15min by default.)
|
|
|
|
1. Lower the TTL of the CDN to 1h.
|
|
|
|
1. Sync the new release to `mathjax/x.y-latest` and `mathjax/latest` on Cloud Files (e.g., Cyberduck can sync folders). Note: renaming/deleting folders on Cloud Files is much slower than syncing.
|
|
|
|
1. Send confirmation to the cdn-notify list, and update the download page at mathjax.org
|
|
|
|
1. Monitor for any issues.
|
| ... | ... | @@ -91,19 +93,8 @@ Note that our policy is that we don't tag and package the hot fixes separately. |
|
|
|
|
|
|
|
**Note:** The CDN notify announcements should contain this info, as should the download page.
|
|
|
|
|
|
|
|
|
|
|
|
### Changing Max-Age
|
|
|
|
|
|
|
|
> This is mostly for completeness. With Rackspace, the need to change max-age has been eliminated since Rackspace doesn't charge for transfers from Cloud Files to CDN-endpoints. In fact, the default max-age that Cloud Files assigns to uploaded files is 15min. If you need more details, check out an older version of this page.
|
|
|
|
|
|
|
|
Changing the max-age for a file requires:
|
|
|
|
|
|
|
|
1. changing the Cache-Control header, e.g. Header set Cache-Control "max-age=3600"
|
|
|
|
|
|
|
|
The easiest way is to use Cyberduck to set the headers for multiple files, including recursively for directories.
|
|
|
|
|
|
|
|
### Doing the Update
|
|
|
|
|
|
|
|
In order to avoid to minimize the possibility for corrupting the origin server directories during an update, the preferred method of updating the origin server directories as to prepare the new release in a staging area. This gives us a chance to carefully check the staged files, and avoids exposing a mix of old and new files on the origin server during the time the staged content is prepared. The final sync is not as fast as the old symlink technique (now unavailable), but since the only issue are the png-fonts, syncing is actually very fast.
|
|
|
|
|
|
|
|
Of course, that doesn't prevent a mix of old an new files on the CDN servers, since they are only refreshed as they are requests. The strategy for minimizing that period of mixing on the CDN servers is the low max-age settings. Additionally, Rackspace offers CDN endpoint-purges via their support (and for individual files via API). |
|
|
\ No newline at end of file |
|
|
|
Of course, that doesn't prevent a mix of old an new files on the CDN servers, since they are only refreshed as they are requests. The strategy for minimizing that period of mixing on the CDN servers is the TTL settings. |
|
|
\ No newline at end of file |
