Document and Automate as much as you can

Document & script as much as you can

When a server is installed, many commands are typed. When an application is installed, many config files are changed and though you may get a working machine slightly faster, it is good to document the install process as you go along for several reasons:

- By documenting the process, you can always know what was done months ago. This is specially important in teams where the person who implemented the server is unavailable during an emergency
- Because the process is documented, it is a lot easier to do the second time around. Not only do server crashes/ upgrades happen but who knows when you will need an additional server. Ideally, further than documenting the process, even allow for installation scripting... that will avoid errors when reinstalling in a rush.
- In case of a problem, it covers your bases (client or boss forget they actually asked you to do something in the first place), your mind is at ease because you can go back and say why things were done the way they were.
- It allows you to know how long things take to do things so you can more easily estimate future work
- By writing it down, it actually commits the experience to memory better and you can reflect on what to do better the next time

• Ideally, going one step further, scripting the install process is good for several reasons

  • Obviously, the speed is even greater
  • it avoids errors and omissions
  • there will be no hesitation if you need to reinstall the whole thing
  • If you ever get hacked (and I hope not), you're back up with a new machine almost instantaneously

• As for the backup, automate it and have more than one copy

  • if the backup process is in a cron job, you will neither forget nor procrastinate, the computer does it on itself
  • by having more than one copy, if one goes bad then you can rely on any other copy.
  • A standard practice is to have five copies of the data, to be able to revert to any previous day should there be a problem.
  • In some cases it is not practical because the data does not changes, changes too much, or not practical. Examine and weight risks
  • With source code, use a revision control system such as GIT, CVS or subversion (does not matter which one, use one). if "it worked yesterday", you can always go back to yesterday's version