Quelques enseignements essentiels après 20 ans en ingénierie logicielle

Lorsque j’ai commencé ma carrière en tant qu’ingénieur logiciel il y a vingt ans, je n’aurais jamais pu imaginer l’évolution incroyable que notre domaine allait connaître. L’industrie des technologies de l’information a constamment progressé dans des directions variées, de l’émergence des méthodologies agiles à l’essor du cloud computing, en passant des applications monolithiques aux architectures microservices, et parfois même un retour en arrière. Malgré ces changements permanents, j’ai découvert que certains principes fondamentaux ont su résister à l’épreuve du temps. Ces leçons sont aujourd’hui encore plus pertinentes dans un environnement de plus en plus complexe en ingénierie logicielle.Dans ce billet, je vais partager dix enseignements cruciaux que j’ai tirés au cours de mes 20 années de carrière. Ces principes m’ont aidé à naviguer dans de nombreux projets, à diriger des équipes, et à progresser professionnellement. J’espère qu’ils vous offriront des perspectives essentielles et un regard neuf sur notre métier. 1. Évitez l’optimisation prématurée On se souvient tous de la célèbre citation de Donald Knuth : « L’optimisation prématurée est la source de tous les maux (ou du moins la plupart) en programmation. » Au début de ma carrière, je suis tombé dans le piège de l’optimisation prématurée plus souvent que je ne voudrais l’admettre. J’ai passé des semaines à développer un système de gestion de documents pour des millions d’utilisateurs, pour ensuite découvrir que nous avions à peine un millier de visiteurs par mois. J’ai aussi mis en place des modèles d’accès aux données très sophistiqués pour prendre en charge plusieurs bases de données, alors que seules deux ou trois étaient réellement utilisées.Cela m’a enseigné une leçon importante : il est inutile de construire des abstractions complexes si vous n’allez pas les utiliser. Concentrez-vous sur l’écriture de code simple qui répond aux besoins actuels.L’optimisation prématurée peut mener à des solutions surdimensionnées, plus difficiles à maintenir et à comprendre. Suivre les principes  YAGNI (You Ain’t Gonna Need It) KISS (Keep It Simple, Stupid) DRY (Don’t Repeat Yourself)  dans cet ordre est crucial. Implémentez seulement ce qui est nécessaire au moment où vous en avez besoin.Garder le code simple et clair est essentiel. Quant à la répétition, elle est parfois inévitable dans certains cas, par exemple, lorsqu’une logique partagée est utilisée dans différents contextes. 2. Réfléchissez avant d’écrire du code En tant qu’ingénieurs, nous avons tendance à penser que tous les problèmes se résolvent avec du code. Pourtant, au fil des ans, j’ai appris que parfois la meilleure solution ne nécessite pas de code supplémentaire.Avant d’ajouter une nouvelle fonctionnalité, demandez-vous : « Est-ce vraiment nécessaire ? Peut-on résoudre ce problème sans ajouter du code ? » Chaque ligne de code que vous écrivez devient une responsabilité : elle devra être maintenue, testée, et potentiellement déboguée.N’oubliez pas que votre objectif est de résoudre des problèmes et de créer de la valeur, et non pas simplement de coder. Parfois, la solution la plus efficace et la plus simple consiste à écrire moins de code, voire pas du tout. Réfléchissez donc deux fois avant d’écrire une seule ligne ! 3. Adoptez de bonnes pratiques Tout au long de ma carrière, j’ai constaté qu’adhérer aux bonnes pratiques améliore la qualité du code, la productivité de l’équipe, et le taux de réussite des projets. Cependant, j’ai aussi appris qu’appliquer ces pratiques de manière aveugle, sans comprendre leur contexte, pouvait s’avérer contre-productif.Quand je parle de bonnes pratiques, je fais référence à : Clean Code : Suivez les principes du livre « Clean Code » de Robert C. Martin pour écrire un code plus lisible et maintenable. Toutefois, ne les appliquez pas aveuglément, certaines idées vieillissent mieux que d’autres. Les Design Patterns : Comprenez les modèles de conception et appliquez-les de manière adéquate. Ne les forcez pas là où ils ne sont pas nécessaires, sous peine de rendre votre projet inutilement complexe. Les principes SOLID : Ils permettent de rendre votre code plus modulaire et maintenable, mais, là encore, ne soyez pas trop rigide dans leur application. L’idée n’est pas de suivre ces pratiques de manière rigide, mais plutôt de comprendre quand et comment les utiliser de manière judicieuse. (Single Responsibility) Principe de responsabilité unique : Une classe ou un module ne doit avoir qu’une seule raison de changer, ce qui signifie qu’il ne doit avoir qu’un seul travail ou responsabilité. (Open-Closed) Principe d’ouverture-fermeture : Les entités logicielles doivent être ouvertes à l’extension mais fermées à la modification, permettant d’étendre leur comportement sans modifier le code existant. (Liskov Substitution) Principe de substitution de Liskov : Les objets d’une superclasse doivent pouvoir être remplacés par des objets d’une sous-classe sans affecter la validité du programme. (Interface Segregation) Principe de ségrégation des interfaces : Les clients ne doivent pas être obligés de dépendre d’interfaces qu’ils n’utilisent pas ; les interfaces doivent être spécifiques aux besoins des clients. (Dependency Inversion) Principe d’inversion des dépendances : Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau ; les deux doivent dépendre d’abstractions plutôt que d’implémentations concrètes. 4. Simplifiez toujours plus « Faites les choses aussi simples que possible, mais pas plus simples. » Cette citation souvent attribuée à Albert Einstein m’a toujours guidé dans la conception logicielle.Lorsque vous construisez ou concevez un logiciel, ne le compliquez pas inutilement. Optez pour des solutions faciles à comprendre. Le monde du logiciel est déjà suffisamment complexe ; il n’est pas nécessaire d’ajouter davantage de complications.La simplicité a de nombreux avantages : Un code simple est plus facile à lire, à comprendre et à maintenir. Les systèmes simples comportent moins de points de défaillance. La simplicité permet un développement plus rapide et un débogage facilité.Bien entendu, il faut trouver un juste équilibre entre simplicité et fonctionnalité. Ne sacrifiez pas les fonctionnalités nécessaires sous prétexte de vouloir garder les choses trop simples. 5. Nommez correctement Phil Karlton a dit : « Il n’y a que deux choses vraiment difficiles en informatique : l’invalidation du cache et nommer les choses. » J’ai appris à quel point cela est vrai.Bien nommer les éléments dans votre code a un impact énorme. Cela réduit la charge cognitive…

