Tag: version control

GitHub’s free alternatives

Personally, I love GitHub.  And I try to promote it as much as I can, and I’ve even got a few organizations setup their repositories there.  However, I am still asked once in a while for a good alternative.  These work either for people who don’t have the money to pay for GitHub’s private repositories, or who are required to keep their code in-house.

Here are a few alternatives to the GitHub hosting service. There are two types of software: locally installed software and hosted.  These are decent for smaller companies that don’t have the budget for licensing a hosted service.

Free Local Install

  • gitlabhq.com – this project looks really good, with new releases every month.
  • gitorious – solid, free alternative to GitHub.

Free Hosted

  • gitorious.org –  open source projects are free, like github.
  • bitbucket – unlimited free private repositories for up to 5 users. The pricing model is similar to the other Atlassian products.

Also, have a look at Sourcegraph, which you can host yourself or pay for a hosted service.

On builds and releases

Once in a while I find myself in a conversation on builds and releases.  It’s one of those where before the conversation everyone seems to be on the same page, but immediately after the conversation starts, there’s a massive fight and argument as to how the world works today and what’s the best path into the future.  And it gets messy.

I believe that the old approach of one release a decade is dead.  Especially in web application development.  The world is much more dynamic now, and so should be the release plans.  This seems obvious to many, and yet, not a lot of people understand the implication of this.  Making releases more dynamic means making the release operation cheaper, ideally – free.  Can you release a new version of the project once a day?  How about every hour? Why not?  You should be able to.  Regardless, whether you will actually release every second or not, the path to making releases cheap is automation.  And that means you have to have some form of software version control, and some form of build or deploy script.  And, of course, some form of rollback script for those times when things go hairy.

One of the things that I do at my current job is setting up such a deployment process.  I’ve done it before, but it’s been a while, and given how fast these things change and improve, I’ve been looking around for new tools and ideas.  While doing so, I came across an interesting GitHub blog post.  And while their requirements and environment are different from mine, I still found it useful.  One of the things that shows how well their process works is the stats at the end of the post.  Just look at them.

That’s about 100 deploys per day! Not bad, not bad at all.