Pages

Tuesday, October 5, 2010

Alexander Grosse: Continous Deployment

The first "normal" talk (beside tutorial and the morning keynote by Lisa Crispin) I am joining is the talk by Alex Grosse about Continuous Deployment.

His talk is based on the experiences of Noxia and especially of dopplr (www.dopplr.com), a compony which had been aquired by Nokia. The dopplr team was known for living CD in real life.

He explains the idea of CD and the relation to testing.

Some nice takeaways:
  • One nice use case for feature flags: disable expensive features in case of high traffic (used by dopplr).
  • Use a DevOps team: integrate ops people into the agile (development) teams.

...

Sunday, May 2, 2010

Impediment Driven Development

I was wandering for some weeks what's the core of my new role in my company.

Now I've got it: I'm doing IMPEDIMENT DRIVEN DEVELOPMENT.

I maintain a list of impediments which disturb our developers and tackle the impediments one by one.

To be honest, I usually tend to tackle several impediments at the same time rather than one by one, but I try hard to limit the work in progress.

It sounds a little bit like the usual Scrum master role (the guy who tries to resolve all impediments of one team), but my role is to resolve the impediments related to a few topics (build mgmt and test automation) of many teams.

Monday, April 19, 2010

Tuesday, April 13, 2010

Using GIT in a CI System -- The Smart Way

Yes, there is a big hype around DVCS system such as GIT, Bazaar or Mercurial. Especially GIT has extremly fast operations for switching branches etc.

There is a very cool chance to use this git feature in your Continuous Integeration (CI) system if you have a big fat codeline with many branches whichare build in parallel.

Let's assume our CI system uses a build grid with a bunch of build agents which are running on a at multicore system (or several of them if you are lucky ;).

Given a build agent multicore machine and a git repo, use one "master" git repository clone which is responsible to fetch all changes. Every build agent has its own working copy git repo which references the object store of the master repo.
When a build is triggered, then perform the following steps: (a) fetch the changes in the master repository, and (b) perform a "git checkout" for the build agent working copy git repo.

This will be extremely fast. This smart git checkout can be in the order of 10-50 milliseconds rather than several minutes -- which can speed up your CI builds dramtically.

Tuesday, February 16, 2010

You know it's not done if.... (cooking 1)


Kitchen Disaster
Originally uploaded by rprins
My favorite example for getting software done is cooking, professional cooking in a restaurant to be precise.

A good, professional cook is able to deliver a great meal for many customers at the specified time. The meals are tasty and they look and smell good. But what about the kitchen?

It's his job to deliver brilliant food to the customer -- not just once. Period.

Hence its "done" if and only if the kitchen is prepared to create the next meal, too.

The first post

So, it took a long time for me to start blogging. I decided to post my 2 cents about agile development and ... "How to get it DONE?"

Why about done? Wait for the next post...