DKIM SPF, le WTF sur MX

Si vous avez vous aussi des problèmes pour envoyer des emails à des boites Gmail depuis votre boite pro, et que vous avez un message de retour comme ceci, Mail Delevery System This is the mail system at host mo536.mail-out.ovh.net. I’m sorry to have to inform you that your message could not be delivered to one or more recipients. It’s attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <ape.crevin@gmail.com>: host gmail-smtp-in.l.google.com[74.125.206.27] said: 550-5.7.26 This mail is unauthenticated, which poses a security risk to the 550-5.7.26 sender and Gmail users, and has been blocked. The sender must 550-5.7.26 authenticate with at least one of SPF or DKIM. For this message, 550-5.7.26 DKIM checks did not pass and SPF check for [outquest.fr] did not 550-5.7.26 pass with ip: [51.210.91.12]. The sender should visit 550-5.7.26 https://support.google.com/mail/answer/81126#authentication for 550 5.7.26 instructions on setting up authentication. v7-20020adfebc7000000b00307774d73a8si474631wrn.1056 – gsmtp (in reply to end of DATA command)   alors vous êtes au bon endroit. Cependant , je vais pas m’étendre sur le sujet car, c’est relou, ya 2 pellos qui viendront lire cet article, et surtout je pense que ca va être automatisé d’ici peut de tps.  Outil de test Voici deux liens qui permettent de comprendre ce qu’il se passe https://www.mail-tester.com/ Cet outil permet d’avoir pas mal d’info sur votre serveur mail, il m’a permit de debuger le SPF  https://toolbox.googleapps.com/apps/checkmx/ Ce dernier permet de voir comment Google voit les choses… mais en fait je pense qu’il aide pas bcp, je mets ça là…  Ma config J’ai un service email chez OVH (Email Pro), mais mon Register DNS est ailleurs (PlanetHoster) et pour le moment je veux pas changer car mon dns outquest.fr est gratuit à vie chez eux.  Faut savoir qu’à mon avis, si on a tout chez OVH, DNS et MX ça doit se faire tout seul… mais en vrai j’en sais rien.    SPF Voici la ligne supplémentaire que j’ai ajouté à mon DNS TXT 14400 outquest.fr.  « v=spf1 include:_spf.google.com include:mx.ovh.com ~all » Honnêtement je pige pas trop ce que ça fait, ni même si la partie google n’est pas de trop (je pense qu’elle est de trop) mais bon, ça à l’air de marcher alors je touche plus à rien.  DKIM DKIM c’est un échange de clé privé/public pour vérifier que vous envoyer bien du serveur officiel (outquest.fr pour moi) et que vous n’êtes pas un usurpateur (spammer) Pour ce faire, chez OVH ya toute une procédure ici  https://help.ovhcloud.com/csm/fr-dns-zone-dkim?id=kb_article_view&sysparm_article=KB0058101#pour-e-mail-pro Lisez bien toutes les petites lignes et faites gaffe la doc est pas toujours à jour et l’API en beta… Donc faut faire qq manipulation directement via l’API d’OVH https://api.ovh.com/console/#/email/pro à l’étape 3, le status va être à « Todo », puis passer à « waitingRecord » au bout de qq minutes.  Faites l’étape 4 en attendant. Celle ci consiste à rajouter une entrée DNS, qui elle même va mettre du temps à se propager (d’où le status « waitingRecord ») à l’étape 5 ou vous dit qu’il faut attendre que ce status passe à « ready ». Donc revenir à l’étape 3 et retenter de tps en tps jusqu’à obtenir un status « ready ».       Etape 1 [« ovhemp1076131-selector1″ »ovhemp1076131-selector2 »] Etape 2 Etape 3 après qq minutes, le status passe de todo à waitingRecord Etape 4 Pour passer à l’étape 5, il faut que l’état status soit « ready ».  J’ai cru à un délais de propagation lent du CNAME, mais deux jours plus tard, c’était autre chose.  Alors le support d’OVH m’a gentillement répondu qu’il me manquait un point dans mon CNAME. Voici la cible à utiliser :ovhemp1076131-selector1._domainkey.2370.ad.dkim.mail.ovh.net Voici la cible que j’ai configuré :ovhemp1076131-selector1._domainkey2370.ad.dkim.mail.ovh.net. Le targetRecord reçu de l’API est donc faux. Par contre la doc est ok. Donc si on a pas l’oeil, c’est tendu…  Après changement j’ai refais l’étape 3 : { customerRecord: « ovhemp1076131-selector1._domainkey.outquest.fr » header: « from;to;subject;date » lastUpdate: « 2023-06-13T16:34:35+00:00 » recordType: « CNAME » selectorName: « ovhemp1076131-selector1 » status: « ready » targetRecord: « ovhemp1076131-selector1._domainkey2370.ad.dkim.mail.ovh.net » taskPendingId: 0 } Etape 5 On y est, ce coup ci l’API nous renvoit qq chose qui ressemble à la doc.  Résultat En refaisant un test email avec https://www.mail-tester.com/ j’obtiens un score de 8.2/10 (7/10 avant). Ma DKIM est bien configurée.

Azure Devops – Git Flow intro

