On Tue, Jun 21, 2011 at 3:24 PM, KCO <kochin....@gmail.com> wrote: > *Already I have a question... do most of you setup a local version of > Drupal (or whatever it is) running on your desktop with a local > version of the database as well?
Yes, always, but generally not the same exact environment that the prod server would have. > Or do you push up to the server and > hope that what you built works and if it doesn't you reverse the push > (my usage of these terms aren't perfect so please excuse me)?* > > I use a tool like capistrano to manage deployment. > And here is where I'm stuck... from a file system perspective I can > see this working fine... but regardless if I setup a local version of > my site or just use the remote version for testing my work, what > happens to the DB when you start working on the feature? What if work > for your feature requires some changes to the DB... what if those > changes affect the master branch? Do you now create multiple DB for > each branch? I think you see where I'm going... > For php projects, I use Doctrine, and am free to fiddle around with the db all i want. If you can't use a tool like doctrine, I'd recommend making schema changes via a set of scripts and / or version a schema dump that you can load / some sort of data-fixtures loading. Managing different environments databases becomes much easier if what's creating and modifying the db are files under your (and version) control. > > I very stuck here in terms of what best practices are... I know that > in systems like WP or Drupal where you shouldn't be touching the core > code/db and should only be creating plug-ins/modules that you may not > affect the site as a whole when developing your little piece... but > what happens to the db? More than likely it won't change either > but... ??? > I have no clue what best practices for Drupal or WP would be. For php, I've been using Symfony2 with great success, but it might not fit your use case. > > Can anyone shed some light here on this for me please? > > In general, for anything that gets deployed to a server, there will be at least a best practice of "don't edit on the server edit on your machine" and "use a deployment tool". What's appropriate for the DB might vary from project to project and framework to framework -- but as long as the stuff you change to change the db doesn't *have* to involve using a frontend to the database by hand, you can stick the commands you'd run in a script and run that instead -- tools exist that will do that for you already though, generally called "migrations" and "data fixtures". i wouldn't recommend hand-writing those tools unless you absolutely have to. As long as the commands that change the db are under vc, there are no issues other than possibly regenerating dbs when you switch branches -- personally, I create many, many branches and the vast majority of them do not require me to change anything in the db schema. The ones that do are easy to handle thanks to git and the magic of scripting. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
