3,035
edits
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
= | = General gotchas = | ||
* Always update your other code to the latest for that branch before you start your production routine | |||
* Don't ever submit a log without a description or corresponding bug number (if applicable) -- blank changelogs should be avoided | |||
* Talk to your team | |||
** Don't duplicate effort | |||
** Be aware of other patches in progress | |||
** Talk to each other to ensure that your patches won't cause regressions | |||
** Run the usual smoke tests and (ideall) some sort of automated script that can spot SNAFUs immedeately | |||
* Don't file IT requests for production updates every hour, and don't email them every 5 minutes (or text-message them either) -- your best bet is to group your updates and push them weekly. | |||
= Tagging for production = | |||
* Tag your last-known-working-copy as your ROLLBACK (if one doesn't already exist) | |||
{code} | |||
[morgamic@khan aus]$ cvs tag -f AUS2_ROLLBACK | |||
{code} | |||
* Review LXR logs to make sure each update makes sense | |||
* Apply your patches for the next batch | |||
* When you're _SURE_ that this is the final batch of updates, you need to tag it as PRODUCTION, then check that baby in | |||
{code} | |||
[morgamic@khan aus]$ cvs tag -F AUS2_PRODUCTION | |||
cvs tag: Tagging . | |||
T README | |||
T htaccess.dist | |||
T index.php | |||
cvs tag: Tagging inc | |||
T inc/aus.class.php | |||
T inc/config-dist.php | |||
T inc/init.php | |||
T inc/patch.class.php | |||
T inc/update.class.php | |||
T inc/xml.class.php | |||
[morgamic@khan aus]$ cvs ci | |||
{code} | |||
= Pushing updates into production = | = Pushing updates into production = | ||
* Only initiate a request if you are sure you are not causing a seriuos regression | |||
* For major updates, you should contact major parties and discuss the update -- at least briefly -- so they are aware. When in doubt, just email everyone. :) | |||
= Requesting an update in production = | |||
* [https://bugzilla.mozilla.org/enter_bug.cgi?format=it_request&product=mozilla.org File an IT Request] when you are sure you are ready to go | |||
* Assign the appropriate severity -- note that critical or blocker pages the oncall. | |||
= | = After the push = | ||
* Always be available after updates are pushed | |||
* Sysadmins, if the developer did things right, you should be able to rollback by using: | |||
{code} | |||
[root@khan aus]$ cvs up -r AUS2_ROLLBACK | |||
{code} | |||
edits