Intro Git Flow tu connais ? non ? Et Git tu connais ? non…ouais faut faire un effort la monsieur (ou madame). Alors git j’explique pas. Si tu connais pas reviens me voir, mais va tout de suite apprendre qq commandes car c’est juste une tuerie ce truc. Quand t’as connus vss, svn ou team foundation server, tu sais que git te sauve la vie. Il est juste incontournable aujourd’hui. Ho tu pourras faire semblant qq heures, mais tu vas vite te retrouver dans l’impasse. Un conseil, tarde pas trop, apprends git ! Et en ligne de commande, pas avec un outil (quoi qu’un outil peut éventuellement t’aider, mais crois moi, fait tout en ligne de commande…) J’ai personnellement tardé à y passer. Trop. Et j’ai aussi utilisé des outils graphiques. Personne n’est parfait ! Alors si tu es encore la, tu sais ce qu’est une branche, un merge ou un rebase, un commit…   C’est quoi Git Flow ? A lire, surtout le premier : voici 3 liens : https://danielkummer.github.io/git-flow-cheatsheet/index.fr_FR.html https://grafikart.fr/tutoriels/git-flow-742 https://git-flow.readthedocs.io/fr/latest/presentation.html Ca cause Git Flow mieux que moi. Je suis ici pour vulgariser. Alors Git Flow c’est un ensemble de commandes git qui permettent de s’organiser autour du code source d’une application. Git Flow propose une stratégie pour gérer le cycle de vie d’une application coté code source, du développement locale jusqu’aux versions releases finale en passant par des branches qui auront un but précis.  En vrai, c’est juste des commandes git ! C’est une surcouche qui facilite la vie. Enfin en théorie. Perso j’utilise les principes de Git Flow mais pas ses commandes.  Pour expliquer Git Flow, on va se mettre dans un contexte, imaginons la vie d’une application, par exemple Tonder, une app web pour flirter.   V0.0.1 alpha – naissance d’une app Il était une fois un développeur en recherche d’amour (il veut ken à donf) et il lui vient une idée d’application qu’il nomma Tonder. Le dev est tout seul sur son projet. Il bosse dessus comme un ouf et sort sa premiere app Tonder Alpha 0.0.1 Il est content, mais c’est une version alpha. Elle tourne sur un serveur à lui dans sa piaule, bancale, comme son code.  V0.1.0 bêta Arpès quelques jours de discussion avec son hamster, son app ressemble à quelque chose, il veut faire tester son app et la rend disponible en version bêta privé. Il a donc une « prod » (toujours dans sa piaule) et il s’appercoit qu’il devient difficile de travailler directement sur sa prod sans prendre le risque de tout péter. Alors il crée une version « staging » sur laquelle il bosse.  Mais pour le moment, il existe qu’une « version » de son code. Aucun historique, tout est en local sur un disque dur de sa machine. Un virus, un feu domestique, un coup de foudre, pire trouver une meuf et avoir des gosses… il peut tout perdre.  Notre dev se dit qu’il serait bien d’avoir un controleur de code source qui lui permettra de  sauvegarder son code sur un cloud le rendre accessible à d’autre dev via ce cloud pouvoir gérer l’historique de son code  Alors il crée son repo Git, qq part où il sait qu’il sera accessible et disponible.  V1.0.0 Première release officielle Ca y est, notre dev sort enfin au grand publique sa super App. Il est fiert. Il est content. Son poil brille (il a pas pris de douche depuis 72h, 15 cannettes de coca trainent sur le bureau, il ne sait même plus quel jour on est, et si d’ailleurs c’est le jour ou la nuit …) Les retours utilisateurs arrivent. Il les traite comme il peut, avec le mécanisme suivant : « je code en dev locale, puis si ca marche je passe sur staging puis si ca plante pas je balance sur la production ». Il fait tout à la main, pas d’automatisation, il se dit qu’il a pas le temps pour ça et que c’est qu’une petite release de plus, ça prendra 5 min… Ils se dit qu’il aimerait bien un peu d’aide… et prendre l’air… V1.0.547 Ca build à donf Notre développeur ne compte plus le nombre de build qu’il a fait. Toujours à la main. Ce coup ci il décide d’automatiser sa chaine de livraison/deploiement continue. Il passe par : son premier build automatisé : https://reactor.fr/azure-devops-pipeline-ci-cd-first-build son premier deploiement automatisé : https://reactor.fr/azure-devops-pipeline-ci-cd-deploy ses versions automatisées : https://reactor.fr/azure-devops-pipeline-ci-cd-versioning multi environnement : https://reactor.fr/azure-devops-pipeline-ci-cd-environnement Il est vraiment satisfait. Certe il vient d’y passé quelques heures. Mais a présent il ne s’occupe ni de son staging, ni de sa prod. Tout est fait automatiquement. Et du coup il peut prendre l’air… ça lui rappel d’ailleurs qu’il a un chien… mais il est où son chien ? V1.1.41 1er co développeur Enfin un peu d’aide ! Un nouveau dev arrive en renfort. Git devient indispensable.  Jusque là, le repo git contient 2 branches, une master et une develop.  La branche develop est celle que les développeurs utilisent.  La master sert de branche « release ». Quand on estime que l’on a quelque chose, on pousse du code depuis la branche develop vers la master.  Une pipeline s’occupe de mettre à jour le staging dès que la branche develop reçoit un commit. Une pipeline s’occupe de mettre à jour la prod dès que la branche master reçoit un commit. Nos deux devs travaillent en simultané sur la branche dev. A chaque commit, on a run de pipeline, ca fait bcp de deploiement pour parfois pas grand chose. Alors nos deux devs décident de travailler en branche.  Chacun aura sa branche au départ. Mais nos développeurs se rendront compte qu’avoir une branche chacun revient à avoir deux versions de la branche develop (en plus de celle ci). Il ne profite pas des avancés de chacun et attendent que la branche develop soit à jour pour récupérer le travail de l’autre, via des cherry-pick ou des rebases hasardeux. C’est un peu confu, et nos deux devs décident d’appliquer Git Flow avec des branches feature (fonctionalités).  Ainsi, ils peuvent travailler tous les deux sur une feature si il…

Azure Devops Pipeline (CI/CD) – Relancer les services

Services Debian systemctl Suite à mon dernier article, j’ai été confronté à un problème que j’ai mis longtemps à identifier. Lorsque je mets à jour mon site web, mettons celui du staging avec une nouvelle publication, je modifie les fichiers à la racine du projet, c’est à dire var/etc/www/staging.blazordemo.reactor.fr/ dans mon cas. Pour ma part j’applique une politique du "j’effface tout" et "j’upload tout". Pas de remplacement de fichier. C’est plus long mais je suis certain qu’il y a pas un mauvais fichier en ligne.  Hormis des pb de cache ou de rafraichissement, mon site web est bien à jour.  Mais pas mon service Kernel. En tout cas sur linux Nginx, lorsque je rajoute par exemple un controler "api/plateform" coté serveur, si je ne relance pas mon service avec les commandes suivantes : sudo systemctl stop kestrel-staging.blazordemo.reactor.fr.service sudo systemctl start kestrel-staging.blazordemo.reactor.fr.service sudo systemctl status kestrel-staging.blazordemo.reactor.fr.service mon api « plateform » ne sera pas accessible. En tapant ces commandes, l’api est accessible. Il serait bon d’inclure cela dans la pipeline, histoire qu’on est rien à faire à la main à chaque run de pipeline si le code c# est modifié coté serveur. Pour cela, il suffit de rajouter ces lignes : – task: SSH@0 displayName: ‘Restart Kestrel Service’ inputs: sshEndpoint: ‘SSH to Ikoula’ runOptions: ‘commands’ commands: | sudo systemctl stop kestrel-staging.blazordemo.reactor.fr.service sudo systemctl start kestrel-staging.blazordemo.reactor.fr.service sudo systemctl status kestrel-staging.blazordemo.reactor.fr.service readyTimeout: ‘20000’ Ca donne ça dans les ‘logs’ des jobs de l’execution du pipeline :

