How to extend AutoPatch with new patch types

Adding New Task Types

By examining SqlScriptMigrationTask, you should be able to get some ideas on how to extend the system. There's no reason why there couldn't be an LdapScriptMigrationTask that read .ldif files, or an XmlScriptMigrationTask that issued SOAP or XML-RPC calls. As long as they allow themselves to be compared such that they fit into the natural patch ordering, and errors are propagated out after logging, they will work fine.

Patch Information Persistence

Currently the patch level of the system is stored in a database, however the idea of the "system patch level" is a separate subsystem in AutoPatch, and its not necessary for the patch table to be persisted in a database. Its entirely possible that a flat file would be sufficient for some applications, or that LDAP or a web server was the only external system with persistence.