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.

Managing your git repository via REST API in VSTS

Let's say you'd like to store some results of a build or a release inside a repository. It could be any reason - easy access, versioning, the only tool you have access to. By default VSTS doesn't provide any kind of git-related steps, which could be helpful in such case. Fortunately, once more its REST API comes to the rescue, giving us an opportunity to fully manage repositories with the possibility to push multiple commits.

Before we start, take a look at the overview to understand what are the general capabilities of this API.

Making an initial commit

Once you have your git repository created in VSTS, you can either initialize it with a commit from the GUI or push an initial commit using API. If you take a look at the example from the documentation:

/
POST /_apis/git/repositories/{repository}/pushes?api-version={version}

and its body:

/
{
  "refUpdates": [
    {
      "name": "refs/heads/master",
      "oldObjectId": "0000000000000000000000000000000000000000"
    }
  ],
  "commits": [
    {
      "comment": "Initial commit.",
      "changes": [
        {
          "changeType": "add",
          "item": {
            "path": "/readme.md"
          },
          "newContent": {
            "content": "My first file!",
            "contentType": "rawtext"
          }
        }
      ]
    }
  ]
}

you'll see mostly self-descriptive properties, which build this JSON. The only thing - oldObjectId - is not so obvious. Basically it's SHA1 of the commit this commit is based on - since there're no commits yet, it's basicaly a string full of zeros.

Pushing data

Making an initial commit is a piecie of cake. What if we'd like to update an existing file? The main issue here is to find an oldObjectId, which is required to actually make a request successful. Once more the API becomes handy here - what we can do is to fetch a list list of all pushes and take the last one. Take a look at the signature from the documentation:

/
GET https://{instance}/DefaultCollection/_apis/git/repositories/{repository}/pushes?api-version={version}[&fromDate={dateTime}&toDate={dateTime}&pusherId={guid}&$skip={integer}&$top={integer}]

What is great about this request is the possibility to filter the data - we don't have to download all pushes, only those from the date interval, made by a specific pusher or maybe only the top N. The response gives us a list of pushes ordered from the newest to the oldest. That is important here is to pass includeRefUpdates=true parameter in the query string. This way we'll get following additional property in the response:

/
{
          "repositoryId": "04baf35b-faec-4619-9e42-ce2d0ccafa4c",
          "name": "refs/heads/master",
          "oldObjectId": "0000000000000000000000000000000000000000",
          "newObjectId": "5e108508e2151f5513fffaf47f3377eb6e571b20"
}

and we're able to refer to the newObjectId property to make an update. Once we have it, we can use once more the endpoint used to create an initial commit with a slightly modified body:

/
{
  "refUpdates": [
    {
      "name": "refs/heads/master",
      "oldObjectId": "5e108508e2151f5513fffaf47f3377eb6e571b20"
    }
  ],
  "commits": [
    {
      "comment": "Added a few more items to the task list.",
      "changes": [
        {
          "changeType": "edit",
          "item": {
            "path": "/readme.md"
          },
          "newContent": {
            "content": "Modified readme file!",
            "contentType": "rawtext"
          }
        }
      ]
    }
  ]
}

Once we post this request, a new commit should be pushed and visible when you access a repository.