Team Development Best Practices For Systems Administrators

Events happening in the community are now at Drupal community events on www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

This wiki page is meant to serve as an open discussion space and organic document for sharing ideas about what are the Best Practices for Development Operations across a team of developers, from a systems administration perspective. Any changes / updates / suggestions are welcome!

Version Control:
* Git is the standard Source Version Control system for Drupal developers. What is the best way to ensure that a gitified directory tree is accessible to multiple concurrent developers (on a *nix system)?

Development Stages / Lifecycle:
1. Development - Could be done individually on a local system. What are the best ways to use a common development box for multiple developers? Should each user launch her/his own development sandbox?

By standardizing your development/staging/production environments, you can save a great deal of "works on my machine."

Some options include:

  • Vagrant with Virtualbox
    -- Configuration Management
    --- Puppet
    ---- Popular
    ---- Somewhat complicated
    ---- Ruby-based templates
    -- SALTSTACK
    --- Relatively unknown, but gaining traction
    --- YAML-based templates
    --- Python-based
    --- Salty-Vagrant Gem integrates with vagrant

Some combination of Vagrant and Virtualbox with a configuration management system allows each developer to have an identical system as staging and production.

The templates can be easily transferred to the staging and production system and updates to each can then be integrated back down-stream so that every environment is the same.

By storing small Vagrant Boxes that can be easily created, destroyed, and then duplicated, each project is guaranteed a pristine and sterile environment.

  1. Staging - If each developer uses her/his own PC to develop, this is where the pieces come together and start to form a coherent project.
  2. Testing - UI / UX testing before launch.
  3. Production - No one should be editing files at this stage. They should be developed and tested first, then pulled down to this system.

Continuous Integration:
Need info here.

Backups:
Obviously backups of a production server are critical. Frequent backups during development phases of a project can also go a long way toward saving your butt, and your time! What are peoples' thoughts on frequency and necessity of dev-chain backups?

Comments

Additional projects and resources

nerdcore's picture

Here are some related projects and resources which may be useful to this discussion:

  • Ariadne [https://github.com/myplanetdigital/ariadne] is a project to build a full-featured Drupal development environment within a Vagrant VirtualBox.
  • drush-up [http://drupal.org/project/drupal-up] is a drush command to spin-up virtual boxes for development.
  • Aegir [http://www.aegirproject.org/] is a set of automation tools to facilitate the setup and configuration of production Drupal servers.

Ubuntu

Sarah Thornton's picture

Anyone looked into Orchestra from Canonical? Its starting to look like an interesting project that could be leveraged for rolling out Drupal environments.

So is it like openstack, but

bhosmer's picture

So is it like openstack, but a canonical product?

DevOps

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: