OK! So those who attended my session on my Drupal development workflow at DrupalCamp Austin this year are probably still reeling from the experience-- I know I am.  And I am wanting to post all the gaps I failed to cover and whatnot.  There will be a reprise session, streamlined, clearer, and still more thorough at Southwest Drupal Summit 2010.

For now, here are some tidbits to tide you over:

Just this afternoon, I had to swap out a header slideshow from using views rotator to views_slideshow on a live site. My workflow for this, true to how it was presented but even better, was:

1. On production site:
   1. drush sql-dump > the .sql in the inaccessible assets folder monitored by git
   2. git add . to ensure I picked up all new documents, images and whatnot uploaded to the site since last maintenance
   3. git commit
   4. git push orign master
      because, in this case, I have an interim server hosting some of my git repos using indefero.
2. On local dev:
   1. git pull origin master
      1. Contemplate pulling my hair out, because git crabbed about untracked files that would be overwritten, yada yada.. but instead
   2. rm that "offending" file and then git reset --hard for good measure
   3. then git pull origin master
   4. drush sqlc < the .sql from the inaccessible assets folder monitored by git.

At this point, I've got local looking just like production, but the current views_rotator driven front page slideshow is not managed by Features!  What to do!  No worries..

I downloaded and enabled the views_slideshow module, edited the View locally, simply changing the Style to Views Slideshow, and set up the other params.  Then I modified the css to match the previous views_rotator css-- not too different, just different selectors (and a chance to clean up a bit):

1. drush dl views_slideshow
2. drush en views_slideshow_single -y (what? oh cool, it automatically updates the "parent" dependency views_slideshow for me.. Thanks module manager!)
3. Edit the view
4. Edit the css

Next I created a new feature of this slideshow whose View machine name has not changed, added it to the site, and enabled it:

1. Create the new feature via Manage Features web UI, cherrypicking a few things starting with the View in question and downloaded it.
2. tar -xf frontpage_slideshow.tar (hmm, that sounds like my presentation almost to a T!) into the sites/all/modules/custom folder
3. drush en frontpage_slideshow -y (psst, hey Chris, the -y is to bypass the y/n prompt ;) )

Commit to git, and push to remote. I include the sql-dump but don't intend to reload it at remote-- check it out:

1. git add . (to pick up the newly downloaded views_slideshow module and the newly created frontpage_slideshow Feature)
2. git commit -am "swapped out for views slideshow; modified css to support; created feature frontpage_slideshow"
3. git push origin master (again, this is going to the lillipad indefero remote git repo)

Then on remote, production:

1. git pull origin master at which point I now have all the files from the changes before but no database changes loaded
2. drush en views_slideshow_single -y
3. drush en frontpage_slideshow -y
   Ok, check this out.. do drush features or visit Manage Features page, and you'll see that the new Feature is installed and enabled..... but it's in the state of Overridden-- confused? Don't be: this just means that the database and live view of the frontpage slideshow (now actually referred to as frontpage_slideshow) is different (the old version) from the code version on disk.
4. drush fr frontpage_slideshow -y
   Woah. Revert??  Yes.  That's the confusing nomenclature of Features (in this release). It's not really "revert", it's "update from file" in my workflow, but whatever.  Just do it.  Load from file, load from disk.

WHAM!  The frontpage slideshow is now the new views_slideshow, and life is GOOOoood.

(oh, and yeah, it really works! I hope to post some log or screenshots here in a bit, but don't hold your breath.)