https://docs.microsoft.com/archive/blogs/bartonmathis/feed.xml Modern development on and with the Microsoft stack Tue, 16 Apr 2019 04:46:04 GMT en-US hourly 1 https://docs.microsoft.com/archive/blogs/bartonmathis/application-insights-performance-profiler Mon, 03 Jul 2017 10:20:07 GMT https://blogs.msdn.microsoft.com/bartonmathis/?p=86 https://docs.microsoft.com/en-us/azure/application-insights/app-insights-profiler, which is super-awesome, and seem to work for ASP.NET Core (aspnetcore) apps as well!  Here's a screenshot of the vanilla aspnetcore MVC app, hosted in a basic web app, after being thrashed by 100k hits to the "home" and "about" pages.   Check It out!]]> https://docs.microsoft.com/archive/blogs/bartonmathis/microservices-microdatabases Thu, 29 Jun 2017 00:54:12 GMT https://blogs.msdn.microsoft.com/bartonmathis/?p=105 https://github.com/dotnet-architecture/eShopOnContainers While we're on the topic, the first question I often hear is "what is a microservice?" or "what is the difference between a microservice and SOA?" Seeing as how microservices doesn't even have an actual definition, it's more than a fair question.  If someone is familiar with SOA, then my favorite place to begin discussions is with this image, and to point out something that most folks don't immediately apprehend. It is very common (and usually required) to split and duplicate data across the data stores for each microservice. This blew my mind when I first considered it, but it makes perfect sense, and is a completely reasonable (and appropriate!) thing to do.  In the image below, we'll want to service/release/version/enhance each of the microservices independently.  Let's take Ordering for example. If we don't store enough Identity information in the Ordering service to allow for folks to create orders while the Identity service is being rev'd, we've still got a horizontal dependency that makes those 2 services monolithic in practice. Microservices == Microdatabases + duplication :)]]> https://docs.microsoft.com/archive/blogs/bartonmathis/replace-connectionstring-values-using-transformations-in-team-services Wed, 28 Jun 2017 22:15:49 GMT https://blogs.msdn.microsoft.com/bartonmathis/?p=36 https://blogs.msdn.microsoft.com/devops/2017/04/05/managing-configuration-app-settings-for-multiple-environments-in-your-cd-pipeline/ And be aware of how stinky-easy this is when deploying to Azure web sites.  Note: Creation of variables in Team Services, and slot settings in Azure are typically done by an Operations or Infrastructure/Deployment team, *not* by developers :).

• Managed via Variables in Team Services: https://www.visualstudio.com/en-us/docs/build/apps/cd/deploy-webdeploy-webapps#configure-the-environment
• Managed via Azure slot settings: https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing#configuration-for-deployment-slots

And also for IIS apps https://www.visualstudio.com/en-us/docs/build/apps/cd/deploy-webdeploy-iis-deploygroups#environment-specific-configuration   But what about other app types that don't have tasks that incorporate transforms?  It's still easy, by using Colin's ALM Build and Release Tools task. Specifically, the Replace Tokens task.   Here's a quick walkthrough, using a connection string value as an example.

1. Create a variable in each environment with the name/value pair for the connection string. The "Name" must match the name of our connection string in web.config.
2. Add the "Replace Tokens" task to the release. This will search all files with a .config extension and perform a match against any "names" that match an environment variable.
3. In order to retain the ability to do easy debugging locally, keep the appropriate connection string setting in the web.config.
4. Create "Debug" and "Release" configs that will tokenize the connection string when it is built by VSTS. In our case, it will replace the actual connectionstring value with "__DefaultConnectionString__" so that the replace tokens task from #2 will be able to find/replace it.

That's it!  Debug locally using a local database (or whatever is appropriate), and have releases flow into the release pipeline where all other connection strings will be populated based on the environment in Team Services, or the slot setting in Azure. Easy!  ]]> https://docs.microsoft.com/archive/blogs/bartonmathis/25-2 Wed, 28 Jun 2017 21:19:43 GMT https://blogs.msdn.microsoft.com/bartonmathis/?p=25 https://www.visualstudio.com/en-us/articles/mapping-my-tfvc-actions-to-git]]>