Swift 4, qui sera lancé cette année, va soulager les développeurs d’un processus contraignant : la migration. La stabilité du code source récemment annoncée par Apple signifie pour les développeurs qu’ils n’auront pas à modifier le code de leurs apps pour passer de Swift 4 à une future version.
Encore faut-il que le projet soit passé à Swift 4, et avant à Swift 3. Dans un billet de blog détaillé, Mozilla raconte la migration de Firefox iOS de la version 2.3 à la 3.0. Une opération tout sauf anodine pour un projet qui comptabilise plus de 200 000 lignes de code.
Xcode a un outil de migration automatique, mais même s’il est d’une « aide fantastique », il vous laisse au bout du compte avec un projet impossible à compiler et long à démêler, indique l’équipe mobile de la fondation.
Pour passer à Swift 3.0, Mozilla a décidé d’agir plus méthodiquement que lors de sa transition de Swift 1.0 à 2.0, c’est-à-dire en commençant déjà par freezer le code (pas d’ajouts durant le processus).
Notre plan était simple. Avancer étape par étape, en migrant chaque composant séparément et en s’assurant que les tests soient concluants avant de passer au suivant.
Pour cela, Mozilla a identifié clairement les différents composants de son projet et les a cartographiés avec le logiciel Graphviz, ce qui a donné le graphique ci-dessous. L’équipe a ensuite organisé le travail dans la plateforme de développement Bugzilla.
Le premier accroc dans le plan s’est manifesté assez rapidement. Impossible de tester individuellement les composants migrés sans convertir le composant principal au préalable. L’approche choisie n’était pas adaptée au fonctionnement de Xcode.
L’équipe a fait face à un second obstacle quand elle a migré de gros composants, en particulier celui consacré au stockage : « même après tout ce temps, la capacité de Xcode à compiler du code Swift est… bancale. » L’environnement de développement renvoyait des messages d’erreur générique qui n’étaient d’aucune aide. Heureusement, Xcode 8.3 sortie en bêta fin janvier a amélioré ce point.
Au lieu de « paralléliser » la migration comme c’était prévu, l’équipe l’a « aplanie » en un seul fil. Un changement de méthode rendu possible par l’éloignement géographique des trois ingénieurs en charge du travail :
Notre ingénieure au Royaume-Uni travaillait sur un composant jusqu’à la fin de sa journée. Ensuite notre ingénieur basé à Toronto reprenait le travail l’a où elle l’avait laissé et le continuait jusqu’à la fin de sa journée. Puis notre ingénieur à Vancouver prenait la suite. […] Les heures de travail qui se chevauchaient étaient utilisées pour résoudre ensemble les problèmes les plus délicats.
Finalement, alors que l’équipe avait estimé avec beaucoup d’optimisme que la migration serait faite en une semaine, il en a fallu entre trois et quatre au total. L’opération a mobilisé trois ingénieurs et trois personnes en charge du contrôle qualité. L’équipe partage sur son blog des ressources et des astuces qui lui ont été utiles.
À une autre échelle, la migration vers Swift 3 de notre application iGeneration qui avait été entièrement écrite en Swift 2 a pris environ quatre jours à notre développeur émérite (il l’a réalisée sans utiliser l’outil de migration automatique de Xcode).
