12 Jul 2016

Technology: How new car2go features are released

The dream of every agile team is to deliver value for its customers in an iterable and reliable manner. Because building the right experiences is no easy job, reacting fast on change, inspecting and adapting are vital for building another breed of cat and for being loved by users. Our philosophy? Create a releasable product increment every sprint, and in the end click one button and drink coffee while magic happens. 

But how does the magic happen and, specifically, how do we automate releasing a mobile application every two weeks and still have 99.9% crash free users? In a nutshell, product increments are born by continuously integrating new features, implementing automated testing and making sure that every build from a continuous integration (CI) branch could, potentially, be released.

Now let’s look in detail at the life of a feature, from planning, thru development to the point it is in the hands of our users.

Release process

Release process flow

Planning phase

In the beginning there are, of course, lots of ideas for new features. Ideas come from car2go lovers via various channels, business stakeholders, customers, the team, etc. Ideas are then prioritized and added to the backlog (maybe more on this process in the future).

As ideas are broken into user stories, our design squad needs to understand the problem and start sketching. After a couple of iterations a first wireframe prototype is tested by real users that give us validation if we are heading into the right direction.

Then we analyse the user story from a technical point of view. The Product Owner, together with development team, refines and measures complexity of the story. We use Atlasssian Jira for issue and project tracking.

According to priorities, we take a story into active sprint, agree over implementation details and split the story into platform specific tasks.

Development phase

We implement and test the user story by completing each task in a feature branch. We use Gitflow for that. When everything is done, it comes the time to fine check design and test if all acceptance criteria are met. Then we create a pull request, make sure integration tests are green and only after other developers approve it, we integrate the new story into our CI branch. We use Atlasssian Stash for collaborating.

Distribution phase

The distribution phase starts with a team testing meeting, where everyone in our team can review the finished story and discover potential issues during a manual testing session.We resolve possible findings and coding “freezes”. When the time to release a new app version has come, one of the developers triggers a Jenkins job that runs automated tests, builds, signs and uploads a binary to an app store.

Alpha testers are now free to download the binary and manually test integration by going through a test sheet. If no release blocking issues are found the binary moves to an open beta testing. After extensive testing and analysing feedback from various channels a decision to go live or not it is made by the PO and business stakeholders.

Just a few facts to show how our process has evolved over time. The car2go app was updated from 2012 until now as follows: 5 times in 2012, 6 times in 2013, 10 times in 2014, 18 times in 2015 and 8 times this year as of writing this (statistic does not include hot-fix releases). Try out latest version of Android, iOS, BlackBerry and Windows Phone and remember to always update and keep up with newest features.

Last but not least, you might have recognised some scrum guidelines that my team found useful over time. But more important is to understand that there is no universal recipe and this is a snapshot of our continuously improving process which might have already changed by the time you read this. If you have suggestions or questions for us, we are happy to discuss.