bookmarks  2

  •  

    AutoPatch was born from the needs of using an agile development process while working on systems that have persistent storage. Without AutoPatch, developers usually can't afford the maintenance headache of their own database, and DBAs are required just to apply changes to all of the various environments a serious development effort requires. The very application of database changes becomes an inefficient, error-prone, expensive process, all conspiring to discourage any refactoring that touches the model, or being a bottleneck when model changes are made. AutoPatch solves this problem, completely. With AutoPatch, an agile development process that requires a database change looks like this: * Developer alters the model, which requires a change to the database * Developer possibly consults a DBA, and develops a SQL patch against their personal database that implements the alteration * Developer commits the patch to source control at the same time as they commit their dependent code * Other developers' and environments' databases are automatically updated by AutoPatch the next time the new source is run This represents streamlined environment maintenance, allowing developers to cheaply have their own databases and all databases to stay in synch with massively lower costs and no environment skew. That's what AutoPatch does. Clusters with one database? Multiple schemas? Logical migrations, instead of just DDL changes? Need to do something special/custom? Need to distribute your changes commercially? All without paying anything? No problem.
    15 years ago by @gresch
    (0)
     
     
  •  

    My thoughts on evolutionary design in regards to databases. Database administration. Best Pratices, Database utilities and other things
    17 years ago by @gresch
    (0)
     
     
  • ⟨⟨
  • 1
  • ⟩⟩

publications  

    No matching posts.
  • ⟨⟨
  • ⟩⟩