Azure Devops Pipeline (CI/CD) – Environnement

Problème du dernier post Je me suis bien pris la tête sur le dernier billet au sujet d’un nouveau problème qui est apparu lorsque j’ai voulu diviser mon site web en 2, une partie staging et une partie prod. Ca pourrait tout aussi bien être "preprod", "recette" etc… Avant j’avais qu’un seul site web: blazordemo.reactor.fr. Celui ci a sa config Nginx et son service systemd qui fait tourner Kernel via un proxy sur le port 7777. (voir article ) J’en ai créé un nouveau "staging.blazordemo.reactor.fr".  L’idée est de faire comme les pros, un site web de "staging" et un de "prod".  dev : locale, tambouille de developeur, avec une base de données crado, des machins bricolés, des trucs à jours ou pas… staging:  distante, même environnement que la prod (meme serveur de base de données, même OS, même TOUT, sauf les données qui sont normalement copiés et anonymisés dans le meilleurs des mondes) prod: distante, le site qu’on update le vendredi soir 🙂 Donc j’ai crée "staging.blazordemo.reactor.fr". Sauf que j’ai pas modifié mon service qui fait tourner Kestrel via proxy sur port 7777.  Et j’ai mis un temps fou à m’en apercevoir. (j’ai été jusqu’a faire un gros delete de mon repertoire www. Nginx continuait à me servir un beau site web… même après un reboot. car le service était le meme…) Donc il me faut 2 services… Un de staging, l’autre de prod. Le tout sur un port proxy différent bien évidement.  Bien entendu, ce problème n’existe pas si le staging et la prod ne sont pas sur le meme serveur, ce qui est TRES recommandé. Cependant, je trouve l’exercice intéressant car il pousse dans les retranchements et force à de bonnes pratiques. Mon ancienne technique Dans le projet Blazor Server, dans Program.cs j’ajoutais ceci  Une ligne de compilation conditionnelle qui me changait le port si on était en release (ce que je considèrais comme mon unique prod).  Je pourrais ajouter une condition STAGING avec un port 7776 et m’en servir pour la version staging. A mon sens une directive de compilation n’a rien a voir avec les environnements, je veux dire c’est liés, mais c’est pas son but de définir du paramétrage de port…  Je pense qu’on peut faire mieux, avec les fichiers de conf appsettings.js. Créeons deux autres fichiers de config, un pour la prod et l’autre pour le staging. Normalement vous avez déjà par défaut un fichier appsettings.Development.json launchSettings.json Si vous travaillez avec Visual Studio ou VS Code vous devez savoir que vous avez des options de lancement de votre app qui sont configurable dans le fichier Properties/launchSettings.json Encore un fichier de config qui sème le doute… { « iisSettings »: { « windowsAuthentication »: false, « anonymousAuthentication »: true, « iisExpress »: { « applicationUrl »: « http://localhost:54778 », « sslPort »: 44382 } }, « profiles »: { « BlazorDemo.Server »: { « commandName »: « Project », « dotnetRunMessages »: true, « launchBrowser »: true, « inspectUri »: « {wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri} », « applicationUrl »: « https://localhost:7249;http://localhost:5249 », « environmentVariables »: { « ASPNETCORE_ENVIRONMENT »: « Development » } }, « IIS Express »: { « commandName »: « IISExpress », « launchBrowser »: true, « inspectUri »: « {wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri} », « environmentVariables »: { « ASPNETCORE_ENVIRONMENT »: « Development » } } } } Comme on peut le voir dans la section "profiles", je peux lancer mon app soit : Via IIS Express  Via la commande dotnet run La première est historique, je pense qu’on en parlera plus dans qq temps. Avant .net core on était obliger de lancer un server utilisant le .net Framework sous IIS qui est le serveur de Windows. La version Express est la version de dévelopement. Pour moi c’est voué à mourrir, mais certains ont des habitudes et Microsoft les forces pas à les changers.  Depuis .net Core (et donc .net 5 et 6), on peut executer nos app sur n’importe quel OS et serveur web comme apache ou nginx sous linux. On a un serveur web intermédiaire appelé Kestrel qui fait le job. D’ailleurs c’est lui que l’on utilise en dévelopement.  En executant une commande dotnet run sur notre projet serveur, on lance un Kestrel. C’est lui que l’on veut paramétrer pour avoir une config dev, staging, prod.  C’est possible d’éditer en développement ce fichier pour changer de port. Mais c’est uniquement un fichier de conf pour une execution en dev local. C’est pas un fichier de configuration plateforme de prod.  Je place ça là car c’est un fichier qui peut vous semer le doute lors de vos devops et test local. AppSettings.{ENV}.json On va modifier le fichier appSettings.Developement.json et lui rajouter ceci  { « Plateform »: « Dev », « Kestrel »: { « EndPoints »: { « Http »: { « Url »: « http://localhost:1234 » } } }, « Logging »: { « LogLevel »: { « Default »: « Information », « Microsoft.AspNetCore »: « Warning » } } } Perso je rajoute une ligne "Environment" qui me permet de voir dans sur quel type d’environement je suis (et plus tard de l’afficher dans l’app).  Ce qui nous intéresse c’est la section Kestrel. On ajoute un EndPoints et on lui précise un port.  Faites un dotnet run sur votre projet à présent : On a un warning qui nous dit que l’adresse utilisé va écrasé celle du launchsetting.json. C’est ce qu’on veut. On voit bien la nouvelle adresse http://localhost:1234.  C’était pour la démo, en dev ça sert a rien de faire cela, autant utiliser le launchSettings.json qui est la pour ça. Donc enlever la ligne Kestrel, c’était pour la démo. Par contre on va mettre ces configs pour appsettings.staging.json  { « Plateform »: « Staging », « Kestrel »: { « EndPoints »: { « Http »: { « Url »: « http://localhost:7776 » } } }, « Logging »: { « LogLevel »: { « Default »: « Information », « Microsoft.AspNetCore »: « Warning » } } } et appsettings.prod.json { « Plateform »: « Prod », « Kestrel »: { « EndPoints »: { « Http »: { « Url »: « http://localhost:7777 » } } }, « Logging »: { « LogLevel »: { « Default »: « Information », « Microsoft.AspNetCore »: « Warning » } } } ASPNETCORE_ENVIRONMENT Encore une chose à savoir. Pour déterminer sur quel environement .net se trouve, il utilise une variable d’environement ASPNETCORE_ENVIRONMENT Elle est d’ailleurs clairement définie dans le fichier launchSettings.json à "Development". Donc en dev, le fichier de config appsettings utilisé sera appsettings.development.json Pour que ce mécanisme fonctionne en prod, soit on définie la variable ASPNETCORE_ENVIRONMENT à "Production" soit par défaut, si elle n’existe pas, c’est déjà le cas (attention moi j’ai nommé mon appsettings prod et non production). Le problème c’est que une variable d’environement est définie pour tout…

Tuto AKS – mise en place

Dans cet article nous allons mettre en place AKS sur Azure en ligne de commande. AKS en ligne de commande : https://docs.microsoft.com/fr-fr/azure/aks/kubernetes-walkthrough Prérequis : avoir installer deux VMs sur azure (voir le tuto précédent) En avant Guingamp : az aks create –resource-group TutorialResources –name myAKSCluster –node-count 1 –enable-addons monitoring –generate-ssh-keys Cette commande va créer AKS sur un cluster nommé myAKSCluster avec une seule node et du monitoring. Ca prends qq minutes… La commande va normalement vous renvoyer du JSON avec toute la config installée : Json { « aadProfile »: null, « addonProfiles »: { « omsagent »: { « config »: { « logAnalyticsWorkspaceResourceID »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourcegroups/defaultresourcegroup-eus/providers/microsoft.operationalinsights/workspaces/defaultworkspace-eaeaae83-9dcd-405b-8f02-4e58e0e30bbb-eus » }, « enabled »: true } }, « agentPoolProfiles »: [ { « availabilityZones »: null, « count »: 1, « enableAutoScaling »: null, « enableNodePublicIp »: null, « maxCount »: null, « maxPods »: 110, « minCount »: null, « name »: « nodepool1 », « nodeTaints »: null, « orchestratorVersion »: « 1.14.8 », « osDiskSizeGb »: 100, « osType »: « Linux », « provisioningState »: « Succeeded », « scaleSetEvictionPolicy »: null, « scaleSetPriority »: null, « type »: « VirtualMachineScaleSets », « vmSize »: « Standard_DS2_v2 », « vnetSubnetId »: null } ], « apiServerAccessProfile »: null, « dnsPrefix »: « myAKSClust-TutorialResource-eaeaae », « enablePodSecurityPolicy »: null, « enableRbac »: true, « fqdn »: « myaksclust-tutorialresource-eaeaae-955218b3.hcp.eastus.azmk8s.io », « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourcegroups/TutorialResources/providers/Microsoft.ContainerService/managedClusters/myAKSCluster », « identity »: null, « kubernetesVersion »: « 1.14.8 », « linuxProfile »: { « adminUsername »: « azureuser », « ssh »: { « publicKeys »: [ { « keyData »: « ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxi46MPyNjpH/kBnXxU5t4bPcWpeCrByvAH9p6uzM+IDda+NTrWHpEmUr1IVZS7CXku5lpl6v3WJjuK1E35DdB5s2ewB7VR6iYKHgruqduAeprMdUx34xeXxn7cc9/QC1b83Lw7k+oyYYYoIfYcy9q/beIlBco8Eidj6GxNRk74fHd3H5r99W0pqA4IfIFpksOb19iiO+pgiABgewmAQETldclajNjVuV6G3cVDdFILGUXjSA/Z1d1eWoqh00XbtyY7sl3LkLd6puHTm1Qt5UlcD4mZKpI2ggqWicHVLA2Eq2Fz7GE637CdYsqXXs5eDJUeBA8S+d2fas00zMB4Pyb » } ] } }, « location »: « eastus », « maxAgentPools »: 8, « name »: « myAKSCluster », « networkProfile »: { « dnsServiceIp »: « 10.0.0.10 », « dockerBridgeCidr »: « 172.17.0.1/16 », « loadBalancerProfile »: { « effectiveOutboundIps »: [ { « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/MC_TutorialResources_myAKSCluster_eastus/providers/Microsoft.Network/publicIPAddresses/449f34d6-68cb-49ad-aa08-825d6448e1d7 », « resourceGroup »: « MC_TutorialResources_myAKSCluster_eastus » } ], « managedOutboundIps »: { « count »: 1 }, « outboundIpPrefixes »: null, « outboundIps »: null }, « loadBalancerSku »: « Standard », « networkPlugin »: « kubenet », « networkPolicy »: null, « outboundType »: « loadBalancer », « podCidr »: « 10.244.0.0/16 », « serviceCidr »: « 10.0.0.0/16 » }, « nodeResourceGroup »: « MC_TutorialResources_myAKSCluster_eastus », « privateFqdn »: null, « provisioningState »: « Succeeded », « resourceGroup »: « TutorialResources », « servicePrincipalProfile »: { « clientId »: « f00bf5fa-37b4-42e5-9f2f-33ff3f32c672 », « secret »: null }, « tags »: null, « type »: « Microsoft.ContainerService/ManagedClusters », « windowsProfile »: null } AKS est maintenant installé dans le groupe de ressource « TutorialResources » Lors de la création d’un cluster AKS, un deuxième groupe de ressources est automatiquement créé pour stocker les ressources AKS. Pour ma part il s’appelle DefaultResourceGroup-EUS. Dedans on y trouve ceci : Le premier est un « espace de travail Log Analytics ». Le second est une « solution ».  Pour le moment je ne sais pas trop a quoi correspond ce dernier. Enfin, l’installation d’AKS a généré un troisieme groupe de ressources avec 5 éléments : Dans l’ordre affiché nous avons un équilibreur de charge un groupe de sécurité réseau une adresse IP publique une table de routage un réseau virtuel. Voilà, beaucoup d’élément on été automatiquement installé. C’est une configuration par défaut qu’il faudra bien sûr ajuster aux besoins.  Pour la suite on va avoir besoin de kubectl qui est le client de ligne de commande Kubernetes. Si vous avez DockerDesktop avec la case Kubernetes cochée, vous devriez déjà l’avoir. Sinon vous pouvez toujours l’obtenir avec cette commande : az aks install-cli Pour se connecter à notre cluster aks via kubectl : az aks get-credentials –resource-group TutorialResources –name myAKSCluster   réponse : Merged « myAKSCluster » as current context in C:\Users\Yann\.kube\config   Pour voir les nodes : kubectl get nodes On y est, Kubernetes est installé sur notre cluster et tourne avec une seule node. 

Azure CLI – tuto 2 VMs

Tuto pour apprendre avec Azure CLI à monter des VMs et ensuite utiliser AKS (prochain tuto). Prérequis : avoir un compte Azure (il en existe des gratuits avec 170€ de crédits) et Azure Cli installé sur sa machine. Azure cli : https://docs.microsoft.com/fr-fr/cli/azure/get-started-with-azure-cli?view=azure-cli-latest Création d’une VM 1 Pour tester azure cli, on va lui demander sa version az –version azure-cli 2.0.80 (…) On va maintenant se connecter sur Azure via cette commande az login Cela ouvre un browser pour se connecter au portail web. Après connextion, le terminal affiche les abonnements Azure Nous allons créer un groupe de ressources : az group create –name TutorialResources –location eastus Il n’est pas apparu sur le portail web d’Azure. Sans doute car je n’avais aucune ressources dedans pour le moment. Nous allons maintenant créer notre première Virtual Machine en ligne de commande : az vm create –resource-group TutorialResources ` –name TutorialVM1 ` –image UbuntuLTS ` –generate-ssh-keys ` –output json ` –admin-username yannvasseur ` –verbose Note : sous powershell une commande multi ligne se termine par ` (en bash c’est \ ) j’ai dû rajouter –admin-username yannvasseur ` à cette commande car on avait une erreur sinon. Il faut qq minutes pour créer une VM, voici ce que la commande nous retourne : { « fqdns »: «  », « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Compute/virtualMachines/TutorialVM1 », « location »: « eastus », « macAddress »: « 00-0D-3A-8D-7D-07 », « powerState »: « VM running », « privateIpAddress »: « 10.0.0.4 », « publicIpAddress »: « 13.90.91.229 », « resourceGroup »: « TutorialResources », « zones »: «  » } Pour obtenir plus d’information sur cette VM : az vm show –name TutorialVM1 –resource-group TutorialResources Le listing que vous obtenez est plutot long, mais d’autant plus complet. Remarquez que l’on a pas de password pour l’administrateur. Json results : Si on se connecte sur le portail web Azure, on voit tout ce qui a été créé : Dans l’ordre affiché on a une machine virtuelle Standard DS1 v2 (1 processeurs virtuels, 3.5 Gio de mémoire) sous Linux (ubuntu 18.04), un disque de 30Go SSD premium, un groupe de sécurité réseau (un firewall), une adresse IP publique (13.90.91.229), une interface réseau et un réseau privé virtuel (10.0.0.0/16). L’emplacement est USA est. Tout ca en une ligne de commande ! VM2 On va maintenant en créer une deuxieme parce qu’on est foufou. Mais avant cela on va récupérer des infos sur notre premiere VM concernant notre subnet (sous réseau) afin que nos deux VMs soient sur le même réseau : az vm show –name TutorialVM1 ` –resource-group TutorialResources ` –query ‘networkProfile.networkInterfaces[].id’ ` –output tsv Résultat : /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/networkInterfaces/TutorialVM1VMNic Cette commande nous permet d’obtenir l’id de notre interface réseau VM1. A partir de cet id, on va demander a azure toutes les informations de cette interface réseau : az network nic show –ids /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/networkInterfaces/TutorialVM1VMNic info interface réseau On va devoir récupérer l’id de l’IP (et pour plus tard on aura peut etre besoin de l’id du sous réseau) az network nic show –ids /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/networkInterfaces/TutorialVM1VMNic ` –query ‘{IP:ipConfigurations[].publicIpAddress.id, Subnet:ipConfigurations[].subnet.id}’ ` -o json Voici le résultat, sous forme de donnée JSON : { « IP »: [ « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/publicIPAddresses/TutorialVM1PublicIP » ], « Subnet »: [ « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/virtualNetworks/TutorialVM1VNET/subnets/TutorialVM1Subnet » ] } Maintenant on va créer une deuxième VM avec cette commande az vm create –resource-group TutorialResources ` –name TutorialVM2 ` –image UbuntuLTS ` –generate-ssh-keys ` –subnet /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Network/virtualNetworks/TutorialVM1VNET/subnets/TutorialVM1Subnet ` –admin-username yannvasseur ` –output json ` –verbose Notez que l’on juste rajouté un sous réseau et renommer son nom. Voici le résultat : Use existing SSH public key file: C:\\Users\\Yann\\.ssh\\id_rsa.pub Accepted: vm_deploy_Ud4Y1LjR5olzzHxJhIQ1kNiWStjJCeBn (Microsoft.Resources/deployments) { « fqdns »: «  », « id »: « /subscriptions/eaeaae83-9dcd-405b-8f02-4e58e0e30bbb/resourceGroups/TutorialResources/providers/Microsoft.Compute/virtualMachines/TutorialVM2 », « location »: « eastus », « macAddress »: « 00-0D-3A-18-E6-A5 », « powerState »: « VM running », « privateIpAddress »: « 10.0.0.5 », « publicIpAddress »: « 40.117.142.145 », « resourceGroup »: « TutorialResources », « zones »: «  » } command ran in 103.297 seconds. Et voila notre 2ime VM est créée. Ce qui est vérifié sur le portail web : Nettoyage Si vou souhaitez tout effacer, c’est par ici : https://docs.microsoft.com/fr-fr/cli/azure/azure-cli-vm-tutorial?tutorial-step=7&view=azure-cli-latest

Kubernetes & AKS – Intro

Intro Kubernetes (communément appelé « K8S ») est un système open source qui vise à fournir une « plate-forme permettant d’automatiser le déploiement, la montée en charge et la mise en œuvre de conteneurs d’application sur des clusters de serveurs ». Il fonctionne avec toute une série de technologies de conteneurisation, et est souvent utilisé avec Docker. Il a été conçu à l’origine par Google, puis offert à la Cloud Native Computing Foundation. (Wikipedia) AKS (Azure Kubernete Service) est un service Kubernetes sur Azure. Il permet d’automatiser le déploiement, la mise à l’échelle et le fonctionnement de conteneurs d’application entre des clusters d’hôtes. C’est un orchestrateur de conteneur. Cela signifie qu’il est en charge de monter des conteneurs suivant un plan que l’on fixe. Il peut par exemple automatiser la charge (monter des conteneurs supplémentaire), relancer un conteneur défaillant, prévoir une réduction ou une augmentation de charge (planification) et donc adapter des besoins suivant des critères (horraire, ponctuel, exceptionnel, CPU, Bandwidth…) https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ L’image ci dessous permet d’illustrer ce qu’est un cluster de conteneurs : Un cluster Kubernetes regroupe plusieurs hôtes Docker et les expose sous la forme d’un seul hôte Docker virtuel. Vous pouvez donc déployer plusieurs conteneurs sur le cluster et effectuer un scale-out d’un nombre illimité d’instances de conteneurs. Le cluster prend en charge tous les détails complexes de la gestion, comme la scalabilité, l’intégrité,etc. Structure et topologie Kubernetes dispose d’une structure basée sur un Master Node et des Nodes. Le Master Node contrôle les nodes. Ces dernières sont des machines virtuelles ou physique. Sur une node on peut retrouver un ou des Pods. Un namespace permet de segmenter des pods, volumes, secrets, configmap… On peut avoir deux namespaces (par exemple dev et staging) sur le même cluster. (là où d’habitude on travaillait avec des machines séparées sur une app monolithique) kubectl est l’application en ligne de commande permettant d’interragir avec Kubernetes. Il est possible d’utiliser Kubernetes sur votre machine locale avec Docker Desktop en cochant cet option : Il est donc possible de travailler localement et préparer ses fichier yaml pour AKS (dev, staging, prod) Pour cela il faut aussi préparer nos conteneurs et les déposer sur un registre (Docker Registry sur Azure) afin qu’ils puissent être utilisé par AKS. Ressources pour se former : Podcast Devapps.be Introduction à Kubernetes : https://www.youtube.com/watch?v=b5vJsYR-Vbo La doc microsoft : https://docs.microsoft.com/fr-fr/azure/aks/ Comprendre Kubernetes en 3 minutes : https://www.youtube.com/watch?v=uyiDNcSmwFw (perso j’ai rien compris…) Celle la est mieux https://www.youtube.com/watch?v=QJ4fODH6DXI xavki : https://www.youtube.com/watch?v=vFfngcRPj9M Web2Day 2017 : https://www.youtube.com/watch?v=zztKO0iRX_w&t=175s

Compilation – Deploiement – Debug avec Cordova sous Windows et Mac et avec ou sans VS2015

(Je m’améliore pas en titre…) J’ai mené pas mal d’essai sur Windows et Mac et je vais essayer ici de synthétiser mes résultats. J’ai pris le code openFB et j’ai suivis leur recette de cuisine pour l’installer proprement, sur le mac. Sur le Mac OSx (Yosemite) Appareil Android (Wiko Ridge 4G) et iPad2 branché en USB sur le mac. $ cordova run android –> compile puis lance un run sur mon device android. $ cordova run ios –> compile puis lance un emulateur. –> Si quelqu’un sait comment on lance son app sur un device iOS branché en usb, je suis prenneur ! l’application s’ouvre dans un emulateur iPad2 et fonctionne normalement. Sur Windows 10 : J’ai copier coller le code du Mac sur Windows. Appareil Android (Wiko Ridge 4G) et iPad2 branché en USB sur Windows. $ cordova run android –> compile puis lance un run sur mon device android. $ cordova run ios –> ne fonctionne pas, on est sur Windows, il faudrait utiliser le remote build Avec Visual Studio 2015 : run android appareil–> compile puis lance un run sur mon device android. run ios appareil –> compile (remote build) puis install via iTunes l’ipa. qu’il faut ensuite installer manuellement sur l’iPad. Pour info :l’application s’ouvre sur iPad. J’ai des problèmes d’affichage (bouton sous la barre du haut) et je n’arrive toujours pas a faire fonctionner OpenFB sur iPad en deployant de cette manière. En cliquant sur Login, une page blanche s’ouvre. Je soupçonne InAppBrowser de ne pas bien fonctionner. run ios simulateur iPad2–> compile (remote build) puis lance un emulateur iPad2 sur le mac idem, même problème que précédement (au moins le simulteur est fidèle) run ios rippleiPad2–> ne compile pas  puis lance un chrome, l’affichage est correct, mais le clic sur login m’affiche ceci : A priori, InAppBrowser a du mal avec Ripple aussi. Et c’est valable avec Android aussi (mais vu qu’il ne compile pas, on a une version web dans Ripple)   Et pour le debug ? : D’une manière générale avec Cordova, il est plus simple de travailler en mode web et d’utilser un F12 sur son navigateur pour accéder à la console Javascript et pouvoir debuger son app. Si l’on souhaite travailler sur une version compiler, Android est un plaisir, il fonctionne de la même manière sous Windows et sur Mac. De plus avec Visual Studio 2015, il est possible de debuger grâce à la console javascript. Bref ça marche ! Pour iOS c’est une autre pair de manche. On peut travailler avec Visual Studio 2015 sur un emulateur qui se trouve sur mac, à distance. Ce qui n’est pas rien. Par contre concernant le debug, je ne sais pas si c’est possible. J’ai une erreur de la part du serveur de build sur mac : Spawn ios_webkit_debug_proxy ENOENT que je n’est pas encore résolut. Donc je reste avec mon pb de login sur iOS sous le bras, car je n’ai aucun moyen de debuger correctement. J’ai appris que Ionic (basé sur Cordova) créer des projets xCode. Du coup il y aurait une piste pour pouvoir debuger depuis xCode des projets iOS. A suivre.   Conclusion : En l’état, coder depuis Windows pour du multiplatforme de type Cordova n’est toujours pas intuitif. On doit installer tout un tas de truc avant de pouvoir voir du concret sur iOS et pour le cas d’OpenFb il est en plus difficile de debugger. Travailler sur Android, que ce soit sur Mac ou Windows ça marche ! Donc de mon point de vu, autant rester sur Windows et profiter de Visual Studio 2015. Pour iOS c’est vraiment compliqué. On peut compiler à distance avec un remote build. On arrive à faire des choses. Pour moi le debug ne fonctionne pas (sans doute un mauvais paramétrage). Le test OpenFB à montrer qu’en execution on avait un soucis lorsque l’on compilait/exécutait à distance, mais la compilation/exécution locale elle fonctionne.   J’ai encore du boulot…                

VS2015 et le remote Build sur Mac OSX (Xamarin et Apache Cordova)

VS2015 nous promet de pouvoir créer du code pour une application iOS sur Windows. Je précise ici que je ne coderais pas une ligne, je souhaite simplement configurer mon environnement de dev pour compiler sur iOS et déployer sur mon iPad2 une app "Helloworld". Pour cela trois moyens : Xamarin Apache Cordova Natif Ce qui n’est pas crié sur les toits, c’est qu’il faut absolument une machine Apple sous MacOSx (version Yosemite recommandé) pour pouvoir compiler du code iOS. (Apple l’exige !). Du coup vous avez deux choix : soit vous avez un mac et c’est tant mieux pour vous, soit vous pouvez utiliser macinthecloud. J’ai commencé avec macinthecloud, ça coute pas cher, mais j’ai préféré aller acheter une machine Mac, même si ça coute un bras. Avant de démarrer, il faut préparer votre Mac comme si vous allez créer une application normal avec XCode. Donc il faut installer XCode avant. Il faut aussi un compte AppleId + un compte développeur (99$ par an). Ensuite avec XCode il faut créer un certificat développeur. Puis créer une application avec Xcode (ca permettra de générer un provisionning profile automatiquement). Pour l’iPad (ou votre iPhone), il faut aussi l’enregistrer..bref c’est trop long à détailler ici et cette page le fait très bien : http://developer.xamarin.com/guides/ios/getting_started/installation/device_provisioning/ Commençons par le moyen le plus simple Xamarin : Xamarin : Xamarin permet de coder sur VS2015 (ou sur l’IDE de Xamarin) une application en utilisant que du C#. Pour cela il faut installer Xamarin sur votre Windows ET sur votre Mac. Il faut aussi un compte Xamarin et démarrer un Trial ce qui vous permet d’accéder à toutes les fonctionnalités (et d’éviter des problèmes de licences…) L’idée ici c’est de démarrer rapidement avec un projet de base que l’on nous propose dans iOS : (blank, MasterDetails…) Prenons Master Detail app, c’est juste histoire d’avoir un truc à montrer à l’écran. On ne touchera pas au code. Normalement sur votre interface vous allez avoir des petits boutons comme ceci : Ici on est pas connecté au serveur de build qui se trouve sur le mac. Il faut l’associé (pair). Ici le guide officiel. Vous allez d’abord lancer sur votre Mac Xamarin.iOS Build Host. Il vous propose un code. Notez le. Dans Visual Studio sur Windows ouvrez les options dans le menu ‘outils’, puis descendez sur Xamarin puis iOS Settings Cliquer sur le bouton "Find Mac Build Host". Connectez vous avec l’adresse IP de votre Mac et rentrer le code de pair. Normalement ici vous êtes connecté au serveur de build iOS. Et vous voyez la petite icône verte ! Remarquez aussi que j’ai accès à mon iPad de Yann (relié en USB sur le Mac). Pour disposer de cela il faut au préalable faire tout un tas de truc pas cool avec des certificats, des provisionning truc bidule (vive Android pour ça). Si je lance un run sur VS2015 (Windows) ça balance mon app direct sur mon iPad (USB sur Mac). Et je suis sur Windows !  Yeahhhh ! Trop trop bon ! Apache Cordova : Pour Apache Cordova on va devoir écrire quelques lignes de commandes dans la console. Mais d’abord il faut installer node.js (http://nodejs.org/) sur votre Mac. Une fois que c’est fait, il faut suivre ce doc : https://msdn.microsoft.com/library/mt147405%28v=vs.140%29.aspx#ConfigureVS Lancer sur la console la commande : sudo npm install -g npm@2.6.0 Cela va installer npm qui est gestionnaire de package. Celui ci va vous permettre d’installer plein de truc super qui tourne avec Node.Js. Taper ensuite la commande qui va installer vcremote : npm install -g vcremote Ensuite vous aller lancer un serveur qui va faire tourner vcremote. Par défaut il vous propose un échange sécurisé avec un ‘pin’. (comme avec Xamarin mais en ligne de commande). Personnellement j’ai désactivé la sécurité. Pour cela taper la commande vcremote –secure false Voici ce que vous affiche la console : Super, le serveur est prêt, il nous attends. Pour info, si vous voulez arrêter le serveur, taper CTRL-C. On retourne sur Windows, Visual Studio, outils, options, Multiplateforme, C++, iOS : Il faut paramétrer le serveur. Nous avons choisi pas de sécurité donc la case n’est pas coché. Par défaut le port est 3030. Taper l’IP de votre machine Mac. Puis le bouton Coupler. Normalement votre serveur réagit et affiche ceci : Et votre connexions est réussi sur Visual Studio. Seulement lorsque vous tenter de builder votre application Apache Cordova depuis VS2015, vous avez une erreur. Il vous demande de configurer qq chose. Pour cela allez (sur Windows) dans Visual Studio, outils, options, Outils pour Apache Cordova, Configuration de l’agent distant. Si vous renseignez les même informations, le serveur vous répondra : "GET /modules/taco-remote 404" Alors la j’ai passé un bon moment avant de comprendre qu’en fait, l’agent de build for Apache Cordova n’est pas vcremote mais remotebuild ! Il faut se rendre sur ce site https://www.npmjs.com/package/remotebuild et installer remotebuild sudo npm install -g remotebuild et relancer un serveur remotebuild cette fois (j’ai gardé la sécurité cette fois). Les commandes ne sont pas les mêmes mais se ressemble beaucoup. Sur Visual Studio paramétrer maintenant votre nouveau serveur (attention le port est 3000 par défaut) Tenter maintenant une compilation sous iOS : Vous verrez alors votre serveur s’agiter : C’est bon signe votre app compile ! Ça prend aussi un certain temps.. Maintenant vous pouvez lancer un run sur votre appareil local, mais attention, ce coup ci, branchez votre iphone/ipad sur le connecteur USB de votre Windows. Il vous faudra avoir installer iTunes avant et un panneau vous avertira si vous voulez remplacer l’application existante (pas la première fois bien sûr). Remplacer la pour la mettre à jour. Sur votre iTunes vous aurez l’application qui s’affiche dans le menu Apps : Cliquez ensuite sur le bouton Installer puis sur le bouton appliquer. L’application se transfert depuis iTunes vers l’iPad2. Vous n’avez plus qu’à l’ouvrir. Conclusion : La tâche n’est pas évidente. Compiler depuis Windows sur un Mac n’est pas si simple. De plus j’ai du mal à piger à…