<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>EF on MemoryLeak</title><link>https://blog.memoryleak.ovh/tags/ef/</link><description>Recent content in EF on MemoryLeak</description><generator>Hugo</generator><language>fr</language><lastBuildDate>Mon, 16 Jul 2018 21:24:55 +0000</lastBuildDate><atom:link href="https://blog.memoryleak.ovh/tags/ef/index.xml" rel="self" type="application/rss+xml"/><item><title>Migrations EF Core depuis Octopus</title><link>https://blog.memoryleak.ovh/posts/migrations-ef-core-depuis-octopus/</link><pubDate>Mon, 16 Jul 2018 21:24:55 +0000</pubDate><guid>https://blog.memoryleak.ovh/posts/migrations-ef-core-depuis-octopus/</guid><description>&lt;p&gt;Ca vous est déjà arrivé de déployer en prod une nouvelle version de votre application et d&amp;rsquo;oublier de passer la migration &lt;a href="https://docs.microsoft.com/en-us/ef/#pivot=efcore" target="_blank"&gt;EF&lt;/a&gt; à 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&amp;rsquo;est la panique à bord!&lt;/p&gt;
&lt;p&gt;Histoire de ne plus revivre cette situation inconfortable, on est tenté d&amp;rsquo;avoir recours à la migration EF par le code. Ainsi, on est certains qu&amp;rsquo;a chaque exécution de notre app, la migration sera effectuée si le schéma de la BDD n&amp;rsquo;est pas à jour. Le problème, c&amp;rsquo;est que si la migration se passe mal, on se retrouve à nouveau avec une application plantée en production → retour à la case départ.&lt;/p&gt;</description></item></channel></rss>