Tuesday, July 27, 2010

More on Continuous Deployment

This time is the turn of Digg, the popular bookmaring website. Thanks to Jens for finding it out.

http://about.digg.com/blog/continuous-deployment-code-review-and-pre-tested-commits-digg4

No change is going to make it onto our internal site without passing a full battery of unit tests. And nothing is going to go on from our internal site to production without passing an additional set of Selenium tests. Does this mean we're never going to introduce bugs to our live site? Of course not - but we're going to keep the number of bugs to hit the live site to a minimum, and we've made it easy and fast to get bug fixes live as well.

Friday, July 23, 2010

“A New Version Of Google Chrome Now Due Every Six Weeks”

google_chrome spinning  http://techcrunch.com/2010/07/22/google-chrome-versions/

With their Chrome web browser, Google has always been obsessed with speed. And now they’re speeding up another aspect of it: how often stable builds are released. The goal now is to release a new stable version of the browser every six weeks […]

This is not directly related to game development, but nevertheless very very interesting: to reliably release stable (not beta or dev) build to millions of users every six weeks, the Chrome team needs water tight automated testing, very good and consistent code quality and extremely honed agile processes: also the cost of making a change has to be small, while debugging relatively predictable. There is no room for long check-in queues, deep branch hierarchies, check-in rights, locked branches and long crunching months to meet a deadline. I can imagine that Continuous Integration and Release Branches are keys to meet this ambitious goal.

On a smaller but still interesting scale, Wordpress is on the same page:
http://toni.org/2010/05/19/in-praise-of-continuous-deployment-the-wordpress-com-story/

Launching products is one of the hardest things companies do. Most companies pour months of work into making sure everything goes right at a launch – the features are right, the marketing is ready, the press is primed, the product is solid, etc. But a new breed of companies are doing things very differently. Instead of optimizing product launches to go as perfectly as possible, they optimize to have them go as quickly as possible.

That’s where the Game Industry has lots to learn: the concept of being always in a state to be able to produce a stable build while keeping development up and running in a sustainable environment will prove to be the next Big Thing in Game Development to give some companies the competitive edge to release good games in time. A dream? What’s your opinion?

Tuesday, July 6, 2010

Festering code bases and budding code bases

A truly excellent read:
http://michaelfeathers.typepad.com/michael_feathers_blog/2010/06/festering-code-bases-and-budding-code-bases.html

Especially the concept that at the time of change, just adding code to an existing method, and not refactoring to a better structure, is perceived as more cost effective, but it’s just accumulate technical debts, that over time cost money in the form of interests. Same concept can be applied to write unit tested code: it seems to cost more at the time of change, but costs less in the long term, by flattening the curve of cost-of-change.