Monday, 30 April 2018

Review – Professional Visual Studio 2017

I recently gave a go to this book, because I feel it is important as a stepping stone to whoever is approaching the IDE – remember, there is always somebody who is starting around 😊

It does its job well to be fair, it covers pretty well all the features and it is pretty up-to-date with the RTM release of the IDE. The only problem I find with it is that the Visual Studio release cadence is going pretty fast, so it will always be a matter of playing catch-up with the team. There is so much that is added and updated on a regular basis that it is almost inevitable for a book like this to fall behind.

Regardless of that, there is also a nice introduction to the Continuous Delivery Tools for Visual Studio that happens to be a nice starting point to the DevOps and CD pipelines tools as well – including Code Analysis.

Visual Studio Team Services is mentioned at the end, instead of Team Foundation Server. It is a change that makes sense, as it is extremely quick and easy to get started there instead of installing TFS.

Wednesday, 11 April 2018

On-premise Blue-Green deployments with TFS 2018 Update 2

Like I said in the previous post, modern deployment patterns are not an exclusive of the OTT providers and they are not something that requires using cloud technologies.

After Rolling Deployments, another very common pattern you might want to tackle is Blue-Green deployments. In a nutshell, it means having two identical environments to use in order to deploy new versions of your application with minimal downtime.

It is a bit harder compared to a Rolling Deployment – mainly because there could be countless variations on the technical details, depending on how your environment is composed, but let’s try to jot down a skeleton version of a Blue-Green pipeline you can use.

So in my case, I am using the same application I used in the previous post, with an additional environment (which happen to be a cluster, just to keep things a little more realistic). This is what my pipeline looks like:

Each environments follows the following process:

Let’s say we are running all of this against the blue cluster, which is currently production.

The first phase is an Agent Phase – it swaps production traffic from the blue cluster to the green one. 

I want it to be independent from the environments so that it can deal with the router that manages traffic between the two clusters. As I do not have an appliance or anything special in front of them (I am just playing with CNAME records in my lab domain) this ensures the process is not tied to any machine.

Moreover, this pipeline is designed to be used just after everything is deemed production-ready, so if it fails it is not meant to be ran again without a hitch.

The reason behind this choice is that I wanted to share a general idea of how to do this on-premise, and there might be so many permutations of what you might need to do or what could go wrong that my example with all the possible fail safes in place would have been way too complex.

Up next, the Rolling Deployment we saw in the last post for both nodes of the blue cluster, one at a time.

Then, even if you are running this for a production application you still need to make sure your smoke tests are passing. This is literally the last line of defense before the switch.

Eventually, a warm-up script to ensure that my application is responding correctly when it is going to be used from my users.

Now the magic happens: as soon as you move to the second Environment, traffic is switched to the blue cluster again (which is done with the v2, and warm enough for production traffic) in a seamless way while the whole process goes on against the green cluster.

Of course, there are some things to consider. The first one, is that this pipeline is not designed to be a commit-to-production pipeline: there is no backup mechanism in it and no revert process if one environment fails (this lives with the fact that you should already have the pipelines defined in the previous post though 😊).

You want to use approvals to manage the switch from green to blue, so that only when it is checked then you can go ahead.

Eventually (this is quite important though), your application must be able to cope with environment change – it should be message-based, or stateless. Traditional stateful applications can have problems with it, which can be mitigated with message queues for example, so we are back to square one 😊

Wednesday, 4 April 2018

On-premise rolling deployments with TFS 2018 Update 2

Team Foundation Server delivers – as usual – the periodic snapshot of VSTS goodness on-premise.
One particular feature I am really happy landed in our datacentres is Deployment Groups. With it you can target sets of machines where you are going to deploy your applications on.

It is really amazing because it enables scenarios like Rolling Deployments for your existing applications running on-premise. These patterns are not an exclusive of the big boys!

For example, I am targeting a two node cluster with a very simple ASP.NET MVC application (running on full .NET Framework, so no .NET Core or anything that fancy, pretty much the run of the mill internal application you might find in pretty much any company) like this:

I am targeting one server at a time – it comes as a simple option but this is crucial, as you could do them in parallel.

Then it is fairly straightforward: stop the node draining all the connections (this is quite important) stop the website, deploy the package via the trusted MSDeploy, restart the website and re-join the node.

To handle the cluster nodes, you can easily use the NLB PowerShell cmdlets:

This Release definition is going to run against each of the nodes, making individual node management very easy. Of course it is just a starting point and I am simplifying some of the situations you might find, but all the foundation is there!