One extremely handy open source library for .NET developers is FluentMigrator. This package allows you to script out your database changes as C# classes. The concept is similar to the code first migrations of EntityFramework, but allows you a bit more fine tuned control over deployments and doesn’t tie you to any specific ORM or other database interaction model. For example, it’s easy to control which environments the updates go to with tagging. This can help prevent accidental database updates to production and has already saved me from database restores on a couple of occasions.
If you work with multiple related projects that exist in separate solutions, one of the more useful features of Visual Studio Team Services is the ability to easily implement private NuGet feeds. This service lets you keep development of various pieces more separate and yet still make it easy to integrate your private libraries into your other applications.
There are a number of extensions for Visual Studio that I always keep installed. Time and again they’ve proven their value for me. Maybe they can do the same for you. I haven’t made the full transition from VS2015 to VS2017 as i use 2015 at work and 2017 at home. Some of these have different versions between the two VS versions. The links below are all to the 2015 versions in those cases.
One of the more recent features of cloud computing is what’s called ‘serverless computing’. There are a number of different ways in which it is implemented, but for the most part it’s just a way to set up a code function to be able to run without needing to create an entire application and all it’s resources.
Visual Studio Team Services (VSTS) makes it incredibly easy to deploy Azure Service Fabric applications to your Service Fabric clusters as part of a continuous integration process. There’s just a few easy steps to get it set up and running.
Whether we are developers, project managers, business analysts, stakeholders or anyone else involved in the software development process, we all know that estimates for software development are always wrong: ALWAYS. I have never once been involved in a software project that met it’s estimates or even came close. Sometimes we get the job done earlier than estimated, but usually it runs over. You know it. I know it. We all know it. Even if that estimate seems reasonable at the time we do it, it always ends up being wrong. So why do we still bother to do them?