Welcome back to the pond! Last week we touched on the importance of mentoring juniors and Github best practices. In this week's episode, we'll be following up on the junior workflow from last week by discussing two tools you should definitely have and how to install them, exploring new ground by touching on some entry level SCSS techniques, sharing my AHA! and FAIL moments of the week, and lastly, our weekly query for you good people out there to ponder. So lets jump right into it shall we?
Last week, this error brought many of our deployments to a screeching halt. "upload via sftp failed on metaltoad.com: Net::SFTP::StatusException (Net::SFTP::StatusException open ...releases/20130408223054/drupal/ sites/all/themes/boilerplate/css/compiled/default.css (2, "no such file"))".
When working with Drupal sites, Drush is your go-to tool. This post is going to focus on the drush sql-dump command. This allows you to export your database to a sql file, so you can restore it later. This can be particularly useful when you are working in a development environment and need to deploy a site to production for the first time. Or when you start work on a new clients existing site, you need to export their live database and download it to your local environment.
One interesting thing that has evolved from our use of Capistrano is the configuration files have become the de-facto documentation hub for a project's server connection details. (We do maintain inventory data elsewhere, but for the developer in the trenches,
config/deploy/prod.rb is the first place to look). A question arose: How to parse the settings out of these files?
Deploying code to WordPress installations has always been a bit of a struggle. Although there are a few WordPress plugins that help in deployments, there hasn't really been a simple WordPress deployment process. It's about time that process became a lot easier.
When we added the Compass CSS authoring framework to our projects, new wrinkles appeared in the deployment process. Committing the artifacts to Git was used for our first prototypes, but is unsuitable for team projects because it's a sure-fire way to introduce merge conflicts. Running compass on the server (either with Cap or the Drupal module) is appealing, but a minority of our projects deploy to hosts without the ability to install Compass. Rather than support multiple strategies, we decided on executing Compass locally on the workstation running Capistrano. Changes are needed to several files:
Cap has made our deployments simple, fast, and reliable. However, it can only access services you yourself have access to. Establishing this access for the first time can be a bit of a trick.
- Multistage: Deploy to different environments (such as testing vs. production).
- Drush Integration: Use the power of Drush to extend Cap's reach into Drupal's internals.
- Multisite: Run many sites from a single code base.