Webtools:CVS Guidelines
Jump to navigation
Jump to search
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)
[morgamic@khan aus]$ cvs tag -f AUS2_ROLLBACK
- 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
[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
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
- 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.
Pushing updates
- Updating production should be a simple step, and should always be consistent if we follow this procedure:
[root@somebox]$ cvs up -r AUS2_PRODUCTION
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:
[root@khan aus]$ cvs up -r AUS2_RTM_[date of rollback]
For example:
[root@khan aus]$ cvs up -r AUS2_RTM_20060808