Web Development Environment and Workflow

Over the years I have worked with a bunch of teams and solo. I usually go with the flow as far as the group workflow. I have had to roll my own subversion workflow in the dark days before it was a normal and expected thing to do.

Here is a rundown of the major types of workflows I have used…

My Ideal Web Development Environment

For environments where you can’t test locally
and are the only person with access to the testing server

UPDATE: Rob McBroom has come up with what looks like a really handy way to use TextMate to work with remote projects.

The two commands are “Get Remote Project” and “Upload Project
Changes”. … They essentially save all files and call rsync - au on your directory in different directions.

For environments where you can’t test locally and share a single testing server with other developers.

With this workflow you have to commit extremely minor changes before you can even test them.

It’s a massive waste of time to commit every single minor change before you can even test it.
But if you don’t have your own dedicated testing environment
then you just have to commit all changes before you can test them. Avoid this setup!

Personally, I’d really rather not work on a project unless I can test all my changes quickly and easily. My time and my Clients money is valuable.

In the past, I have worked remotely on projects that couldn’t be tested locally, but I had my own dedicated testing environment on the staging server. I would prefer not to have to ever do that again. Uploading changes before you can test them is just hideously slow.

I will make extremely minor changes remotely if the cost of setting up the local environment is higher than the potential that making a bad edit will trash the production server. But, usually those changes are just HTML, JavaScript and CSS. And all that stuff is really easy to test before committing.

The CrazyEgg Development Environment

  1. Local developers each have a complete local testing environment.
  2. We make changes locally, test locally and commit changes to the trunk branch of our subversion.
  3. When we have made all of the changes necessary to make a deploy,

    we then merge trunk to stable and deploy to our staging server.
  4. We test the changes on the staging server

    and then make any changes necessary and commit to stable.
  5. We then deploy the stable checkout to our production servers.

Quick bug fixes are handled on the stable branch. This helps keep the unstable feature development and the quick fix development as separate workflows.

I do occasionally skip the whole staging and deploying thing for very small changes that don’t require a full deploy or restarting any processes or anything. Mostly just CSS and JavaScript changes. Then you can just scp them to production and restart your processes if necessary.

John Butler created a system that allows us to deploy without having to shut down the system now, so that helps.

The sixteenColors Development Environment

  1. Developers have local testing environments
  2. When we make enough good changes we
  3. commit to trunk from our local and
  4. deploy trunk to production

This is the secret alpha version I’m talking about. The current version of the website was developed by lordscarlet a long time ago in ASP.NET. The alpha is juts a super-tiny webapp at the moment. There’s no need to waste the few hours a month we have to work on it with a verbose and tedious workflow.

My old offsite totalTrak.net Development Environment

Since this is an ASP.NET application and I was developing it on a PPC PowerBook,
I had no easy way to setup a local testing server. I was also the only person working on the project.

  1. I had a local mirror of production
    • A checkout of the trunk working copy
      • You should always have separate stable and trunk branches.
      • I didn’t bother with it on this project since the app was extremely stable (therefore no need to make quick patches on stable) and I was the only developer working on it.

        Excuses excuses…
  2. All changes made locally
  3. Tested HTML, CSS & JavaScript locally
  4. Tested T-SQL in TextMate locally
    • I hacked together a crazy system to connect to their SQL Server
      • It involved some crazy unixy shell stuff with an SSH Tunnel to their SQL Server ports via their MacMini blog server
  5. Upload the changes to the testing server for testing
    • I used Transmit to manage the mirroring.
    • I also used the TextMate Transmit bundle to upload files from my working copy to the testing server
  6. Commit changes from local
  7. SVN update testing server for final test before deploy
    • SSH tunneling to mount their SMB shares locally
      • This was slow, but it worked for subversion operations.
      • TextMate totally chokes on a mounted share normally,

        but over an SSH tunnel? Way too slow.
  8. SVN update production via SSH
    • We made sure that the .svn folders weren’t served.
    • Normally, you should always make your production server use a checkout rather than a working copy.
      • This was all very pre-Capistrano

My really old onsite Development Environment

  1. Local machine had no project files
  2. Shared development server
    • Each developer had a separate set of working files

      on a single shared development box
    • We all shared a single development SQL Server
      • We occasionally made duplicates of tables to test out some crazy operations.
  3. I made changes to the files over a SMB share
  4. I committed changes to trunk from the share
  5. deployed by svn upping the production working copy

Way way way way back in the day…

Back in the dark Dreamweaver days

before I discovered subversion.

  1. We all shared a single development server
  2. We made changes to the files over a SMB share
  3. We then deployed by replacing the files on production with the development files
  4. Then we franticly checked everything to make sure it all still worked

I sure am glad we have some better workflows today. Yeesh

What is your workflow?

How do you guys work? What kind of development do you do? There are LaTeX guys and Ruby guys and ASP guys out there. What kinds of workflows are standard for your environments? Will you put up with having to upload to a testing server to test every single minor change? Or do you demand to have a local development environment that is just like your production environment?