Webtools:CVS Guidelines: Difference between revisions

Jump to navigation Jump to search
m
no edit summary
No edit summary
mNo 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
** Be aware of other patches in progress
** Talk to each other to ensure that your patches won't cause regressions
** 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
** 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.
* 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 =
= Tagging for production =
* Tag your last-known-working-copy as your ROLLBACK (if one doesn't already exist)
* Tag your last-known-working-copy as your ROLLBACK (if one doesn't already exist)
{code}
<code>
[morgamic@khan aus]$ cvs tag -f AUS2_ROLLBACK
[morgamic@khan aus]$ cvs tag -f AUS2_ROLLBACK
{code}
</code>
* Review LXR logs to make sure each update makes sense
* Review LXR logs to make sure each update makes sense
* Apply your patches for the next batch
* 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
* 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}
<code>
[morgamic@khan aus]$ cvs tag -F AUS2_PRODUCTION
[morgamic@khan aus]$ cvs tag -F AUS2_PRODUCTION
cvs tag: Tagging .
cvs tag: Tagging .
Line 31: Line 26:
T inc/xml.class.php
T inc/xml.class.php
[morgamic@khan aus]$ cvs ci
[morgamic@khan aus]$ cvs ci
{code}
</code>


= Pushing updates into production =
= Pushing updates into production =
Line 39: Line 34:
= Requesting an update in production =
= 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
* [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.
* Assign the appropriate severity -- note that critical or blocker pages the oncall.  


= After the push =
= After the push =
* Always be available after updates are pushed
* Always be available after updates are pushed
* Sysadmins, if the developer did things right, you should be able to rollback by using:
* Sysadmins, if the developer did things right, you should be able to rollback by using:
{code}
<code>
[root@khan aus]$ cvs up -r AUS2_ROLLBACK
[root@khan aus]$ cvs up -r AUS2_ROLLBACK
{code}
</code>
3,035

edits

Navigation menu