August 31, 2011
Simple staging on Heroku

Not everything runs the same on production as it does on localhost so you need a staging environment to vet changes before making them public.

When developing Piazza (on GitHub) we put together a simple workflow to manage production and staging deployments. Our app is built on the Heroku Cedar stack with Java and the Play framework but this workflow should be applicable to all other apps on Heroku.

Git branches

We need Git branches to track what we have on Heroku. We will be pushing these back to our central repository origin (GitHub in our case) to facilitate easier collaboration.

git checkout -b prod
git checkout -b staging
git push origin prod
git push origin staging

Heroku setup

You will need two different Heroku applications, one for staging and one for production. If you’re starting from scratch you can create these applications and attach them to the right Git remote repository.

heroku create --stack cedar --remote prod
heroku create --stack cedar --remote staging

If you already have a Heroku app under the Git remote heroku you can rename it and create a new app for staging.

git remote rename heroku prod
heroku create --stack cedar --remote staging

make me a sandwich

Create a file in your project root named makefile (with the lowercase m). We will create two make targets in this file which are basically project specific shortcuts. There’s a lot more you can do with make but we’re sticking to basics. Our two make targets look like this:

make stage will now deploy the contents of the staging branch to the appropriate Heroku app followed by GitHub. make deploy will do the same with the prod branch. You will have to merge changes from master into these branches yourself like so:

git checkout staging
git merge master
make stage

Bonus: Keeping branches clean

Since you have to update the staging and prod branches manually it is good to put in some safety measures to prevent bad deployments. For our part, we require the Git branch to be clean. A simple Bash script can check Git to see if there are any uncommitted changes and abort the make target

The new make targets should look like

Now if you try to make stage with a dirty repo the deployment will be aborted.

$ git checkout prod
Switched to branch 'prod'
$ touch newfile
$ make deploy
There are uncommitted changes.
make: *** [deploy] Error 1

Appendix

August 17, 2009
Only Twitter can save us from URL shorteners

Twitter should make URL shortening moot by allowing a link to be included with each Tweet at a fixed character cost of 5-10 characters.

Everybody hates URL shorteners. They slow down page loads, can frame your content, steal your PageRank and even drop dead without notice (and come back alive in a similarly suprising fashion). I mean, even Jeff Atwood thinks they are hack, and he’s a very practical fellow.

To remedy these issues, some well-intentioned people are putting together a spec for webmasters to declare their own short URLs. The thinking goes, other short URL services would first check the target page and use the webmaster specified short URL if one exists. The difficulty of getting URL shorteners to cooperate aside, there is a more fundamental problem here: we should not need short URLs in the first place.

Let me be more direct: Twitter is the only reason URL shorteners are rearing their collective head again. This, at the end of the day, is simply a design defect. While the 140 character limit is what makes Twitter special, the interaction between this limit and URLs at large has the harmful side-effect of requiring third parties to build applications for the sole-purpose of providing 301 redirects. See above for potential issues with such applications.

As new usage patterns emerge for their platform, Twitter do a great job improving their API to provide the smooth, seamless experience that their users have come to expect. Even better, their developer community does a great job including such improvements in their apps. This, after all, is exactly what is happening with the Re-tweet API right now.

The solution to the URL shortening problem is for Twitter to allow one URL to be included with each Tweet for a negligible character cost (say, 5-10 characters). They could then use their default short URL provider for SMS updates, which do have technical character count limit. More importantly, Twitter could sell the click-through stats of all URLs, shortened or not. Power users of all stripes might be willing to pay for this functionality.

Any experienced developer can tell you that there are a million ways of implementing any piece of functionality. Some are just better than others. They cause less exposure to bugs, implementation issues, or even attack surface. Sure, you could try to implement transport-layer encryption with JavaScript but it’s just not the right place to do it. Similarly, making long URLs play nice with the character limit is a task best handled within Twitter’s API by Twitter themselves.

10:01am  |   URL: http://tmblr.co/Zn_4by9r03b
Filed under: twitter web opinion 
Liked posts on Tumblr: More liked posts »