Jump to: navigation, search

Difference between revisions of "Hudson/Admin/UpgradeHudson"

(New page: This page documents the necessary steps to make sure you get a successful hudson upgrade. <br> = Pre-Upgrade Announcement = Since Hudson is used by many eclipse projects, it is a goo...)
 
(Notify Cross-Project)
 
(4 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
= Pre-Upgrade Announcement  =
 
= Pre-Upgrade Announcement  =
  
Since Hudson is used by many eclipse projects, it is a good idea to send an email to the cross-projects-issues-dev mailing list, notifying them of the upgrade.&nbsp;&nbsp; This gives all projects advanced warning in case there are any issues that may occur.&nbsp;&nbsp; Give this notice at least 3 days before doing the actual upgrade of the system.  
+
Since Hudson is used by many eclipse projects, it is a good idea to send an email to the cross-projects-issues-dev mailing list, notifying them of the upgrade.&nbsp;&nbsp; This gives all projects advanced warning in case there are any issues that may occur.&nbsp;&nbsp; Give this notice at least 3 days before doing the actual upgrade of the system.
 
+
<br>
+
  
 
= Upgrade Process  =
 
= Upgrade Process  =
Line 17: Line 15:
 
#Follow the steps on [[Common Build Infrastructure/Managing Hudson|Managing Hudson]].&nbsp; These steps how to restart the server.
 
#Follow the steps on [[Common Build Infrastructure/Managing Hudson|Managing Hudson]].&nbsp; These steps how to restart the server.
  
= Post Upgrade Verification =
+
= Post Upgrade Verification =
  
You should do a visual verification on various jobs to make sure that everything looks correct.&nbsp; If there are build histories missing, or plugins that do not seem to be working, you may need to re-install these.&nbsp;&nbsp; Starting with version 1.337 of Hudson, Hudson will try and get all dependencies for the plugins as well.&nbsp;&nbsp; This eliminates many of the plugin problems that occured in the past due to missing dependencies.
+
You should do a visual verification on various jobs to make sure that everything looks correct.&nbsp; If there are build histories missing, or plugins that do not seem to be working, you may need to re-install these.&nbsp;&nbsp; Starting with version 1.337 of Hudson, Hudson will try and get all dependencies for the plugins as well.&nbsp;&nbsp; This eliminates many of the plugin problems that occured in the past due to missing dependencies.  
  
 +
You may have to repeat the upgrade of plugins, shutdown, restart steps several times to get all dependencies worked out.&nbsp; However, with 1.337 and above, this should be mitigated with the new depenency manager installation.<br>
  
 +
== Test Jobs ==
  
== Notify Cross-Project ==
+
Ideally there should be handful of jobs that can be run to do a Smoke Test of the upgrade.  These jobs should test a variety of functionality.  This smoke test or sanity test can be used to measure how well the upgrade process went.
  
Send an email to the cross-project-issues-dev mailing list, letting the list know about the upgrade completion, and a list of any new or noteworthy changes.&nbsp;&nbsp; Include a link to the most recent Hudson Change log so that others can review what has changed that may or may not affect them.
 
  
 +
== Notify Cross-Project  ==
  
 +
Send an email to the cross-project-issues-dev mailing list, letting the list know about the upgrade completion, and a list of any new or noteworthy changes.&nbsp;&nbsp; Include a link to the most recent Hudson Change log so that others can review what has changed that may or may not affect them.
 +
 +
Projects that use Hudson, should do a santity test to make sure their builds are working as before.  If not, then a bug with a reference to the upgrade request bug should be created.
  
 
= How often should we Upgrade? =
 
= How often should we Upgrade? =
  
 
Hudson follows a very agile development process.&nbsp; It releases new versions once a week.&nbsp;&nbsp; This means that bug fixes and enhancements are available every week.&nbsp; However, unless we are particularly having problems or there are some major new functionality, we should consider at least once a month checking for an upgrade.&nbsp;&nbsp; Usually you may want to wait a few days to make sure there are no major bugs that have cropped up.&nbsp;&nbsp; It is a good idea to monitor the [http://n4.nabble.com/Hudson-users-f361316.html Hudson User mailing list].
 
Hudson follows a very agile development process.&nbsp; It releases new versions once a week.&nbsp;&nbsp; This means that bug fixes and enhancements are available every week.&nbsp; However, unless we are particularly having problems or there are some major new functionality, we should consider at least once a month checking for an upgrade.&nbsp;&nbsp; Usually you may want to wait a few days to make sure there are no major bugs that have cropped up.&nbsp;&nbsp; It is a good idea to monitor the [http://n4.nabble.com/Hudson-users-f361316.html Hudson User mailing list].
 +
 +
== Times NOT to Upgrade ==
 +
 +
There are some critical times during the eclipse development process that we should try to avoid doing an upgrade on the hudson server.
 +
 +
* During Milestones M6 - Release Candidate 4 of the release train.  Any upgrades should occur after the release train has been published.
 +
* During the last week of a milestone.
 +
** Need some better guidelines around here...whose milestone, each project may have different milestones.
 +
 +
{{important|Upgrade Notification|Admins should give a reasonable amount of notification about an upgrade to all portential projects affected.  This message needs to be posted to the cross project mailing list, and a bug should be opened against the hudson server.}}

Latest revision as of 14:03, 14 December 2009

This page documents the necessary steps to make sure you get a successful hudson upgrade.


Pre-Upgrade Announcement

Since Hudson is used by many eclipse projects, it is a good idea to send an email to the cross-projects-issues-dev mailing list, notifying them of the upgrade.   This gives all projects advanced warning in case there are any issues that may occur.   Give this notice at least 3 days before doing the actual upgrade of the system.

Upgrade Process

  1. Manage Hudson->Prepare for Shutdown - This sets the notification that the server will shut down and keeps any new jobs from running.
  2. If you have an option to Automatically Upgrade or Download the War file, select the Automatically Upgrade option.   This eliminates any human errors that can occur (i.e. deploying or installing war files wrong).
  3. After the WAR has been updated, if there are any plugins that need to be upgraded now is a good time to do this as well.  Select the plugins with updates and let hudson install.
  4. Check to make sure that all Jobs have completed.  If not, wait until the jobs are finished.
  5. Follow the steps on Managing Hudson.  These steps how to restart the server.

Post Upgrade Verification

You should do a visual verification on various jobs to make sure that everything looks correct.  If there are build histories missing, or plugins that do not seem to be working, you may need to re-install these.   Starting with version 1.337 of Hudson, Hudson will try and get all dependencies for the plugins as well.   This eliminates many of the plugin problems that occured in the past due to missing dependencies.

You may have to repeat the upgrade of plugins, shutdown, restart steps several times to get all dependencies worked out.  However, with 1.337 and above, this should be mitigated with the new depenency manager installation.

Test Jobs

Ideally there should be handful of jobs that can be run to do a Smoke Test of the upgrade. These jobs should test a variety of functionality. This smoke test or sanity test can be used to measure how well the upgrade process went.


Notify Cross-Project

Send an email to the cross-project-issues-dev mailing list, letting the list know about the upgrade completion, and a list of any new or noteworthy changes.   Include a link to the most recent Hudson Change log so that others can review what has changed that may or may not affect them.

Projects that use Hudson, should do a santity test to make sure their builds are working as before. If not, then a bug with a reference to the upgrade request bug should be created.

How often should we Upgrade?

Hudson follows a very agile development process.  It releases new versions once a week.   This means that bug fixes and enhancements are available every week.  However, unless we are particularly having problems or there are some major new functionality, we should consider at least once a month checking for an upgrade.   Usually you may want to wait a few days to make sure there are no major bugs that have cropped up.   It is a good idea to monitor the Hudson User mailing list.

Times NOT to Upgrade

There are some critical times during the eclipse development process that we should try to avoid doing an upgrade on the hudson server.

  • During Milestones M6 - Release Candidate 4 of the release train. Any upgrades should occur after the release train has been published.
  • During the last week of a milestone.
    • Need some better guidelines around here...whose milestone, each project may have different milestones.
Important.png
Upgrade Notification
Admins should give a reasonable amount of notification about an upgrade to all portential projects affected. This message needs to be posted to the cross project mailing list, and a bug should be opened against the hudson server.