Our approach is to write 'deploy' scripts that can either by SQL or PHP scripts. These are executed during any deploy, either to a dev, QA or production system. The developers write deploy scripts as part of the feature that they are working on, and the scripts are verified in our continuous integration system with automated tests.
We do not write rollback scripts. We make sure that each deploy is 'rollback-able' which means the application code can be rolled back without requiring any database changes. For example, if we need to drop a column, we make the code change first, then in a subsequent release, actually drop the column. If we rename the column, we maintain the existing one until a subsequent release. Just one approach. There are some great tools out there that will produce rollback scripts for you, or you could write your own, but we chose to go this simpler way. One other thing that we do is dump the database schema into text after each deploy and commit it to a directory in the repository. That enables us to see in text changes that were made to the database for each release. Jon On Fri, Jul 12, 2013 at 9:58 AM, Jason Feriante <[email protected]>wrote: > The Eloquent ORM allows database migrations / version control, rollbacks, > etc. > http://codehappy.daylerees.com/eloquent-orm > > There are frameworks using Eloquent (e.g. Laravel). > > If you're using Composer, (which is becoming much like ruby gems in terms > of power / convenience), you can install eloquent via illuminate/database. > If you're using a composer compatible framework (e.g. Slim, Symfony, > Laravel, or another), it's relatively easy to install the ORM. > > Here's more on Eloquent migrations. > http://codehappy.daylerees.com/migrations > > > > > On Fri, Jul 12, 2013 at 9:22 AM, Lonnie Olson <[email protected]> wrote: > > > One method I have used is "database migrations" included in Ruby on > Rails. > > Essentially each version of your database includes up and down > > changes. Up changes are the changes needed to bring the database from > > previous version, and Down changes are the reverse. > > > > You may be able to create a lot of code to automate a lot of this > > functionality, but you can also do it manually. The benefits mean you > > can check in these migrations into your normal VCS so they get version > > controlled as well. > > > > The RoR docs may give you some ideas on how to code it yourself. > > http://guides.rubyonrails.org/migrations.html > > > > On Fri, Jul 12, 2013 at 8:37 AM, Chris London <[email protected]> wrote: > > > I just wanted to see what everyone is using to try and manage database > > > deployment/version control for the following use cases: > > > > > > 1) Database schema changes. Being able to roll out and roll back > database > > > schema changes from development to staging to live. > > > > > > 2) Database data changes. Being able to roll out and roll back inserts, > > > updates, and deletes to databases. (this one poses a unique problem > > which > > > auto increment ids) > > > > > > Thanks everyone, > > > Chris > > > > > > _______________________________________________ > > > > > > UPHPU mailing list > > > [email protected] > > > http://uphpu.org/mailman/listinfo/uphpu > > > IRC: #uphpu on irc.freenode.net > > > > _______________________________________________ > > > > UPHPU mailing list > > [email protected] > > http://uphpu.org/mailman/listinfo/uphpu > > IRC: #uphpu on irc.freenode.net > > > > _______________________________________________ > > UPHPU mailing list > [email protected] > http://uphpu.org/mailman/listinfo/uphpu > IRC: #uphpu on irc.freenode.net > -- Jon St. John Director of Engineering Drive Current, Inc. [email protected] Phone: (888) 303-0764 x85 Fax: (888) 290-6670 San Diego: 8555 Aero Drive, Suite 305 San Diego, CA 92123 Salt Lake City: 314 West Broadway #250 Salt Lake City, Utah 84101 _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
