Difference between revisions of "SUNScholar/Change Management"

From Libopedia
Jump to navigation Jump to search
 
m (1 revision)
(No difference)

Revision as of 21:16, 14 August 2010

Introduction

Soon after installing DSpace you want to change things. How do you manage the changes so that they do not affect the uptimes of the production system too much and are controlled by all interested parties. The following are recommended procedures to follow.

Recommendations

  1. Build a test/development system on another server. This is the machine which you use to test changes and upgrades of software before you implement it on the production server.
  2. Try not to make major changes to the system during peak usage times of the year. Pick a time when there are very few users on the system.
  3. When you want to implement a change or upgrade you will need to inform submitters, reviewers and metadata editors. For this, setup a mailing list and ensure all submitters, reviewers and metadata editors join the list. For normal users, send a notification to the campus communications manager and then when the time arrives for the change, put the system into maintenance mode.
  4. Before changing anything on the production server ensure your backups are working. It is a good idea to keep incremental backups for a period of seven days.
  5. If you have service level agreements with the IT department, then inform them of changes that affect them at least two weeks ahead of the time.

References

  1. http://admin.sun.ac.za/cm/
  2. http://en.wikipedia.org/wiki/ITSM
  3. http://en.wikipedia.org/wiki/ITIL
  4. http://en.wikipedia.org/wiki/Change_Management_(ITSM)
  5. http://en.wikipedia.org/wiki/Release_management
  6. http://en.wikipedia.org/wiki/Configuration_management