workflow.textile

workflow.textile

Viget’s EE Development Workflow

Goals

• Optimize for local-first development
• Manage and sync multiple instances of an EE site
• Deploy from git
• Work from files, not the DB, wherever possible

EE’s database

To understand the dev workflow, it’s important to know a few things about EE’s database structure:

There are no files that manage or defined channels (document types) – in EE, modeling like this is actually done in the database. This has some advantages, but it makes EE very foreign-key dependent, and each piece of data tends to be tied to several others. For these reasons, we treat the DB as a whole ­ we don’t pull down entries, or push up a new field, we pull and push all data at once. It’s important to almost never ‘push’ to the main database, and when you do, to take extra care to make sure you aren’t overwriting data that’s out of sync (new entries, edits, password changes, etc).

Instances

Before launch

• Development
  Viget devs build the site on their own computers, versioning changes in git as they go. Once the features are ~90% complete, they begin deploying regularly to Staging.
• Staging
  Canonical version of site. Clients enter any new content on this site and can be confident that it won’t be overwritten. Clients and project managers verify that features work as expected.

After launch

• Development
  New developers should be able to check out and get a dev copy of the site running in a matter of minutes. Usually, they work with realistic data, pulling down live data from the Production site.
• Staging
  Staging is only used to demo and test new features. Clients occasionally use it to work on draft entries (although we discourage this). Staging data is unreliable, and developers commonly overwrite or revert it.
• Production
  File changes are pushed to Production without issue. Data, however, is only pulled from production. The only exception is when a new feature requires significant data changes that can’t be peformed on Production, in which case Viget and the client are especially careful to prevent data from being overwritten.

Common tasks

• Create a new development instance
  • git clone [repo].git
  • Set up a virtual host
  • rake import db
• Deploy file changes – templates, JS, CSS, images
  • cap [server name] deploy
• Copy the DB down from a live site
  • cap [server name] sync:db_down
• Copy down entry images, uploads, and other data-related files
  • cap [server name] sync:content_down
• Deploy database changes – don’t do this unless you’re very, very sure
  • cap [server name] deploy
  • cap [server name] deploy:import_db