Récit d'une grosse migration de Swift 2.3 à Swift 3 avec Firefox iOS

Stéphane Moussie |

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.

L’outil de migration intégré à Xcode.

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.

Cliquer pour agrandir

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.

Extrait du canal Slack mis en place pour la migration.

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).

avatar RedMak | 

Volila ! Le "code freeze" est nécessaire!
Mais moi et mon équipe étions contraint de migrer et en meme temps ajouter des fonctionnalisées à l'existant qu'il faut après migré ..

tt ca parce que le chef à decider ainsi et que mon chef pouvais pas dire non .. ??

Et c'est pas un petit projet oh que non (chiffre d'affaire +/- 400000€ par jours .. donc il fallait faire les choses bien !)

avatar EBLIS | 

400000€/j seulement de CA ? Petits joueurs !

avatar Lightman | 

@RedMak

"chiffre d'affaire +/- 400000€ par jours"

Ça veut dire que des jours c'est +400000 € et d'autres jours c'est -400000 € ???
C'est pénible cette habitude d'utiliser « +/- » à la place de « environ ».
Accessoirement, « par jours » ne prend pas de 's'.

avatar cenker | 

Votre codeur émérite aurait un tuto mysql swift ? x)

avatar Hydrog3n | 

C'est vraiment pas conseillé ! Utilisez une API plutôt interagir avec la base de donnée.

avatar LaurentH | 

On a plutôt une API REST, ça marche bien...

avatar C1rc3@0rc | 

Tuto MySQL Swift, ça n'a pas de sens.

Deja verifie que ton besoin n'est pas couvert par CoreData.

Soit tu veux utiliser Swift pour faire une application qui interroge un server, et la tu te fous de ce qui tourne dessus comme SGDB (SQL, noSQL,..), la seule chose qui intéresse c'est l'API: en general REST. En gros t'envois une requete comme avec n'importe quelle page WEB (get, post,.. ) et tu recuperes du JSON/HTML/XML/TEXT.

Soit tu veux faire de la programmation serveur, comme en Python, Ruby, Java, NodeJS, PHP( ? ),.. et pour le moment c'est en développement. Tu peux aller voir en fonction de ton besoin:
https://swift.org/server-apis/
https://developer.ibm.com/swift/
https://swiftserver.codeplex.com/
http://perfect.org/

https://vapor.github.io/documentation/getting-started/install-swift-3-ma...

Si tu veux faire du SQL local avec SQLite par exemple, tu as:
https://github.com/ryanfowler/SwiftData/blob/master/README.md
https://github.com/Oyvindkg/swiftydb/blob/master/README.md
https://github.com/ccgus/fmdb/blob/master/README.markdown

Ou alors tu veux faire un soft server MySQL en Swift, donc tu veux reinventer la roue en Swift, et la tu vas devoir passer par des librairies C, creer des classes Swift, monter tout ça dans une application qui va devoir faire du multithread, de la gestion de cache, ... en gros monter toute une architecture server (et securisé en plus). Donc si c'est ton projet ça veux dire que tu as besoin d'etre ingénieur en système d'informations => il te faut pas un tuto mais une formation comme en proposent les universités, le CNAM, l'EPITA, etc.

Sinon, si tu veux apprendre le SQL et mySQL, prends un cours SQL (https://openclassrooms.com/courses/administrez-vos-bases-de-donnees-avec...)

avatar bbtom007 | 

Il a eu droit de dormir ou seulement les coups de fouet ?

avatar EBLIS | 

Sympa l'article. Merci MacG.

avatar Domsware | 

Merci pour cette information, très intéressante.

avatar agaloppe | 

Une API pour interagir avec une db ?! Bizarre ..... orm plutôt non ?!

avatar agaloppe | 

Ou sql pur .... mais une API la je vois pas !!!

avatar Hinamori | 

Concevoir ? Il faut des idées (et des bonnes !)
Coder ? C'est pas évident ! (Et il faut du talent)
Débogguer ? C'est chaud patate !

Râler ? Il faut juste rien y comprendre !

J'anticipe les râleurs et les trolls !

avatar cenker | 

Du coup, utiliser une api ou pas ? Si oui laquelle ?

avatar Jean-Jacques Cortes | 

Voilà pourquoi j'attend que Swift soit stabilisé avant de me lancer dans son étude. Inutile d'apprendre des trucs qui seront périmés dans les prochaines versions. J'ai assez donné avec html et css.

avatar Nico S | 

@Jean-Jacques Cortes

"J'ai assez donné avec html et css"

????

avatar C1rc3@0rc | 

@Jean-Jacques Cortes

Oh tu peux y aller au niveau de l'apprentissage de Swift. Le langage est tres riche et complexe, il te faudra bien un an de pratique avant d'en maîtriser une partie. Faut aussi beaucoup de temps pour integrer Cocoa.

En l'etat, Swift est utilisable pour faire des petits projets et le probleme de la migration vient lorsque tu attaques des projets que tu devras maintenir plus d'un an. Donc pour l'app iOS de base - jeu jetable, interface de site WEB, coussin peteur, etc - c'est tout a fait faisable.

Donc entre le temps que tu vas mettre a apprendre le langage, la programmation de la plateforme et la conception d'un projet important, Swift en sera certainement a une version définitive du langage.

Aprés faut voir pourquoi tu veux apprendre Swift.
Si tu maîtrises deja HTML5 et que ton idee c'est de faire des app Swift au lieu de faire des web app HTML5, l'investissement n'est pas forcement rentable: se lancer dans la programmation iOS c'est limité a iOS, une app iOS n'est pas meilleure qu'une bonne WEB app (qui elle est compatible avec toutes les plateformes), vu qu'iOS change chaque année faut maintenir l'app meme si le contenu et l'interface du service web ne changent pas, l'interface iOS est contrainte aux directives d'Apple alors que la Web app c'est toi qui decide,...

Et puis, le développement iOS ne se limite pas a apprendre Swift et Xcode et Cocoa, ça c'est juste le début, derrière faut apprendre tout ce qui fait le metier de developpeur: mathematiques de l'informatique, algorithmique, méthodologie, architecture de l'ordinateur, architecture des reseaux,...

avatar kiddsoso | 

Mysql Swift ?
Pourquoi faire ?

Si tu veux interagir avec une db le mieux est de passer par ton serveur qui lui gère ta db donc ouais une API REST est le mieux.

Pour interagir avec ton API t'as plus qu'à envoyer des requêtes (GET, POST, PUT, DELETE) en utilisant Alamofire par exemple.

avatar BeePotato | 

Une légère erreur dans l’article : « 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 3 à Swift 4. »

La stabilité est annoncée pour Swift 4, ce qui signifie qu’il n’y aura plus à modifier le code source pour passer de Swift 4 à une version ultérieure.
Ça ne concerne pas le passage de Swift 3 à Swift 4, pour lequel il faudra encore faire des modifications de code (mais nettement moins importantes que lors des précédents changements de version).

avatar Stéphane Moussie | 
@BeePotato : en effet, je rectifie. Merci de la précision.
avatar stefhan | 

Article très intéressant.

MacG : qu'avez vous gagné en passant d'une version de Swift à l'autre ?

CONNEXION UTILISATEUR