From hate to love - why I moved to VSTS

This is a short post about my journey from hating to really loving VSTS. In fact, for the last few years I was a hardcore fan of TeamCity and really couldn't find any other tool, which would fit my needs. In fact, VSTS was the last thing I'd use to work on a daily basis(mostly because of my bad experience with TFS/VSO). I'll explain what was the reason of changing my mindset.

Learning curve

What surprised my a lot was actually the learning curve of VSTS. I was used to really digging deeper into configuration to actually make magic happen. Here you just grab something and use it. Want a Grunt runner? It's already installed, not need for some 3rd-party stuff. Want to groups some tasks and reuse them? Just go for tasks groups and use them anywhere you want. Also no annoying "default branch" from TeamCity(in pre 10.0 era) is present so working with your git project is a piece of cake.

All in one place

This is something, which I like the most - I have my codebase, builds and releases, all in one place. No more switching between different tools to do a code review, tweak a build and deploy it. It's easy to use, easy to configure and to monitor.

Technology stack

Other tools are perfectly fine when used with .NET platform. But they're not designed for it - and you feel it. Don't get me wrong - I'm aware of the fact, that creating such applications are not a trivial tasks. But after all those years, I've finally come to a conclusion, that having a tool designed specially for your technologies really makes things easier.

Ready for a cloud

The last but not least - since VSTS integrates with Azure seamlessly, I can develop my cloud applications or move from on-prem without much effort. Just use one of many Azure tasks in your build/release and watch how everything is being collected and deployed. No need to configure additional plug-ins - the best thing here is, that once you use it, you'll ask yourself "why other things can't be so easy?".

Those are just a few reasons why I chose VSTS as my main tool for building and managing my applications. I strongly recommend you to give it a chance, even if you disliked it on the first try - especially with recent and upcoming updates, which makes it even better.

The curse of the babble

We talk. We, as developers, software engineers - whatever you call us - we talk. We talk about implementation details, we talk about our toolset, we talk about performance issues. This this a part of our job - if you don't talk about your code, ideas or problems - you have a problem. To be honest, people are just designed like that - you can talk before you can write. However, there is a one specific "talk", which I believe is a curse and hits whole IT really hard.

Have you ever tried to introduce a new tool for your team? It can be a build server, a source control system or a new library. In most cases it is pretty easy - someone gives an idea, you discuss it, point possible problems. Maybe someone is more experienced with this tool and can decide whether it is a go/no-go. Mostly it is a moderate(or not - you know, each dev knows better) discussion and you can close it within an hour, no strings attached. You know why such discussions are the most definite ones? Because devs know the best, what they expect from a tool and what it can give a team.

On the other hand it is not always true, that a team decides. This is especially true for big companies, which involve tons of bureaucracy. You cannot decide on your own - you have to ask your manager, your architect and your director. There are some DevOps engineers and middleware specialists also. Don't forget to ask your mom, your wife and your dog. You have to ask everybody because everybody knows what you need better than you.

Have you mentioned everyone in your email requests? Good, now let them meet and talk. Let them babble, let them discuss all those things they hardly understand. Just imagine:

  • Dev: Hi All, we need a TeamCity instance accessible for us so we can test our .NET apps build process.
  • Mgr: Hi Joe Director, my team wants a TeamCity server so they can work with it.
  • Joe Director: Architect, don't we have such thing in our infrastructure?
  • Architect: No, we have Hudson only - they should be OK with it. Do they want a whole server? They have to ask our server team.
  • Dog: Bark, bark!
  • Dev: I said we want only a TeamCity instance + we want to build .NET apps...
  • Mom: Your grandpa gave a TeamCity your grandma instead of a wedding ring, I will try to find it...
  • Finance: It costs 1,999.00, we can't afford it this year.
  • Joe Director: What?! I have to pay  2000 for this Hudson server?
  • Wife: Are you getting  2000 extra this month? I'll go shopping, wow!
  • Dog: Bark, bark!
  • Mgr: Why do we want to test build process anyway? Can't you just use MSBuild?
  • Dev: We want to test the 'whole' process and by the way - TC is free!
  • Architect: Is it free? Is it enterprise enough? What about integration? Last year we bought enterprise ESB solution for $100K and since we haven't started to implement it yet, I have to know whether this SimCity will work with it.
  • Finance: SimCity? Can we also get it?
  • Dog: Bark, bark!

Sounds familiar? I think everyone knows that feeling.

They will talk for a month considering whether a tool you mentioned is needed for you. They will spend their time discussing, arguing and trying to prove, that they can or cannot afford it. They don't care, that they will spend money while talking. They will spend much more that your tool costs. Funny fact that they don't seem to care about it.