Presentation on theme: "Change Management & Revision Control CPTE 433 John Beckett."— Presentation transcript:
Change Management & Revision Control CPTE 433 John Beckett
Purposes of Change Management Getting it done (properly, of course) Assure that changes do not have a damaging effect on others: –Programmers –SAs –Users –Online visitors Reducing the “oops quotient”
Steps In Change Management Communicating –So people know what is happening –So you’ll do all the details that need doing Scheduling –To clarify possible problem areas so they can be avoided or mitigated –To keep moving forward Executing –Sticking with the plan –Handling problems with service goals in mind
Two Phases Plan your work –Establish agreement about how things will be done. –Get it down on paper, copy what you submit –Communicate, communicate, communicate. Work your plan –Hold up your side of the agreement. –Hold others responsible for their side. –Communicate, communicate, communicate.
What is a “Significant” Change? Anything that affects more than a single user. Anything that might affect more than a single user So…Document even small changes!
Configuration procedure Create revision histories –Capture status of all involved hosts at critical points Lock configuration files so only one person can edit them at once Run automated checks on the format/information Notify other systems or apps that an update has occurred
UNIX Revision Control System (Ubuntu: You’ll need to apt-get install rcs) Allows SAs to cooperatively manage files. Alerts an SA attempting to modify a file, if another SA has “locked” it. Discards changes made without locking, the next time it is unlocked by the holder. Useful if SAs cooperate with each other, since each will probably have root.
DIFF Use “DIFF” to show changes that have been made. Consider automating DIFF runs on critical config files, saving the results. Back up the results of this process!
The Reboot Issue If you reboot after making a configuration change, that takes the machine down. If you don’t reboot after making a configuration change, you don’t know if a reboot will work properly. Schedule changes for times you can reboot without impacting service. –This is difficult in a 24x7 mentality. Wal Mart idea: Customers may shop 24x7 –Registers closed from 11:50 to 12:20 –Can you partition your services to allow for reboots?
Another Reboot Test Method Change config Flag machine as needing a reboot Reboot at next quiet time. –“Soon” Service is uninterrupted while you make the config change. You avoid the “it won’t reboot and the SA is out backpacking” syndrome. Beware: You’d better be there at reboot time!
No Changes On Friday You’re human –This is surprising to some folks. Case of a large cutover here (dorm telephones) –Vendor normally cuts over Friday night, uses weekend to clean up –We scheduled for Thursday –Intensive testing earlier in the week Cut over unused lines before the “real thing” –Actually cut over on Wednesday –Uneventful
The Best Conversion …is the one nobody remembers SLS project at Info Services (critical app) –Program was rewritten from scratch –Programmer surreptitiously installed new version –I was the only one who noticed –Applications were unaffected –Why? Very clear writing in the program Full understanding of req’s (working model available)