SUNScholar/Change Management

From Libopedia
Jump to navigation Jump to search
Back to Upgrading

WE CANNOT ACCEPT RESPONSIBILITY FOR ANY DATA LOSS OR CORRUPTION
BEFORE PROCEEDING, DO EXTENSIVE TESTING ON SPARE INFRASTRUCTURE
*** YOU PROCEED AT YOUR OWN RISK ***

Introduction

How do you manage 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 the recommended procedures to follow.

Recommendations

  1. Build a test/development system on another server, typically an old retired server. At Stellenbosch University library we built: http://repository.sun.ac.za (Only available on-campus). 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 at least 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
  7. http://www.jiscinfonet.ac.uk/infokits/change-management/