Me — Did you manage to make any progress last night on your first deployment for the iOS app?
X — Unfortunately not. And I’m pretty sure I'm not going to be able to have another go today.
Me — But I thought your code was fine and your team leader was happy with the results…
X — Unfortunately Apple won’t let us deploy the end result to the App Store. Apparently because the version numbers for xcode and the sdk are too low. Anyway that’s the current blocking message. And it's always possible that a new error message will appear later in the process.
Me — Can you remind me why we’re discovering this problem when there are already 5 kanbans to deploy?
X — Because I've never put any iOS related stuff into production before, so this is the first time I've seen these errors. This exact setup (hardware and software) worked last year with the last intern but apparently Apple decided it wasn’t good enough now.
Me — But why are we discovering this today? When there are already 5 kanbans that are "finished". Why wasn't it discovered just after the first ticket was ready for deployment?
X — Because when a kanban is finished, I just push it to the main repository and stop there. It’s very different from the continuous deployment we use for the web related stuff. Since those 5 improvements were quite small, I thought I would finish them first and then send everything live with a spoonful. And that’s when the errors appeared.
Me — I'm not sure why you didn't pushed your iOS work in production after each kanban.
X — Well I'm sure it's not a good idea to have the App Store update the application 5 times in 2 days. That's why I was aiming for 1 or 2 updates per week : it makes more sense.
Me — Let’s deep dive a little bit here : how many updates could have been possible this week?
X — Well I did the 5 kanbans in 3 days so the first update would have been on Tuesday with two small features, the second on Wednesday with another pair of features and the third on Thursday with the last one.
Me — So imagine if we had tried to deploy the first ticket on Tuesday. What do you think would have happened next? You can do the exercise with two scenarios in mind: 1/ everything goes smoothly and 2/ reality bites and it stalls because of a configuration mismatch as we’ve just seen.
X — I see where you’re trying to go… In the first scenario, we know on Tuesday evening that everything is going according to plan and we can decide with the marketing team or even with our users if we deploy a second time on Wednesday, on Thursday or even on the following Monday. In the second scenario, we stumble on the actual errors early in the week but we can still deploy the first batch of features by Friday, possibly as soon as Wednesday.
Me — How does that sound?
X — I’m still not quite sure if it's a good idea to have two updates per week, but I'm pretty sure it's a better idea to have one update instead of none. It’s somewhat frustrating to realize that even though we've been working on this stuff all week, the end users can’t see anything at all.
