Ca vous est déjà arrivé de déployer en prod une nouvelle version de votre application et d’oublier de passer la migration EF à la mano ? Eh ben moi aussi. On se retrouve alors à executer le script sql de migration en urgence, en espérant que tout se passera bien. Bref, c’est la panique à bord!
Histoire de ne plus revivre cette situation inconfortable, on est tenté d’avoir recours à la migration EF par le code. Ainsi, on est certains qu’a chaque exécution de notre app, la migration sera effectuée si le schéma de la BDD n’est pas à jour. Le problème, c’est que si la migration se passe mal, on se retrouve à nouveau avec une application plantée en production → retour à la case départ.
Et si on pouvait appliquer la migration EF par le code, mais pendant le déploiement. Après tout, avec la cli dotnet, il est tout à fait possible d’exécuter une migration. Alors pourquoi ne pas le faire à travers un script powershell durant le deploy ? Si vous utilisez Octopus comme chez Younited Credit, alors c’est possible !
Migration avec la dotnet cli
Supposons que vous ayez découpé classiquement votre application en couche de manière à avoir votre startup project et votre DAL séparés, par exemple :
MyCompany.AppOfTheFuture : application console en .NET Core
MyCompany.AppOfTheFuture.DAL : Votre Data Access Layer, celle qui contient vos repositories Entity Framework, votre DbContext et votre code de migration
Afin d’exécuter une migration avec la cli .NET Core, on peut utiliser la commande suivante depuis PowerShell :
La ressource ef.dll peut être considérée comme l’équivalent de migrate.exe pour EF6. C’est la dedans que se trouve le code qui sera exécuté pour appliquer la migration en base de donnée. Il est important de renseigner le chemin correct de la DLL selon la version de .Net core que vous avez installé.
Les paramètres importants de la commande sont :
ef.dll database update : définit le type d’opération à appliquer sur la BDD. Parmis les options possibles, il existe également la commande create afin d’initialiser une BDD.
–context AppOfTheFutureContext Définit la classe de contexte EF
–assembly “MyCompany.AppOfTheFuture.DataAccess.dll” Définit le nom de l’assembly contenant la classe contexte
–startup-assembly “MyCompany.AppOfTheFuture.dll” Définit le nom de votre startup project. En outre, il s’agira vraisemblablement du projet où se trouve votre appsettings.json et la chaîne de connexion à la BDD.
A la suite de l’exécution de cette commande, si tout s’est bien passé, votre BDD doit être à jour et aligné sur la dernière migration.
Intégration de la migration dans Octopus
Maintenant que nous savons jouer une migration en CLI, la migration depuis Octopus n’est plus très compliquée à mettre en place. En effet, il suffit de jouer un bout de script PowerShell pendant la tâche de déploiement et c’est joué !
A titre d’exemple, on va se baser sur le déploiement d’une webapp Azure et donc du template Octopus Deploy an Azure Web App :
[deploy-azure-webapp]
Dans ce template, il est possible de renseigner un script PowerShell à exécuter en Pre-Deploy/Deploy/Post-Deploy. On va s’intéresser à la mise en place du script pendant le deploy. Si on le fait trop tôt, on ne pourra pas profiter de la valorisation des variables dans notre appsettings.json.
Il nous suffit juste de recopier la ligne de commande précédemment mentionnée dans la section Features / Configuration Scripts et c’est tout bon :
[octopus-custom-script]
L’intérêt de cette approche est de mettre en évidence un problème de base de données rapidement, et surtout avant que votre webapp soit en ligne. Fail Fast! Dans notre cas, si la migration échoue dans Octopus, alors ce dernier ne poursuivra pas le déploiement.
Auteurs
Cet article a été rédigé avec mon ami et collègue Anthony Hocquet. Vous le retrouverez sur son nouveau blog que je vous incite à suivre tant les futurs articles sont prometteurs !
Quand vous souhaitez faire appel à cette fonction on utilisera alors un code de ce type, cette fois ci dans votre code C#.
RegisteredFunction.Invoke("DisplayAlert", text);
On remarque que tout ca fonctionne à base de magic strings (le nom de la methode), que les functions sont obligées de retourner une valeur (void n’est pas prit en compte pour l’instant), et puis ce RegisteredFunction.Invoke c’est vraiment pas super sexy.
Du coup je m’étais dis, ca pourrait être sympa d’au moins cacher RegisteredFunction.Invoke, et voici comment j’imaginais la chose.
On pourrait commencer par définir l’ensemble des fonctions js dans une interface C#, un peu comme ca :
public interface IAlerter
{
bool DisplayAlert(string text);
}
Le choix de l’interface n’est pas complétement anodin, Retyped propose un grand nombre de librairies js exposées sous forme d’interface C#, ce qui nous ouvre la porte a plein de possibilités.
Pour en revenir à notre interface IAlerter, on peut l’injectée dans notre component Blazor à l’aide de l’attribut [Inject], comme ceci.
public class Interoper : BlazorComponent
{
[Inject]
protected IAlerter Alerter { get; set; }
public string Sometext { get; set; }
public virtual void Say()
{
Alerter.DisplayAlert(Sometext);
}
}
Et finalement il nous ne nous manque qu’un petit helper magique produisant une implémentation de l’interface IAlerter se chargeant de faire les RegisteredFunction.Invoke qui vont bien. Un truc qui pourrait ressembler à ca :
var alerter = Substitute.For();
alerter.DisplayAlert(Arg.Any())
.Returns(info => RegisteredFunction.Invoke("DisplayAlert", info.ArgAt(0)));
Evidemment ici, je vous présente la version naïve qui ne fonctionne que pour notre interface, mais avec un peu de reflection on peut rendre cela générique sans trop de mal.
Le fail est sous vos yeux, si vous executez ça dans la console de votre navigateur vous aller voir une très belle exception avec un stack de 3 pieds de long. (@Charly, elle est pour toi celle-ci)
[stack]
Une grosse PlatformNotSupportedException! Impossible d’ utiliser l’api System.Reflection.Emit avec Mono Webassembly. C’est emmerdant, mais en y reflechissant bien, c’est pas déconnant si on veut maintenir un framework pas trop fat dans le navigateur.
L’expérimentation sur ce point précis s’arrete donc la, mais tout n’est pas à jeter.
Je retiens de cette aventure l’organisation du code. Une interface décrivant l’interop javascript, qui sera injectée dans les BlazorComponent, et une implémentation concrète de l’interface, comme ceci.
public class Alerter : IAlerter
{
public bool DisplayAlert(string text)
{
return RegisteredFunction.Invoke("say", text);
}
}
On est pas allé aussi loin que je ne l’aurais espéré, mais qui sait dans une prochaine version de Blazor cela sera peut etre possible.
Depuis quelque temps dans la communauté .NET on parle fait pas mal de marketing autour de Blazor. Je ne vais pas vous présenter cette nouvelle techno… si vous etes ici, c’est que vous connaissez déjà :).
Une des premières choses qui m’a embété fut de voir dans les articles de présentation un mélange sans vergogne du code html et du code .NET wrappé dans la section @functions
Evidemment, ici le code est extremement simple, mais dans la vraie vie j’vous le donne dans le mille on aurait envie de faire des tests unitaires de notre code C#.
Je vous propose donc cette facon de faire. On va créer un classe qui hérite de BlazorComponent et on y mettra notre code métier.
Commençons par créér une classe qui contiendra notre code behind
using System;
using Microsoft.AspNetCore.Blazor.Components;
namespace OwnBlazor.Pages
{
public class GuidGenerator : BlazorComponent
{
public string GeneratedGuid { get; set; }
public void Generate()
{
GeneratedGuid = Guid.NewGuid().ToString();
}
}
}
la seule chose qu’il faut noter ici, c’est que notre classe hérite de BlazorComponent
Passons à notre vue qui est maintenant beaucoup plus propre.
Il y a tout juste quelques jours, on pair programmait avec Anthony sur un projet. Nous nous sommes retrouvés a vouloir combiner au runtime des Expressions trees en fonction de parametres évalués au runtime.
En gros on avait envie d’écrire un truc du genre
Expression predicate = x => x.Id > 1;
puis un peu plus loin
predicate += x => x.Name.Length sexy
Pour faire plaisir à [maitre Etienne](https://twitter.com/EjDel?lang=fr) on va travailler a base de tests unitaires.
Commençons par la version naïve; En cherchant un peu sur la msdn on tombera facilement sur [Expression.AndAlso](https://msdn.microsoft.com/fr-fr/library/bb382914(v=vs.110).aspx) permettant de créer une nouvelle expression qui combine deux Expressions left et right
[Fact]
public void SimpleCombining_Fails()
{
// Arrange
Expression firstPredicate = x => x.Id > 1;
Expression secondPredicate = x => x.Name.Length lambda = Expression.Lambda(binaryexp, parameters);
// Act
Action filter = () => {
var combinedPredicate = lambda.Compile();
var result = _persons.Where(combinedPredicate);
};
// Assert
Assert.Throws(() => filter());
}
On commence par définir nos deux prédicats (left & right) que l'on combine dans une expression binaire AndAlso (et logique) en utilisant comme paramètre générique T le paramètre utilisé dans la premiere expression initiale.
On essaye par la suite d'utiliser la lambda créée pour l'occasion dans une instruction [Where](https://msdn.microsoft.com/fr-fr/library/bb549418(v=vs.110).aspx) que vous connaissez tous en Linq.
Bon, j'avais déjà vendu la méche en disant que c'était une version naïve; effectivement a l'execution vous allez avoir une [InvalidOperationException](https://msdn.microsoft.com/fr-fr/library/system.invalidoperationexception(v=vs.110).aspx)
System.InvalidOperationException: ‘variable ‘x’ of type ‘AndOrExpressions.Person’ referenced from scope ‘’, but it is not defined’
Pour faire simple, dans nos deux expressions initiales, le paramètre x bien qu'il se nomme de la même maniere et soit du même type, il ne s'agit pas du meme objet. x est donc inconnu dans la seconde expression.
Etant donné que les Expressions sont des objets [immutables](https://en.wikipedia.org/wiki/Immutable_object) il va nous falloir un moyen de créer/réécrire une expression donnée.
C'est pour ce genre de cas qu'MS a mis à notre disposition la classe [ExpressionVisitor](https://msdn.microsoft.com/fr-fr/library/system.linq.expressions.expressionvisitor(v=vs.110).aspx). Celle-ci nous permet de traverser l'expression tree et d'apporter des modifications. Rappelez vous que chaque modification produira une nouvelle expression, c'est le principe même de l'immutabilité.
Ok, commencons par créer une visiteur qui remplacera un paramètre T par un autre passé en paramètre.
public class ReplaceExpressionVisitor : ExpressionVisitor
{
private readonly Expression _searched;
private readonly Expression _replacement;
Simple, non?
Du coup si on réécrivait notre test de la facon suivante en imaginant une methode And qui permet de combiner des Expressions
[Fact]
public void ReplacingType_Succeed()
{
// Arrange
Expression firstPredicate = x => x.Id > 1;
Expression secondPredicate = x => x.Name.Length Assert.Equal(people, Anto));
}
Il ne nous reste qu'à définir une methode d'extension qui répond a cette signature, comme ceci :
public static class ExpressionsExtensions
{
public static Func And(this Expression> firstOperand, Expression> secondOperand)
{
var replacement = Expression.Parameter(typeof(T));
var leftVisitor = new ReplaceExpressionVisitor(firstOperand.Parameters[0], replacement);
var left = leftVisitor.Visit(firstOperand.Body);
var rightVisitor = new ReplaceExpressionVisitor(secondOperand.Parameters[0], replacement);
var right = rightVisitor.Visit(secondOperand.Body);
return Expression.Lambda>(Expression.AndAlso(left, right), replacement)
.Compile();
}
}
Cette methode va combiner avec Expression.AndAlso nos deux expressions initiales, mais cette fois ci on aura prit soin de les réécrire en utilisant le même paramètre générique. Et évidemment cette fois-ci, le test est vert :)
Si vous avez déjà eu besoin de déployer un azure webjob via vsts, vous avez du tomber sur ce bon blog post de Thomas Hellstrøm. Néanmoins, en suivant telles quelles les instructions de notre ami Thomas, vous risquer de casser la webapp qui host votre webjob.
Ce blog post va prendre la tournure d’une recette de cuisine, d’un pense bête ; cela m’évitera de me reposer la même question dans quelques mois, et j’espère secrètement que cela puisse aider certains d’entre vous.
On commence donc par utiliser la fonction « Publish as Azure Webjob » à partir de Visual Studio 2017.
Pas la peine d’aller au bout du deploy, ce tool va ajouter le package nuget Microsoft.Web.WebJobs.Publish et créer le fichier « webjob-publish-settings.json » dans le répertoire properties de votre projet.
On passe ensuite sur le build sur VSTS. Thomas nous propose de définir les arguments suivants sur la tache msbuild :
Notez le paramètre « /p:WebPublishMethod=Package », qui produira un fichier zip.
Et en jetant un œil dans le fichier zip, mauvaise surprise, on est en train de packager le dossier bin avec des dll qui vont venir écraser celles qui appartiennent à la webapp.
Du coup j’vous propose de corriger ça.
On commence par changer les arguments de la tache msbuild.
Ça, c’est la poisse: Your account has no free minutes remaining.
Le scénario est à se pendre, tu montes ton projet en intégration continue et après quelques (dizaines) de commit tu te retrouves dans l’impossibilité de complétera une PR ou juste vérifier que le dernier commit n’a pas introduit de régressions.
Du coup je me propose de présenter ici, comment créer à moindre frais un agent de build sur-vitaminé. Et le fait d’avoir une machine un peu costaud, n’est pas un moindre mal ; qui ne s’est pas arraché les cheveux en attendant que l’agent de build hosté veuille bien se lancer et faire son travail… ?
Plutôt que de créer nous même une vm, installer windows, msbuild et tout le nécessaire a un agent de build, on va plutôt utiliser azure DevTest Lab. L’idée est de tirer parti des template de vm qui sont mises a notre dispo.
Après avoir créé votre première instance DevTest lab, on ajoute une vm basée sur l’image Visual Studio Community 2017 (latest release) on Windows Server 2016 (x64).
On va vous demander un login et un mot de passe pour le compte admin de la future vm.
Je vous conseille de stocker votre mot de passe dans le coffre-fort « my secret » pour une plus grande sécurité. (ce n’est donc pas mon mot de passe que vous voyez 😊)
Bon il nous faut maintenant choisir les caractéristiques de la vm. J’ai opté pour 32 GO de ram et 8 vcpu, une D8S_V3, elle ne sera allumée que quelques minutes le temps de faire le build, donc elle ne nous coutera pas bien cher.
Place aux artefacts, il convient de voir cela comme des scripts additionnels qui installeront d’autres programmes/services sur votre vm. Ça tombe bien, l’artefact VSTS Build agent nous procure le service de build qui convient.
Quelques précisions, le champs VSTS account name doit se conformer au pattern suivant : https://{{vsts_account_name}}.visualstudio.com
Le secret correspond une clé privée que vous pourrez crée en vous rendant à l’adresse https://{{vsts_account_name}}.visualstudio.com/_details/security/tokens
Finalement, l’agent pool doit être un pool pré-existant. A vérifier/créer ici : https://{{vsts_account_name}}.visualstudio.com/_admin/_AgentPool
Petit plus, dans le cas ou vous envisagez de builder des projets front, profitez de cette étape pour ajouter l’artefact NODE JS.
Bon, aller y’a plus qu’a cliquer sur OK, attendre quelques minutes et l’agent devrait apparaitre dans le pool que vous avez choisi.
Quoi qu’il en soit pas de panique, si vous vous êtes trompé sur un paramètre des artefacts, il sera toujours possible de retenter l’installation a postériori ou bien de procéder a l’installation manuellement.
Dernier point, si vos crédits azure ne vous permettent pas de laisser cette vm allumée tout le temps, voici deux petites commandes qui vous permettront d’allumer et d’éteindre la vm a volonté. (a utiliser dans une console azure cli
az lab vm {{command}} --lab-name {{devtestlab}} --name {{vm-name}}
--resource-group {{resource-group}}
command : start ou stop
devtestlab : le nom de votre instance DevTest lab
vm-name : le nom de votre vm
resource-group : le nom du resource group ou est installé la vm.
Dernièrement, j’ai pas mal fait joujou avec OData.
C’est quand même super plaisant de pouvoir requêter une source de données via une URL et avec une richesse proche de ce que l’on connait avec du SQL.
Une fois n’est pas coutume je ne vais pas parler de .NET mais plutôt partager avec vous un bout de javascript qui met en évidence la facilité avec laquelle vous pourrez brancher des tables ngtable avec votre backend odata.
Trêve de bavardage, on passe au code :
Pour cette illustration, j’ai utilisé le web service services.odata.org qui expose la base Northwind (sample Microsoft) que l’on a tous croisés un jour.
Juste un mot sur le code, évidemment c’est le service odataTableService qui fait la glue entre OData et ngTable; c’est lui qui permet de réaliser les filtrages et les sorts. Une fois que ce service est disponible dans votre app, regardez avec quelle simplicité, votre controller peut créer une table :
Que ce soit manuellement ou de manière automatique, lorsque l’on parle de déploiement il va nous falloir définir un package de déploiement.
Dans l’univers Octopus, les packages de déploiement sont des fichiers avec une extension .nupkg. Voyons comment en créer un pour un projet de Base de données.
Ajouter une dépendance vers Octopack
Octopack est l’utilitaire que nous allons utiliser pour générer ce package de déploiement. Démystifions le terme, octopack produit un fichier qui n’est autre qu’un zip, contenant les fichiers à déployer ainsi qu’un ensemble de métadonnées et potentiellement des scripts powershell.
Bref, rien de bien extraordinaire.
Pour l’installer dans notre projet de base de données, nous allons utiliser Nuget, qui est un gestionnaire de dépendances très performant et bien connu des développeurs. Cependant il n’est pas facilement accessible lorsqu’on travailler sur un projet SQL/SSIS/SSRS/SSAS.
Pour tromper Visual Studio nous allons commencer par ajouter un projet C# de type console pour faire simple
Ajoutons sur ce projet C# une dépendance vers Octopack.
Dans la nouvelle fenêtre on cherche le package Octopack, et on l’installe.
Après avoir acquitté la fenêtre de preview d’install, la fenêtre «Output» de visual Studio devrait vous confirmer que l’installation s’est bien passée.
Il aurait été formidable de pouvoir l’installer directement dans notre projet de base, mais nous allons devoir transpirer un peu plus pour arriver à nos fins.
Ready ?? Ouvrons le fichier csproj de l’application console et copions la portion de msbuild qui correspond à Octopack
Puis, copions la discrètement dans notre fichier sqlproj, de la même manière à la fin de celui-ci.
Un petit rebuild pour vérifier que tout fonctionne toujours bien… et TADAM y’a toujours pas de package de déploiement généré.
Créer le package
Bon si vous avez été un peu curieux, vous aurez remarqué que la portion de msbuild que l’on a copiée a pour but d’importer un autre fichier msbuild (qui se trouve dans le répertoire packages\OctoPack.3.4.1\tools\OctoPack.targets)
En baragouinant un peu le msbuild, on comprend assez vite que la variable RunOctoPack est initialisée à false et c’est elle qui déclenche ou non la génération du package.
Alors évidemment, une solution possible est de modifier cette variable à true. Néanmoins cela induit qu’un package de déploiement sera créé a chaque build du projet. Ce n’est vraisemblablement pas ce que vous souhaitez.
Je vous propose plutôt d’ouvrir une console DOS et une fois dans le répertoire du projet, tapez la commande suivante :
Si tout s’est bien passé vous devriez avoir une sortie similaire a celle-ci :
Cette fois ci, si vous jetez un œil dans le sous-dossier obj/octopacked de votre projet vous y découvrirez un fichier .nupkg qui est le package de déploiement
A quoi ressemble mon package ?
Pour aller un peu plus loin nous pouvons jeter un œil à ce qui a été produit pour nous par Octopack.
Dernièrement j’ai ressorti ma BeableBone Black histoire de faire une peu de veille techno. J’vous raconterai un de ces quatre en quoi monter une boite peut vite cramer tout votre temps libre, mais c’est pour la bonne cause.
Bref pour en revenir à la Beagle, je ressors mon câble série que j’utilise pour me connecter à la console. Je fais les branchements et go sur le site de Prolific pour récupérer le dernier driver pour Windows 10.
Tiens! bizarre, même après un reboot je n’ai toujours rien qui s’affiche dans mon terminal.
En creusant, je m’aperçois que le driver du câble n’est pas reconnu.
S’en suit plusieurs tentatives de réinstallation et de reboot infructueuses.
Je cherche un peu sur Internet, pas mal de personnes ont des soucis avec des versions contrefaites acheté sur des sites asiatiques. Le mien vient de chez Adafruit, et il fonctionnait parfaitement il y a quelques mois, sur Windows 8.
Ho… tiens réessayons sur cet ancien PC. Ca fonctionne parfaitement!
Énorme je récupère l’installer du driver qui se trouve sur ce dernier;
Je repasse sur mon PC équipé de Windows 10, désinstalle le driver en place, reboot, installe l’ancien driver (fonctionnant sur Windows 8) et surprise, ca fonctionne.
Si ça c’est pas de l’obsolescence programmée! Honteux!
Rien que pour ça, je vous recommande plutôt d’investir dans un câble concurrent comme ce FTDI. J’en possède un également et fonctionne tout aussi bien.
Du coup, je vous dépose le driver fonctionnel, ici. J’espères que cela pourra aider quelqu’un.
Tiens, en prime je poste ici le schéma de branchement du câble Prolific avec la beagle.
Le fil noir va sur le pin 1 (GND)
le fil vert sur le pin 4 (RECEIVE)
le fil blanc sur le pin 5 (TRANSMIT)
Ne branchez surtout pas le fil rouge, c’est du 5V, vous grilleriez la beagle!!