Visual Studio Team Services
I’ve long been using Visual Studio Team Services (rebranded from Visual Studio Online) which allows full application lifecycle managment (issue tracking, code repositories, builds & releases) hosted by Microsoft at visualstudio.com.
It’s completely free for up to 5 users per instance!
If you are a Visual Studio subscriber (Visual Studio Enterprise, (Test) Professional or MSDN) you yourself also don’t count against the limit.
So if your entire company already has MSDN subscriptions nobody has to pay anything. And if not, any developer above the 5 initial users is only 6$/month.
Additionally users who don’t need access to the code (testers, managment) but instead only need access to work items, bugs and the kanban board it doesn’t cost anything either. You can add all of them free of charge as stakeholders.
Fully hosted ALM
As a full Application Lifecycle managment solution, issue tracking via kanban board, git, integrated build definitions, testing and release managment as well as hosted build server are the main selling points and I have used all of them over the years quite happily.
They are continuously adding new features (right now a wiki is in preview mode and lots of existing features have gotten facelifts).
Some people have a negative connotation towards TFS (probably because they had to use Team Foundation Version Control which is the Microsoft’s implementation of a version control system).
However With VSTS you don’t have to use Team Foundation Version Control system as it also supports (and even defaults to) git!
Unlike GitHub VSTS offers unlimited free private repositories (no public repositories though, it’s geared towards enterprise ALM not opensource. Althought those aren’t that far apart anymore).
Adding people to a team is trivial via the settings panel (all they need is a valid Microsoft/Outlook/Live/Whatever is the rebranding of the week account).
After signing up you get your own subdomain at mydomain.visualstudio.com and all your projects are hosted there (don’t worry about git vs. TFVC for now, you get to choose again for every single project you create).
You can add as many projects as you want and each project will come with its own issue tracker, code repositories, build definitions, etc.
Note that you cannot change between Git and TFVC after a project was created (you’d have to delete and recreate the project, thererby loosing anything but the code which you can of course backup). But really, just choose git.
On top of being way more powerful, git lets you keep working productively when you don’t have a connection to the server (distributed vcs), whereas TFVC won’t let you commit until you reconnect (centralized vcs) so you’d end up with a “changes from today” commit (trust me, I’ve been there).
Also note that you can choose between three different processes for managing your issues.
Here’s an excellent overview but most likely your team already uses one of those and you can just stick with it. Again, editing this after project creation is no longer possible.
Since I’m mostly working alone or with max. 1-2 other people the issue tracking doesn’t really affect me much.
Visual Studio technically has integration for the VSTS issues itself (via Team Explorer), however it does take a while to refresh each time and you won’t have access to them if you are not connected to the internet. The later being the main reason why I use my own (I still have at least 2-3 days a month where I don’t have access to internet either plane, trainride, out of the country(*), etc.)
* The last point now being a lot better with the recent EU data roaming regulation
Each project comes with a default repository, but you can add unlimited more!
Most of the time this has come in handy for dependencies (e.g. third party sourcecode, forked+fixed repositories that have been abandoned by the original author but I needed).
Also I migrated old/finalized projects by merging multiple repositories into a single project, e.g. I use one project as a backup of my gitlab account. The VSTS project is called “Opensource” and each gitlab repository is backed up to its own git repository so they are all accessible to me via /Opensource/_git/[reponame].
Similarily all my old WP7 applications no longer clutter the mainpage projects list but are all tucked away into the project WP7 with each application still having it’s full git history in its own repository.
This means that all those projects share one issue tracker and build environment but as they are finished/archived I don’t need issue tracking anymore and build/release allows multiple definitions anyway.
The integrated build service (called hosted agent) is probably my favorite feature.
I used to run Jenkins or TeamCity on a dedicated VM but no more!
It offers 240 free build minutes per month (with a 30 minute limit per build) and you can either bill the exceeding minutes to your account (disabled by default; so if you exceed the limits, builds just won’t run) or you can attach your own build server which you’ll have to pay for on your own (Azure VM, company internal server, etc.).
There are currently three hosted agents, the old one (VS2015) the new VS2017 one and a Linux one. You can run your builds on any of them as long as the preinstalled software allows you to build your code. Also note that only one concurrent build is possible with the hosted agents by default, so if you have lots of builds they will just queue up and execute in order.
If you have additional dependencies, fear not! The tools installer will install your dependencies just in time before the actual build. Really neat if you have a dependency on another executable and you don’t want to distribute it with your git repository.
This also means that you won’t have to use a private agent just because of one or two dependencies that the hosted agents don’t provide - instead just install them during the build.
There are lot’s of predefined build templates that help you get going quickly and each one can be configured with dozens of existings tasks. Plus, if you’re missing something specific, check out the marketplace for lots of additional tasks.
What’s awesome is that you can even build your Xamarin iOS/Android apps on their hosted agents without needing your own iOS build agent.
Hosted vs. private agents
Over the years I have used both routes.
Generally I have found the integrated agents to be a tad slower than using my own build server (which usually is an Azure VM either A2 or D1, so ~4GB RAM, 1-2 cores).
A process that would take 2 minute on my local machine with an older i5 might take 5min on my Azure build agent and might take ~10min on the hosted agent.
I mainly use the hosted agents now for automated deployments of smaller stuff and spin up the Azure VM for bigger builds (by spinning up the build server when needed and shutting it down after the build I can use a beefier one for less money. Instead of running 24/7 it only runs (and costs me money) when it is performing a build). But that’s probably something for another blogpost..
If you have lots of custom dependencies it’s probably better to set up your own build server by installing a private agent.
Note that only one private agent can be attached by default. If you need more, they are 15$/month, however - again - each Visual Studio Enterprise license will grant one additional private agent.
Thus if you have 5 Enterprise licenses this means you can attach up to 6 private agents for free.
All my websites are using the integrated build agent and auto. deploy to staging environments.
Since most of them are static/minimal they require very little build time (<2min).
Upon completion I get an email notification for approval on the production deployment.
After reviewing the staging environment it’s just two more clicks to push it to production as well.
Considering that I anyone can get all this for free this really is a killer platform and I haven’t had any kind of downtime in a while and even if there is an issue they are supper fast in resolving it and publicly informing users while doing so.
Just last week I misconfigured my VSTS instance (read: fucked up hard) by removing the hosted build agent from the security group. It no longer had access rights and thus I couldn’t use it to build anymore.
After ~2h of attempting to fix it I wrote them an email and my issue was resolved within 4 more hours (they had to re-add the hosted agent to the security group from their backend and probably added an item to their backlog that users shouldn’t be able to remove it).
I’ll definitely keep using VSTS for the foreseeable future.