Using Dandelion for simple website deployments

Anyone building simple static websites has been there. You start out putting your website live by FTPing your files to the web server. With so many free FTP tools out there, life is grand.

But then FTP becomes problematic when you start making changes to the website. Which files did you change? When you make a mistake remembering, you end up with missing images, incorrect style sheets, broken links, and other issues with your pages and assets.

Surveying the field of deployment options

There are an increasing number of options for deploying your files to your web server, at different costs, with different strengths and weaknesses:

• Capistrano
• Springloops
• Server-side Git pulls
• Heroku’s Git endpoints (i.e., git push heroku master)

My pick for deploying simple websites: Dandelion

One solution I’ve fallen in love with is Dandelion. It is free, simple, and integrates with any process that uses Git for version control. In fact, it uses Git to determine what has been changed since your last deployment and uploads or deletes files for you based on your changesets in Git.

You install the Dandelion Ruby gem, configure a file called dandelion.yml, commit your files to Git, and run the dandelion deploy command from your site root in your terminal.

Before using Dandelion, I was reviewing my Git commit logs and manually dragging files into my Cyberduck window to deploy them to the server. I always dreaded deployment. It actually kept me from making changes to my sites sometimes because I didn’t feel like dealing with it.

Now I literally don’t think about deployment while I’m working on my static HTML and WordPress sites.

Working with the dandelion.yml file

One major function of the dandelion.yml file is to setup your FTP, SFTP/SSH, or Amazon S3 connection. Other than that, you can tweak which files Dandelion sends (or doesn’t send) to the server.

In general, Dandelion looks at your Git repository and references the files there.

Including additional files

Sometimes there are files that you choose not to check in to Git that you want on your server. You usually block these files with Git’s .gitignore file.

Here are examples of files that I block from Git using .gitignore but would want on the production server:

• Configuration files that contain sensitive information like passwords to databases and 3rd party services
• Combined and minified assets like CSS and JavaScript files

Dandelion allows you to include individual files or entire folders that may not be present in your Git repo using the additional setting:

It will upload the files in this list every time you run dandelion deploy.

Excluding files

Sometimes there are files that you check into Git that you don’t want or need on your server. Here are some typical examples:

• Sass and LESS source and configuration files
• Source JavaScript or CoffeeScript files that get combined and minified into a single file
• Bower configuration files
• CodeKit configuration files
• Dandelion configuration file
• README files

You can exclude any files or folders from being uploaded to the server using the exclude setting:

Pro tip: do not save your dandelion.yml file with server credentials in your Git repository

I mentioned using .gitignore above to block files containing sensitive information from being saved to your Git repository. This same logic should apply to your dandelion.yml file.

To get around this problem, do the following:

1. Add dandelion.yml to .gitignore.
2. Copy dandelion.yml to a new file named dandelion-sample.yml.
3. Remove sensitive information from dandelion-sample.yml.
4. Check dandelion-sample.yml into your Git repo.

Your dandelion-sample.yml file will look something like the examples earlier in the article.

People new to your project will then need to copy dandelion-sample.yml to their own dandelion.yml file and fill in the missing blanks with the server credentials.

Be sure to keep any other configuration changes made to dandelion.yml in sync with dandelion-sample.yml.