I basically knew that i would use something other than git to do the migrations, but i thought that it would be nice to use git as a trigger. Because we are already using it as a deployment tool, so it would know when to call the app and sync the db.
I'll take a look at the article that you sent! Thank you very much =) Em sexta-feira, 8 de novembro de 2013 05h36min52s UTC-2, Thomas Ferris Nicolaisen escreveu: > > On Thursday, November 7, 2013 3:07:15 PM UTC+1, Gabriel Felipe wrote: > >> So I own a VPS server running CentOS, and decided to use git for >> deployment. Man! That's fun. Push, done! >> I'm really happier than i was with the old ftp approach. >> >> But I wish I could go further, today it deploys automagically all my >> files, but it doesn't even touch my db. And if I change it in the mods, I >> have to update it manually. So i was thinking about using some git hooks to >> do this also automatically. >> >> By now I'm using one git hook at the server, it's a post-receive hook and >> basically copies files to the production directory when pushed to master. >> >> The prerequisites for the DB deployment are: >> 1) It needs to go both ways, if i pull from db, and it's different from >> my local it should update my local db. >> 2) It should be based on modifications and patchs and not the dump of the >> whole db, this way i can work with the team without compromising other guys >> work. >> >> I was thinking about keeping a db.sql on the version control, and make a >> script to analyze it on post-receive (on server) and post-merge(on local), >> so it can take the mods and apply, and i would keep a database of which >> mods were applied already (the script should run in both, client and >> server). >> >> Any of you guys have already done something similar to this? What would >> you recommend? >> > > In my experience, it is best to disconnect this from the notion of > pushing, and rather have the applications being deployed to do the SQL > migrations at runtime, during startup. Keeping track of changes to the > schema in versioned migration-scripts, and then including version-info in > the DB so it knows which migration-scripts still have to be applied, is > basically the trick. > > Also, only a smaller part of deployments actually include changes to the > DB, so optimizing for this isn't always the most valuable investment. > Anyhow, there's a lot of material on this out there, and a lot of tools > depending on your tech-stack. Google around for combinations of these with > "automated SQL migration". Here's a technology-agnostic article from Martin > Fowler on the subject: http://martinfowler.com/articles/evodb.html > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.