Megatokyo 3 en développement

Je me suis enfin lancé dans le développement de la version 3 de mon application universelle Megatokyo.

L’idée est de profiter du portage vers Windows 10 (la version 1 était en Silverlight pour Windows Phone 8, la 2 en UWP pour Windows 8.1) afin de revoir une bonne partie du fonctionnement général de l’application.

En effet, l’application actuelle a comme gros défaut d’avoir du mal à exécuter la tâche de fond qui va vérifier la présence de nouveautés. De plus, le scanne effectué pour extraire les données du site officiel nécessaires au bon fonctionnement est assez lourd et demande pas mal de temps au démarrage de l’application.

Passer à une application 3 tiers

L’idée est donc de déporter tous les traitements vers un serveur qui stockera toutes les informations nécessaires, préviendra les clients des mises à jour et transférera les données sur demande.

Plusieurs avantages à ça :

  • Le client devient plus léger et ne fait que charger des données déjà prêtes.
  • Plus de tâche de fond côté client qui peut échouer faute de ressource et consomme de la batterie.
  • Des notifications beaucoup plus ponctuelles et riches.
  • Plus de demande de traduction pour chaque client, mais une seule fois par langue.

L’idée est aussi d’en profiter pour apprendre à utiliser .NET Core 2.1, la version libre et multi-plateforme de du Framework .NET.

La partie serveur

Le serveur se compose de deux logiciels distincts. Le premier est un service qui va analyser les données et envoyer les notifications, le second un Web Service qui permet au client de venir chercher les données.

Les deux sont donc en .NET Core 2.1 et hebergé sur mon serveur Debian.

Le service de notification

Le service de notification est une simple application console exécutée en tant que daemon via Systemd.

Son principe est de récupérer le flux RSS du site officiel, de détecter les nouvelles entrées (planche ou diatribe) puis de lancer une récolte d’information pour complèter celles reçues via le flux RSS.

Une fois les données récupérées, elles sont stockées dans une base MySQL puis une notification est émise vers Azure Notification Hub qui s’occupe de la distribuée à tous les clients enregistrés.

Le Web Service

Le Web Service est un projet de type Web API en ASP.NET Core 2.1 qui permet d’interroger la base de données MySQL.

Il s’occupe aussi de la traduction des diatribes via Bing Translator (faute de mieux !) et enregistre celle-ci dans la base de données afin qu’elle puisse être réutilisée.

Ce Web Service est accessible via nginx en HTTPS et sait répondre aux demande de certification Let’s Encrypt.

Créer un projet Jenkins Multibranch Pipeline pour Delphi (Seconde partie)

Dans la première partie, nous avons vu comment installer Jenkins et les extensions nécessaires pour compiler un projet Delphi. Nous allons maintenant voir comment créer un script Jenkinsfile de base.

Créer le fichier Jenkinsfile

Les pipelines s’appuient sur des scripts écris en Groovy, un langage de script faisant appel à Java à travers une sandbox.

Jenkins recherche dans chaque branche du dépôt un fichier Jenkinfile contenant un script Groovy définissant les étapes de la compilation.

Structure de base du script

Un script de pipeline commence par la ligne de commentaire #!groovy, ce qui permet aux éditeurs reconnaissant ce format de le coloriser automatiquement. Sous Windows, je n’ai pas trouvé de logiciel le gérant, même si la demande existe pour une intégration dans Notepad++.

Ensuite, le script doit contenir la balise pipeline {}. Elle indique à Jenkins que le script commence. Ensuite, on peut indiquer des options pour ce pipeline et surtout des « stages » qui seront en fait les étapes de notre compilation.

Dans cet exemple, on déclare un pipeline, qu’il peut utiliser n’importe quel agent déclaré dans Jenkins et qu’il n’y a qu’une grande étape, la compilation.

Compilation d’un projet Delphi

Pour pouvoir compiler Jenkins, nous allons créer une étape de compilation faisant appel à MSBuild.

Dans un pipeline Jenkins, les variables d’environnement de Windows ne sont pas prises en compte ! Il faut donc les préciser à Jenkins dans le script.

Pour cela, nous allons rajouter une section « environnement » à notre script et y déclarer toutes les variables d’environnement nécessaires à la compilation.

Comme vous pouvez le voir dans l’exemple ci-dessus, les chemins sont tous absolus, il n’est pas possible d’utiliser %PATH% par exemple pour simplement ajouter quelque chose au PATH existant. Ici, nous avons deux versions de Delphi installées, la 17 (Seatle) et la 18 (Berlin) d’où la présence des deux chemins.

Nous allons maintenant pouvoir appeler la compilation à proprement parler. Pour cela, nous allons déclarer une « steps » et faire appel à notre plugin MSBuild via un « script ».

On commence par indiquer à Jenkins qu’on veut récupérer le chemin d’accès à l’outil MSBuild en l’appelant par le nom déclaré lors de la configuration.

Ensuite, on fait appel à la commande « bat » à laquelle on passe le chemin d’accès absolu à MSBuild et le chemin d’accès absolu à notre fichier .dproj. La variable ${WORSPACE} est renseignée par Jenkins et contient le chemin vers le répertoire de travail où va avoir lieu la compilation.

