My latest post for mobile.blog, Two simple techniques to make your release process more asynchronous and decentralized shares a couple of conventions we use at Automattic to ship the WordPress, WooCommerce, and Simplenote apps every two weeks with no sychronous meeting.
Imagine you're about to package the release candidate for the new version of your app when you discover there are open PRs that look like they should make it into that build. Also imagine that everyone else in your team is asleep because you live on the other side of the world. How are you going to know whether you should wait for those PRs to be merged go ahead?
That's what happens to me every two weeks and what prompted me to write to share some of the tactics we use to deal with this situation to avoid delays or middle-of-the-night conversations.
As my day job, I work with a lot of smart folks from all over the world. Automattic has been a distributed company since its inception. When I say "from all over the world," I mean that literally, my division alone has people from 22 timezones!
Being distributed across so many timezones makes it impossible to rely on synchronous meetings as the primary tool to take decisions. There's never a (reasonable) time when everyone can online together.
This pressure made us develop several processes to get stuff done asynchronously. As a mobile infrastructure engineer, one of those I'm most involved with is our apps' releases, scheduled every two weeks. My team wrote about our release process in the past. Eli, our Head of Apps, also gave a talk about it a try! Swift NYC.
In my post, I drill down on two particular conventions using GitHub labels and milestones to communicate whether a PRs should be part of the new version of the app it belongs to. I also talk about the different automation we put in place to remind contributors and reviewers about these conventions.
I think you'll like it. Check it out here and do let me know what you think.