We started using it about a year ago – like everyone else. We joined Github for our own projects, and the open source ones, too.

But one post from Bryan Helmkamp helped us getting the server setup streamlined, particularly, the multistage Setup. So this is mixing gits’ and capistranos’ best aspects.

Why Multiple Stages? For many, bliss is when you can deploy with one command. This is great at the start of the project and the default for capistrano. The problem is that as soon as the project has a certain size, the speed at which one can deploy actually slows stuff down. This is because everyone has to wait with adding stuff until the deployment is done and agreed upon by the customer.

How it works Now with multiple stages, at one point we decide that a number of features are complete and can be tested by users. We update the staging branch and deploy that with capistrano to the stage server. There, the customer can check out the new features while we continue developing. When we reach an agreement we can deploy we update the production branch from the staging branch and deploy that.

So let’s jump in.

Installation

We are using the capistrano-ext gem and the gitworkflow.rb from Brian’s post in lib/tasks to standardize branching for deployment, and the actual deployment process. If you want to set up a new project to use those methods, you need to create

• config/deploy.rb
• config/deploy/*.rb
• lib/tasks/gitworkflow.rb
• Capfile

into your application. You can look here for some explanation – basically, you have to ‘capify’ the application and create deploy/envs.rb for each environment. If it’s aready capified, check the differences.The project should be in sync with a master branch (on github in my example).

Setup

This deployment setup requires two extra branches on github. This can be done with:

git checkout -b staging             # creates a branch locally
git push origin staging             # pushes the branch to github
git checkout -b production          # same for the production branche
git push origin production
git checkout master
git branch -d staging
git branch -d production

The local branches are deleted after each deploy.

For the following to work, the git config needs to be right. Much of this (maybe all of it) will be set correctly when cloning the project from github. Check:

git config --list

If the variables are not set right you can use

git config remote.origin.url git@github.com:simplificator/yourapp.git
git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
git config branch.master.remote origin
git config branch.master.merge master

Or alternatively, perform a new git clone git@github.com:simplificator/yourapp.gitin another directory and work from there.

Then, the deployment targets need to be set up.

cap staging deploy:setup
cap staging deploy
cap production deploy:setup
cap production deploy

It’s likely you need to go to the server to set up the databases. One way of doing this is going to the deployment location into the current checkout and then running

rake db:create:all

We need

• yourapp_production
• yourapp_staging

Here you need to do some badly documented magic:

• get gems
• setup apache for passenger
• run the migrations

Workflow

• Branch for working.
• Add and commit in your branch. Stash everything else.
• Unit test.
• Checkout master, pull, and merge your branch.
• Unit test.
• Push the master up.

Staging

When you’re happy with what you’ve done you can stage your work:

rake tag:staging
cap staging deploy:migrations

or the shortcut rake deploy:staging. When you do that, the staging branch is replaced with your local master branch.

Production deploy

When you want to push the staging branch into production, do

rake tag:production
cap production deploy:migrations

When you do that, the production branch is replaced with the staging branch from github.

Fixing

When you have to do a fix for the production server:

export BRANCH=hotfix
rake branch:production

hackhackhack…

git commit
export BRANCH=hotfix #(unless it's the same shell still)
rake tag:staging BRANCH=hotfix
cap staging deploy

After this, your staging server is running your corrected production code. If it works, you can redeploy this using

rake tag:production
cap production deploy

from the same shell (because of the BRANCH variable). Then the stage server is free again to take the more recent code.

New development doesn’t affect that process.

Conclusion

I’m sure a lot more of this could be automated (like the initial db setup) – I’m not claiming we got all edges out of the process. But it can give you some ideas on how to do it yourself.

For us, it has rendered our deployments much more professional, without adding too much cruft (after the initial setup of the first project). The stage server helps us to train ourselves with deployments of complicated software involving many moving parts until they run smoothly and will execute on production without trouble.

Your message was deleted without being read on Fri, 8 May 2009 12:50:03 +0200

Thanks!

We try to reply considerably faster when you apply for a job at simplificator:-) Still we take our time to go through your documents and answer your questions.

To simplify the process we created a todo list template for our “recruitement process” in basecamp and now have an easy way to track progress of each application.

Does that mean that you should stop sending applications? Not at all! We are still looking for another talented coder to join our team.

You can find more about the job here (text in german).

We start with a short block of theory and then continue with lots of examples and homework assignments.

We had some troubles in the beginning (see picture below) but after everything was settled the workshops were received very well.

Getting the 2009 Apple Displayport-VGA Adapter connected with an old (metal, not plastic) VGA connector proved to be difficult….

While Jona is a great graphic/product designer (that’s what he does for a living) he also knows how to make a great fondue in a small kitchen.

Thanks.

Simplificator GmbH wurde im Mai 2007 von Lukas Eppler und Pascal Betz gegründet. Ziel der Firma ist es, auf agile Art Software zu entwickeln, die komplizierte Probleme auf einfache Weise löst. Die Entwicklung läuft in enger Zusammenarbeit mit dem Kunden. Wir glauben an kontrollierte Softwareentwicklung mit kreativen, hoch qualifizierten Entwicklern. Wir entwickeln nach dem Test-First-Ansatz, in kurzen Iterationen und Release-Zyklen. Unser Büro ist mitten im Kreis 5 oberhalb dem Restaurant Les Halles, wo sich auch die Ruby on Rails Community der Schweiz regelmässig trifft.

Unser Team besteht aus den beiden Gründern Pascal Betz und Lukas Eppler, Marco Ribi und Nico Ritsche. Nico arbeitet zwar extern, ist aber integriert in unser Team. Wir beschäftigen weiter immer wieder externe Mitarbeiter, welche bei uns oder von fern für eine gewisse Zeit mithelfen. Mit Nico sind wir zu viert – aber wir haben genug zu tun und brauchen Verstärkung.

Wenn Du gerne Webapplikationen baust, sauber und schnell coden kannst, wenn du Ruby on Rails kennst, ein schneller Denker oder eine klare Analytikerin bist, Energie hast und deinen Hirnschmalz gerne kreativ verwertest, dann müssen wir reden miteinander. Wir bezahlen ordentlich, bieten Flexibilität und Lernchancen. Wir sind noch klein und Du kannst dadurch die Firma mitprägen. Du kannst mit modernsten Technologien Erfahrungen sammeln und siehst direkt in alle Prozesse der Softwareentwicklung.

Wir erwarten eine fundierte Ausbildung (FH, Uni, ETH, ..), idealerweise ein paar Jahre Erfahrung in der Webapplikationsentwicklung, und entweder ein Jahr Praxis mit Ruby on Rails, oder eine fundierte Erfahrung mit Java-Webapplikationen. Erfahrungen mit Photoshop und Webdesign wären hilfreich, wie auch Fähigkeiten bei Usability und Konzeption. Auch Erfahrungen in iPhone-Softwareentwicklung wäre spannend. In erster Linie möchten wir jemanden finden, der in unser Team passt und Wissen produktiv und effizient anwenden kann. Die Stelle ist als unbefristete Anstellung mit 60%-100% gedacht. Arbeitsort ist Zürich. Ich freue mich auf deine Bewerbung per mail an jobs@simplificator.com. Für Fragen: 044 500 47 50.

And if you don’t speak german – let me know. It’s not an ultimate requirement for the job – a bit would help, though.

The calculation and bookkeeping should be integrated into the buying process of their customers’ customers, in order to make the decision process quick and easy for them. Like that, more customers are willing to actually pay the markup for offsetting their carbon. This creates opportunities in usability and API connectivity.

We have now won a contract to produce an application in that field for myclimate. We’re proud to be able to contribute to the climate efforts.

• http://enfranchisedmind.com/blog/posts/hpricot-does-namespaces
• http://www.rubyinside.com/nokogiri-ruby-html-parser-and-xml-parser-1288.html