Si besoin, on peut ajouter des paramètres dans la ligne de commande pour indiquer quel plateforme utilisée ou le mode de compilation.

On obtient donc au final le script suivant :

Et voilà, vous n’avez plus qu’à nomer ce fichier « Jeninksfile » et à le placer à la racine du trunk ou de la branche, puis livrer !

Comme nous n’avons pas encore configuré la compilation automatique sur une livraison SVN, il nous faut lancer un scanne des branches manuellement. Pour cela, dans l’interface de Jenkins, cliquez sur votre projet Mutibranch Pipeline puis sur « Scan Multibranch Pipeline » dans le menu de gauche. Jenkins va alors détecter qu’une branche est à compiler et lancer la compilation.

Créer un projet Jenkins Multibranch Pipeline pour Delphi (Première partie)

Vu les difficultés que j’ai rencontrées lors de la mise en place d’un projet Multibranch Pipeline pour la plateforme de compilation Jenkins, voici une série d’article pour comprendre comment cela fonctionne et comment écrire un script Jenkinsfile.

Installer Jenkins sous Windows

Vu qu’il est question de Delphi, le serveur de compilation sera forcément sous Windows. Dans mon cas, l’installation a été faite sur un Windows 2012 R2 n’ayant pas accès à Internet, ce qui compliquait énormément les choses.

Installation de Delphi

Commencez par installer Delphi sur le serveur avec la licence adéquate. Attention, seule les versions de Delphi supportant MSBuild pourront être compilées par Jenkins. Les fichiers à transmettre à MSBuild sont les .dproj. Si vous n’en avez pas, c’est que votre version est trop ancienne.

Lancez au moins une fois Delphi pour qu’il crée son environnement complet, dont entre autres, les fichiers dans %appdata% et certaines clés de registre.

Installation de Jenkins

Commencez par télécharger Jenkins, la version LTS étant recommandée (Long Term Support). Ensuite, lancez simplement l’installation comme pour tout logiciel sous Windows.

Si votre serveur n’a pas accès à Internet, le mieux est encore de faire aussi l’installation sur un poste ayant accès qui vous servira pour installer les extensions que vous reporterez manuellement vers le serveur cible.

Au premier démarrage, Jenkins vous propose toute une série d’extensions par défaut, il est conseillé de les installer.

Une fois installé, Jenkins est présent dans la liste des services et lancé par le compte système. Ce compte ne peut pas accéder à certains fichiers de Delphi qui ne sont créés qu’au lancement de l’IDE (entre autre, le fichier EnvOptions.proj placé dans %appdata%\Embarcadero\BDS\18.0\ si vous utilisez Delphi Berlin).

Il faut donc modifier le compte utilisé pour démarrer le service Jenkins et utilisé celui qui a été utilisé pour installer Delphi, puis redémarrer le service.

Installation des extensions pour Jenkins

Si vous avez laissez Jenkins installer les extensions recommandés, une grande partie est déjà là.

Il ne manque donc que ce qui est spécifique à Delphi. Voici les extensions que j’ajoute personnellement :

  • MSBuild Plugin : obligatoire, c’est la base pour lancer la compilation de projets Delphi à l’heure actuel. Il existe une extension RAD Studio Plugin mais elle ne supporte pas encore les pipelines même si l’auteur a prévu de le faire.
  • Redmine plugin : pour permettre de lier notre projet à une application de gestion de projet.
  • SonarQube Plugin : pour analyser le code Delphi, je consacrerai un article à son utilisation avec Delphi.
  • NUnit plugin : pour effectuer des tests unitaires, malgré son nom, il supporte DUnit dans sa dernière version.
  • Blue Ocean beta : c’est la future interface de Jenkins, qui a l’avantage d’apporter avec elle une multitude de plugins nécessaires à l’utilisation des pipelines.
  • Blue Ocean Pipeline Editor : c’est un éditeur de script intégré qui devrait bientôt nous simplifier beaucoup la tâche !

Configuration de l’extension MSBuild

Allez dans « Administrer Jenkins » puis « Configuration globale des outils ». Cliquez ensuite sur « Ajouter MSBuild » et saisissez un nom pour définir votre outil.

Saisissez dans le premier champ, l’emplacement ou se trouve MSBuild, généralement C:\Windows\Microsoft.NET\Framework\v3.5.

Saisissez ensuite les paramètres :

  • /t:build indique que vous voulez faire une construction complète du projet (recommandé).
  • /p:platform=Win64 indique que vous souhaitez compiler en 64 bits pour Windows. Reportez-vous à l’aide de Delphi pour savoir quelle plateforme utiliser.
  • /p:config=Debug indique que la compilation se fera en mode Debug.

Dans mon cas, j’ai créé deux outils, un pour compiler en mode Debug, et un pour compiler en mode Release.

L’extension MSBuild n’étant pas encore compatible avec les pipelines, les paramètres ne sont pas correctement pris en compte. Il faudra donc les passer dans la ligne de commande dans le script.

