Git + Drupal Workflow

Question

I start with Git with workflow questions. I learned a lot of commands and I know how everything works, but I can’t understand the correct workflow. Love to have some suggestions. [Note, I'm the only developer working on my projects]

• A friend once told me that it is best to work on a real server, rather than on a local host, in order to avoid environmental problems. It's true?

• I use the same basic theme for all my Drupal sites. When I make changes to one, I now need to copy and paste it in about 10 other places. Is there a way to keep this basic theme in one place and bring other sites to it? Perhaps github?

• If I want to make a “full” backup of the code database and the database, the only way to do this is to export the database as a sql file and commit all this?

Thanks for the help!

Terry

Answer 1

• In general, you should run testing on the server as close as possible to the production server, but not to the real server in real time, as this will lead to the breaking of the live site during testing. Since Drupal is designed to run on different servers, the use of such servers is not so important.

• You should use git pull instead of copy-paste. Since git has a decentralized design, you really don't need a central location like github. If this is useful for your workflow, use it, but if not, you can directly move from one server to another.

• There is no great solution for Drupal that stores so much configuration information in a database and supports synchronization. Synchronizing the entire database is one approach. Many modules also have export data, which basically stores data from the database into code, so you can synchronize it with the rest of your code. Features is probably the easiest way to experiment with the exported model and see if this works for you.

Answer 2

• I understand your friend’s point, but I strongly disagree with the launched (possibly erroneous, possibly) broken development code on the production server. Better load VirtualBox and configure the virtual machine with the same configuration as the server on which you are deploying. Use git to create “tags” for each version that you deploy so that you have useful guidelines for the “versions” of your site.
• Take a look at the "git submodules". You almost certainly need to find out what it is, but if you come from a disruptive background, you will probably find them very confusing. Submodules mostly reference other repositories, so you have a programmatic link to another project inside your main project. However, they must be autonomous in the directory.
• I personally like to store the schema.sql file in my repository (just an empty SQL schema), but I don’t think that keeping your full database backups in the repository would be wise, although you can. Store these separately.

If you're new to the whole idea of ​​version control systems, you're probably better off just jumping with both legs. Everything will start to make sense when you go. And, of course, by its very nature you are unlikely to do any permanent damage, as you can roll back and forth.

One firm recommendation: fix often. Every time you make changes that work, make. Smaller fixations are much easier to handle than larger ones. For example, if you need to undo a broken change, you will most likely be able to undo it without deleting a bunch of working code that was committed at the same time if your commits are atomic.

Answer 3

for dumping drupal db regulator i use

a) a git alias to create an empty, unrelated branch named "db" find the alias http://gist.github.com/360294

b) the following commands, using the great maatkit tools, empty some uninteresting tables and empty the db into separate files, without comment

mk-find DBNAME --tbllike "cache%" --exec "TRUNCATE %D.%N"; mk-find DBNAME --tbllike "watchdog" --exec "TRUNCATE %D.%N"; git checkout db && \ cd /GITROOT/db && rm -rf * && \ mk-parallel-dump -d DBNAME -- mysqldump --skip-extended-insert --skip-comments --skip-lock-tables '%D' '%N' \> '%N.sql' 

Answer 4

• In general, the closer your environments are to each other, the better. This is especially important when trying to diagnose and track problems. It’s not that it is impossible to have different settings in each of your environments (dev, qa, prod, etc.), but I would say that it is preferable to be consistent if possible.

• Setting up a git repository for a common theme is a great idea to remove the inheritance of problems when copying / pasting your changes. Regardless of whether the git repository is configured on your own server, or using a service like github, it is strictly dependent on personal preferences.

• Yes, to get absolutely everything backed up, you need to do sqldump databases in addition to your code repository. At the same time, use the Features module liberally and get as much of your configuration in the code as possible. It also helps when moving between environments, as well as being able to keep track of your changes along with the rest of your code. Some of the most important elements to add to your functions will be content types, views, permissions, variables (via Strongarm ), block placement (via Context ), menus, etc.