Why our release process is getting faster

As you may have noticed if you follow OBM’s life, we, the OBM Core Team have decided to release more often.
Of course, this is not an easy decision, and it means a lot of modifications in our daily work.

Let’s first explain...

...what leads us to that organization turn.
=============================

We operate in a fast moving environment.

Guys at Mozilla (for Firefox), at Microsoft (for Internet Explorer), at Google (for Chrome) are working hard to launch new versions of their browsers as soon as possible. And we need to extend the compatibility of OBM in order that our customer can still use our product when they update their browsers.

New smartphones and tablets are designed and put on the market every week, OS/ROM version depends on the day you buy your smarphone and some mobile operators are cooking their own specific ROM with brand new features that are impacting our software synchronization. We need to go fast because we don’t want to answer to our customers that we only support the oldest ones which you cannot buy any more.

Thunderbird is moving a big step forward in every new release, our connector is compatible with the latest ESR version (today is version 17) but we need to be still proactive and not wait for the announcement of Mozilla new release to begin our dev support of Thunderbird and more specifically [lightning](http://obm.org/content/mozilla-news)


The more we work on our product, the more we hate big major releases. Why ? Because major features and product releases are very painful, with no real benefit for our customers and for us. There is often mismatched expectations with major releases, many Issues and a very big risk to be very late.
The feedback loop between the day we think about a feature and the day our customer is finally able to use it could be measured in months meaning we had very long gaps between coding and validation of our implementations.

How can we succeed without a loss of quality ?
==================================

We are agile. We speak together daily and everybody knows what the otherare doing. If one of us is blocked or is doing something wrong, anybody can react and help him. Because we work on an open source project, our scrum dashboad is visible by anybody, inside or outside the company (thanks to Jira). And we love sticky-notes moving from todo column to done.

We undestood something very important. The sooner we find a bug, the easiest, the less risky and the cheaper it is to fix it.
So we [eat our own dog food](http://en.wikipedia.org/wiki/Eating_your_own_dog_food) and we love that. We use everyday our product for our own need, and each time it is possible we also use experimental new code. Our feedback can be very fast, and we can very quickly fix any Issue encountered, our gap can now tends to less than a day. But we want to do more, we want continuous delivery and maybe one day continuous deployment.

We encourage pairing programming and responsible code reviews. This is such an incredible way to improve the quality of our code, thanks to the diversity of our engineers.

We do [TDD](http://en.wikipedia.org/wiki/Test-driven_development) (Test Driven Development) and our code is full of unit tests that are run every time our continuous integration receives new code.

Everyone in the team is taking the responsibility to test seriously. Not only the QA team, but also every developer is aware of the importance to deeply test his own work, and also the work of anybody.
We don’t have a dev team, and a QA team waiting for the dev work to be ready (weeks later). No, we have only one team and everyone have the same goal: to build the best product possible! QA can test any new feature or bug fix as soon as new code has been pushed to our repository. Testing is done at all stages in the lifecycle and by everyone.

Also we have the chance to work with very nice customers. We have a close relationship and they trust us. They can join us easily and we can react very quickly to their Issues. We learn a lot thanks to them, and I hope we pay them back a lot.

The future
========
We are proud of our work. We are proud to release very often new features and a more stable product each time. But we want more.
We want to be able to deploy continuously on our cloud servers (internally for Linagora users, but also for hosted users) and maybe for customers who wish to be updated continuously (for pre-prod servers).
We want to release at least every week a new version with a minor effort not disturbing our daily work, and of course with real improvements. And we want more and more users to benefit of our work.

In year 2012, we closed **836 Issues**, add **30 new features** and only **released 5 times**. In 2 months, we have already released 3 times and closed 292 Issues. Keep going and don't forget to follow us on [twitter ](https://twitter.com/OBM_CoreTeam)Apparel