Création du projet Multibranch Pipeline

Cliquez sur « Nouveau Item », saisissez un titre, sélectionnez Multibranch Pipeline puis validez.

Une page de configuration s’affiche. La seule partie réellement importante, est la section « Branch Sources ». Elle va vous permettre d’indiquer le serveur de sources vers lequel va pointer Jenkins. Dans mon exemple, c’est Subversion qui va être utilisé.

Notez que l’option « Déclencher les builds à distance (Par exemple, à partir de scripts) » n’est pas fonctionnelle et ne devrait pas s’afficher ici. C’est un bogue connu des développeurs de Jenkins et nous verrons plus loin comment faire pour que Jenkins construise automatiquement une branche quand une livraison de code à lieu.

Sauvegardez la configuration. Jenkins va aussitôt scanner le dépôt pour y trouver les branches et voir si elles contiennent un fichier Jenkinsfile. C’est la présence de ce fichier qui va indiquer si une banche doit être compilée. Et c’est l’écriture de ce fichier que nous allons voir ensuite.

Plus de 3000 téléchargements !

Depuis le 11 février 2013, date à laquelle est sortie la première version sur Windows Phone 8.0, Megatokyo a été téléchargé plus de 3000 fois pour sa version smartphone !

Microsoft ayant changé ses statistiques, il est difficile de connaître exactement le total de téléchargements, la conservation des données n’étant que sur 12 mois, je n’ai donc pas de données précises quant à la version pour Windows 8.1.

Quoi qu’il en soit, sur les 12 derniers mois, Megatokyo 1403 fois, dont 728 sur Windows Phone 8.1 (soit 51,8%), 289 sur Windows 8.1 (soit 20,6%), 272 sur Windows Phone 8 (soit 19,4%) et 114 Windows 10 (soit 8,2%) .

La répartition selon les pays dépend largement des langues supportés (anglais, français, russe, allemand et japonais), sauf les japonais qui boudent complètement l’application (2 téléchargements…) :


La sortie de Windows 10 a étrangement amplifié le nombre de téléchargements sur Windows 8.1, ce dernier ayant été particulièrement boudé.

J’espère que la future version pour Windows 10 (Mobile) aura du succès, mais je n’avance pas bien vite pour le moment !

C’est parti pour la navigation !

Un peu d’avancée encore ce weekend. Je me suis lancé dans l’interface.

J’ai donc mis en place le menu hamburger à gauche avec la gestion de l’historique (bouton dans la barre de titre). Merci à Microsoft de donner des exemples, car ce n’est pas simple de trouver via la documentation comment faire.

Mais au final, c’est vraiment bien. La barre de titre est maintenant 100% configurable puisqu’on peut la remplacer par une barre totalement personnalisée en XAML. Donc tout est possible ! Onglets, champ de recherche, boutons, case à cocher, etc. C’est très simple une fois qu’on a regardé un peu les exemples.

J’ai juste un petit bogue dans l’historique, des fois il tente de remonter trop loin…

Première confrontation avec les applications UWP

J’ai entamé la migration vers Windows 10 (application universelle). C’est très simple venant de Windows 8.1 (application universelle là aussi, ancien modèle évidemment).

J’ai créé un nouveau projet UWP, puis j’ai repris l’intégralité de ce qui était dans le sous-projet « Shared » de l’application 8.1, c’est à dire tout le code « métier » qui n’est lié ni à Windows 8.1, ni à Windows Phone 8.1. Rien à modifier, tout compile parfaitement du premier coup.

Par contre, toute l’interface est à refaire de 0 puisqu’il faut fusionner le sous-projet Windows 8.1 avec le sous-projet Windows Phone 8.1. Je suis en train de lire la documentation et de choisir les différents types de page à utiliser et comment gérer le redimensionnement automatique en fonction de l’écran qui affiche l’application.

Pour le moment, je n’ai que recréé toute les images nécessaires au projet. Il y en a encore plus qu’avant vu que Windows 10 gère la 4K avec mise à l’échelle à 200% et forcément les tailles ont été légèrement modifiées… Il est vraiment dommage que l’on ne puisse pas simplement utiliser des images vectorielles (genre du SVG).

Ca m’a donc pris un temps fou, vu que pour que ça soit nickel, je suis reparti de l’image vectorielle.

Normalement, je pourrai aussi reprendre sans aucune modification, le projet contenant la tâche de fond. Pour celui gérant les tuiles, la définition des textes à énormément changé, il faut que j’adapte ça. En espérant que Microsoft donne des exemples !

Voilà, j’avance tranquillement. J’espère que ce sera prêt pour la Threshold 2 de cet automne !

Ouverture du blog Aarklendoïa

Bonjour à tous !

Après quelques tâtonnements, j’ai décidé d’ouvrir à nouveau un blog sur le développement de mon application Megatokyo, actuellement disponible pour Windows 8.1 et Windows Phone 8.x.

J’y retranscrirai les étapes du développement telles que vous pouvez déjà les trouver sur le forum de Next INpact.

J’espère que quelques-uns me liront et que ça les intéressera !

A bientôt !