Tuesday, 18 April 2017

Quickly share query results with the Web Access

If you really like the Copy Query URL button because it opens a full-screen page with no other link to TFS or VSTS...

You would also know that the query link expires after 90 days. Too bad. Is there a way of getting the same behaviour (without taking into consideration any ACL-specific configuration) without using that link?

Well yes - just add &fullScreen=True to the Web Access URL:

Friday, 7 April 2017

“We don’t ship so often”: why? A reflection on Delivery hurdles.

The last Stack Overflow Developer Survey Results shows that the more a developer ships the happier (s)he is. 
Of course we see a huge amount of people checking in multiple times a day, but also a large amount of people checking in (so potentially building and deploying) much less than that.

So, looking at the other side of the medal: why aren’t you shipping often?

Reasons – as usual – are varied. There might be process constraints (certifications, etc.), hard requirements, but I’ve often seen a heavy reliance on older deployment procedures which are considered too expensive to be replaced by automation. Don’t touch what works, right?

Web applications are a stellar example of this. You might have the most complex web app in the world, but why should you manually move stuff around when you can pack everything in a MSDeploy package?

But that is for Azure and cloud technology and stuff!

Wrong answer! MSDeploy is around since 2009 and it is well supported on-premise as well! So why aren’t you using it for your existing application? It is, after all, the same concept Tomcat uses for its .war files.

This isn’t about throwing years of valuable content in the sink. It is often a matter of trying to split the larger problem into smaller components, and approaching different delivery vehicles. You can retain your existing application as-is, just replacing how you bring it into your production environments.

Sunday, 2 April 2017

How can I monitor my AlwaysOn synchronisation status?

As a Team Foundation Server administrator it is critical to have knowledge of all the components involved by your deployment, and SQL Server is the lion’s share (of course).

As you know I am a huge fan of SQL Server AlwaysOn, a really brilliant High Availability solution. I was wondering if there is a way of having an estimation of where the Database Engine is when you see the Synchronizing state in the AlwaysOn dashboard…

I found out there is a way, and it doesn’t even require any SQL at all. All you need to do is to add the Last Commit Time column on the Dashboard, so you will see the time of the last synchronised commit from the Primary Replica to the Secondary.

Of course it is not an ETA, but it gives a rough idea of how much work is left for the synchronisation.

During this state Team Foundation Server is still available because it relies on the Primary Replica, but remember to not perform any failover otherwise you are going to lose data! If it is a long synchronisation you are doing I strongly suggest to set the Failover Mode to Manual, downtime is always a better trade-off than data loss.

Tuesday, 21 March 2017

Move TFS databases with no downtime, thanks to SQL Server AlwaysOn

If you follow this blog or my Twitter feed you should know I am a massive fan of SQL Server AlwaysOn.

Recently I restored and moved some TFS databases around, and one of them remained on a temporary storage because of the massive size involved. After a while I managed to sort out the primary storage so I could move this database (and its Transaction Log) back to it.

This what I did, no warranties of course but it worked on my machines!

First of all, you need to be aware that you will have a limited availability during this period. It doesn't mean you are going to have an outage, but that you cannot rely on the Secondary Replica while you work on it. Why? Because you need to disable the Automatic Failover and make any Secondary non-readable:

Then suspend Data Movement from the Primary. This means your Primary Replica is not going to sync with the Secondary.

You will get your database to move in a non synchronised state.

Now note down your logical names for the files you need to move. Use these in the following query, the path in the FILENAME is going to be the new destination:

Run this on all servers. You might want to wait for the Secondary to be up-and-running, but don't forget to run it against the Primary too!

Copy all the files to the new destination, once done restart SQL Server on the Secondary:

Now check that if Secondary is in a green state.

If the Secondary is green, resume Data Movement and after the status is Synchronised again perform a manual Failover so that the roles are swapped. Then perform all of the above on the new Secondary and you will be done.

Eventually, don't forget to re-enable any configuration you disabled before performing this!

Friday, 17 March 2017

Settle your team's disputes with an EditorConfig file

Ok, this is a bit too much :) but it is actually possible to settle some disputes on Visual Studio settings by leveraging on an EditorConfig file.

EditorConfig is a broadly adopted open-source file format that enables IDEs to be set in a pre-defined way so that you can have a consistent set of rules across tools. This is an ideal tool for creating a standard set of settings and guidelines to be adopted across the team, and Visual Studio 2017 now supports this format!

Kasey Uhlenhuth wrote a brilliant description of what is supported in the IDE, and the setting area is very well done with an actual example of what you are setting up.

Then you can configure how to enforce your style rules - bear in mind that errors are treated as such, so they would prevent a successful build!

If found in a solution, the .editorconfig file will override the default settings of the IDE – so to have a team-shared convention all you need to do is put the file into the root of the project folder, job done!

Wednesday, 8 March 2017

The new connected marketplace experience: how to buy Package Management for TFS

It is not news that in a Hybrid DevOps stack you might have stuff on-premise and stuff in the cloud, Package Management is a prime example of this.

If you don’t have a Visual Studio Enterprise license for any user in your organisation you’d need to buy some users’ licenses for this service. It is billed through Azure even if you are on-premise and totally disconnected from the internet.

You install it on-premise, but you would still set your billing to an Azure subscription when buying it:

Once you are done you can install the extension. Remember: if you have an Enterprise license (either with or without MSDN) you are already entitled to Package Management so you can install the extension straight away.

Also, if you need to manage your users you can browse to the Users hub (<your TFS>/<your collection>/_admin/_userHub) and assign licenses to whoever requires them:

This is exactly like VSTS, but on your on-premise TFS.

Sunday, 26 February 2017

Handle your NuGet packages’ qualities with Release Views

Are you building NuGet packages for your tools, utilities and libraries? Check.

Are you using SemVer for versioning? Check.

Then you might want an easy way of offering your (internal) packages, sorting them between Release and Prerelease for example. Release Views is what you are looking for.

What is really brilliant is that you already have a baseline set: Release and Prerelease. You don’t have to configure anything, it is already there for you.

What makes lots of sense IMHO is to divide them into Release, Prerelease and CI.

That’s because even if we would all love to have a single feed where you can get all the packages in an independent fashion, it is highly likely that some users might not need a CI package but something more refined instead.
With the latter it is clear that the package is not as good as a beta, making it easier to section your offer for the user as you like. CI is really bleeding edge sometimes, and I believe it is good to have it separated from other builds.