Facebook published a pretty interesting paper where they describe their strategy for doing CI/CD of their mobile apps, both on iOS and Android.
They describe the whole enchilada: from the general release cycle of their apps, to what they test for and how they test for that. But also, they share what they found after analyzing their strategy, looking for signs of how it impacted their development workflow.
The data they looked at goes back to 2009:
A significant aspect of our study is that the data we base our analysis on is extensive (§3). The data we analyzed covers the period from January, 2009 to May, 2016. It includes all of the commit logs from revision control systems, all app crashes that were captured, all issues reported by FB staff and customers, and all issues identified as critical during the release process.
That’s a crazy amount of information, and the conclusions they draw after crunching all the numbers are really interesting also, but perhaps not all-that surprising to people with experience in this industry. For instance:
We believe we are the first to show two compelling findings: (i) the number of developers modifying a file is inversely correlated to the quality of software in that file, and (ii) the software changes pushed on the day of the release cut from the Master branch are of lower quality than the files pushed on other days.
I had that empiric knowledge. It’s nice to have the data to back it up.
Productivity remains constant even as the number of engineers working on the code base grows by a factor of 15. This is the case for both Android and iOS developers, and whether measured by LoC pushed or number of pushes.
If you do mobile development and are interested in stuff beyond the hottest new design pattern of the week, this is a great read. I really enjoyed it.