Nebbia Technology

17 December 2017

If you hear these phrases, you might need Microsoft Visual Studio Team Services

There are so many features in Microsoft Visual Studio Team Services that it can be difficult to wrap your head around what all they do and if you’re utilizing the tool to its fullest potential.

Phrases like Stay connected from idea to release and Improve code quality and catch issues early from the Team Services website sound great, but how does it do that? What problems is VSTS solving for me, a development team member or manager?

To help make the abstract features of VSTS a bit more real, I put together some phrases that you might hear that VSTS can help eliminate. When combined with DevOps and agile development practices, VSTS can remove these phrases from your office vocabulary and let everyone focus on the fun part: making awesome software.

I know Carrie asked you to add the button. I’m telling you the bug is more important.

One of the biggest pet peeves of any software developer is being asked by two different people to make two different tasks the priority. With VSTS, everyone at any time can see the order of priority in the backlog. To change a priority, just drag the backlog item that takes precedence above the other!

If you want to formalize what level of priority any given backlog item is, there is a specific field within backlog items to highlight that. Out of the box, you can set the priority to one, two, three, or four.

One is This needs to happen! and four is When you can get to it, this would be nice. Setting these priorities upfront can allow for easier backlog grooming further down the road. Also, nearly everything in VSTS is extensible. If you only want three levels of priority, or perhaps you feel you need five, that’s all able to be customized.

Is Jared going to work on that?

With VSTS, you can add features or user stories as backlog items, or bugs that need fixed. You can re-arrange backlog items and assign priorities to them so everyone knows what to work on next. Team members can be assigned responsibility for a backlog item to reduce finger-pointing.

Now you know who’s responsibility a feature is, what tasks need to happen to complete them, and how long those tasks are estimated to take.

So, when do you think you’ll be done?

It’s done when it’s done the developer mutters under their breath before smiling and saying Maybe next Tuesday. Then next Tuesday arrives and it’s still not done, and the cycle begins again.

There is a better way. VSTS allows you to take big user stories and break them down into smaller tasks. This helps developers figure out what exactly needs to get done before a backlog item is truly finished, and allows them to estimate time for each task. This will give everyone a much better picture of how long a particular backlog item will take to finish.

Then, as the developer moves the tasks from the ‘To do’ to the ‘In progress’ and finally the ‘Done’ column, everyone has a high-level view of what’s done, what’s left to do, and about how long it will take.

That’s weird. It works on my machine.

This is the most classic line delivered by any software engineer. Every software developer has been there, done that, and got the t-shirt. Yes, there is a t-shirt.

But we have an antidote to this tired old line thanks to VSTS. It’s called the build process. Whatever set of steps it takes to compile, build, and test the code can be put into the build process – including whatever esoteric steps it takes to build on that senior dev’s machine.

When you set up a build process, you can set it up to pull in npm packages, run tests, execute PowerShell commandlets, and more. The sky’s the limit, and because there’s one build server the code needs to build on, the phrase should always be It builds on the build machine.

As a bonus, you get a lot of data about each build. See how long it takes to build, if a build failed, and if that’s the case at what step in the process it happened. You can get a build log of when builds happened and when builds failed. No longer is It works on my machine a valid excuse, and now there’s no mystery about why a build succeeded or failed.

Can you send me the code?

Source control allows you to store, share, and manage the history of your code. You can see who’s done what, when, and can get any version of your code at any time. If the phrase Can you send me the code? is uttered at any time in your organization, you have some room for improvement.

VSTS can be used as your source control repository, and indeed, source control is a central to managing your software development workflow. You even have your choice of source control, with Git and Team Foundation Version Control both being first-class citizens on the platform.

Now you can look at any code directly in the browser, see what has changed with it over time, and see who’s changed it. You can clone and check out the code into your favorite code editor or IDE, and then push it straight back into VSTS after making changes. At no point should you be sending code via email.

The customer said there was a bug a while back. Did that ever get fixed?

At any point in time, anyone can see the state of every single bug you have in your system. Whether it is new, approved, committed, done, or removed, you know what’s happening with your bugs and who is fixing them.

In fact, bugs are treated much like features: you put them in the backlog and prioritize them. As a best practice, fix any bugs you plan on fixing before creating more features. The longer you wait, the harder it will be to remember what caused them in the first place, much less how to fix them.

I don’t remember if that ever got tested.

Whether you’re talking about automated testing or manual testing, with VSTS you can create a history of what’s been tested, by whom, and when. You can create Test Plans and follow them, testing for different browsers or operating systems. You can see what tests were run, which passed, which failed, and why.

You should try to strive to create as many automated tests as possible (which can run in the build process), but manual tests are important for full integration testing.

We can’t push the bug fixes live until Sharon’s done with that feature.

Within VSTS, with the combination of source control and a build and release process, you can easily and independently update software features. No more waiting on Sharon!

On the source control side, you can create a branching strategy that helps isolate changes in the code. One tip I recommend is to create a new branch for any backlog item. Once you’re done fixing a bug or adding a feature, you can do a Pull Request into your master branch (or dev, QA, and production depending on how you have your process set up).

Then, you can create a build process that looks for changes in the master branch. Once it sees a change, it builds the code following whatever steps you set up. After the build passes, it can deploy the artifacts (the files the build creates) into the right environment every time there is a new feature added or bug fixed.

It never feels like we are getting anything done.

You can easily see how much work is getting done with VSTS, including a history of productivity. When you make changes to your process, you can see if it’s making a significant difference in productivity over a sprint. Are more features getting delivered? More bugs being fixed? Continuous improvement of your process is key to getting better as a team, and with VSTS you can measure the effects of any organizational or process changes you make.

It’s also a great way to allow everyone to see that yes, you are indeed accomplishing things, which can really help morale in long-term projects.

Conclusion

Visual Studio Team Services can seem overwhelming when you first look at it. The feature list is long, but if you take the time to learn them and integrate them into your process, it’s well worth the effort.

VSTS is the thread that binds the whole development process, start to finish. Deciding what to work on, tracking what’s being worked on, building, testing, and deploying code, these are all of the things that VSTS can help with.

When used correctly, it can help your team speed up development, reduce the number of defects, and most importantly make your customers a whole lot happier.

If you need help with DevOps consulting, custom software development, Azure, or training, get in touch.