Okay, so I missed my daily blog post yesterday, I was a kinda busy. I'm hoping to make up for it by doing two posts today, this is the first one. It's a repost from a reddit thread titled: Drupal development 2 or more people on one project. Forgive my spelling and any other errors, I got kinda drunk in the middle of this one. Enjoy.
Certainly will. First, IDE. I'm a vim person and try to avoid using an IDE as much as possible. I find that they slow me down and with vim I have everything I need to edit any kind of file it opens. Plus I also use tmux for terminal emulation and zsh along with oh-my-zsh for my shell.
We use gitosis to host our repos and use the command line git to do everything else. I've heard very good things about gitolite, and sometimes github.
I've had lots of luck using the A successful Git branching model for managing workflow within each project with around 10 people contributing to the project. The key thing here is not to commit directly to the master branch and use the
--no-ff flag when merging branches. The rest is kinda common sense, create your tags for things you want to remember (we tag for every new platform we deploy to aegir). You have to enforce this with your users, we use git_hooks to keep people from commiting and merging into branches they shouldn't be touching and we accept patches for changes they want to make to something they can't push to.
The next part is following a features based workflow. Features allows you to store small pieces of functionality in module form that you can then enable on a site and provide that functionality. For example, we have a flash streaming server user can upload media to and stream to different audiences. We wanted to provide a way for users to add "Streaming Video" content to their sites also wanted to make functionality work across our 190ish Drupal instances. Features lets us do that really easily by packaging up the code that provides the functionality to the site and now it's an option on all of our instances.
Here's the basic workflow for a features based development cycle.
1) Create a vanilla instance of your drupal site, we use drush make files to define our builds and we have all of our code in the install profile. We base our make files off of how Open Atrium does theirs: https://community.openatrium.com/documentation-en/node/1420.
So our install profile file structure ends up kinda looks like this:
That is all versioned and when you build your development instance you are cloning a fresh version of that. The reason why we do this like this is so we can have each build defined with a make file, and if you notice, there is a make file included in the repo. The make file in the repo declares everything that should be included in an instance when you download it. It looks something like this:
core = 6.x
api = 2
projects[drupal][type] = core
; Contrib modules
projects[features][subdir] = "contrib"
projects[token][subdir] = "contrib"
projects[ctools][subdir] = "contrib"
projects[menu_block][subdir] = "contrib"
Now you need a make file to build this instance, it looks something like this:
api = 2
core = "6.x"
projects[drupal][type] = core
projects[PROFILENAME][type] = "profile"
projects[PROFILENAME][download][type] = "git"
projects[PROFILENAME][download][url] = "firstname.lastname@example.org:profiles/PROFILENAME.git"
projects[PROFILENAME][download][branch] = "feature-streaming-video"
This will clone a copy of the profile and checkout the feature-streaming-video branch. You can also use tag instead of branch and checkout a specific tag of a repo.
So with drush make you would do something like this:
drush make --working-copy ./builds/stable.make www
--working-copy flag tells drush make to include the gits (or whatever VCS you use) versioning information for the project.
After that your profile will look like this:
Basically you've generated everything you need for a drupal instance to work
Then you create your database, and use
drush site-install (or si for short) to install the site
drush si appstate --db-url=mysql://MYSQLUSER:MYSQLPASSWD@localhost/DATABASE --account-name=admin --account-pass=password --email@example.com --site-name="My Site Name" --firstname.lastname@example.org
2) Now that you have an instance built, then create your content type, views, or whatever else you need to do. Then using Features create a Feature that includes all of your functionality and untar it into your
/profiles/PROFILENAME/modules/custom/ folder in your profile. At this point you want to add your changes to a feature branch in the repo or to the develop branch, but don't merge into master yet. Also, checkout strongarm, that wil let you export things from the variables table which is helpful for including automatic url aliases in your features.
3) Now go back and drop all tables in your database and run the drush site-install command to create a vanilla install without anything left from the initial creation of the feature. CCK creates a database table for each content type so you have to be sure to remove everything so you don't get weird side effects when testing or developing the feature. Then re-enable the feature and ensure that everything you intended to be included with the feature is included. This would be a good time to write some tests too.
That's basically it. You keep dropping the tables and reinitializing the site until you have it so all you have to do is enable a feature and everything is setup. After that you merge into the master branch, Jenkins runs some QA tests and eventually the code gets pushed to production.