Using BaseUri to develop your VSTS extension

When you work on your Visual Studio Team Services or Team Foundation Server extension, you need a VSTS or TFS environment to deploy your extension to. To deploy your extension, you package all your JavaScript, HTML and CSS files into a VSIX and deploy the complete package.

This means that for every small change you make, you need to completely redeploy the package and then use your browser to validate the changes. Fortunately, there is an easier way to pickup changes while developing your extension.

BaseUri property for your manifest

While working on your extension, you can add a the properrty baseUri to your JSON manifest file. If this property is not present, all your files will be loaded from VSTS or TFS. When you add this property, you override the default location of your assets. By letting this property point to your local host you can serve the files locally and your extension will load them into the context of VSTS or TFS.

Take for example the following portion of a manifest:

 "manifestVersion": 1,
 "id": "AnotherSampleExtension",
 "version": "0.0.0",
 "publisher": "",
 "name": "Another Sample Extension",

Now you can add the the following line to enable serving your extension from your local host:

baseUri: "https://localhost:5000",

Do make sure that you specify a HTTPS enabled URL. Now while working on your extension, you can run the extension in the context of VSTS or TFS while are your local file changes are picked up without republishing your extension.

When you are finished with development, just remove the baseUri from your manifest file and publish the extension to the marketplace.

Microsoft is not your enemy

How do you feel about Microsoft? Do you think that Microsoft is a closed company that does everything in its power to win professionals and consumers over to the dark side? If so, you’re not alone. Many have a negative view of Microsoft. But is that view still true? Or is something totally unexpected happening and is Microsoft actually changing?

Microsoft is the enemy

But first, why should you listen to me? I am totally biased. I’m a Microsoft developer, have a Windows Phone, use a Microsoft Surface and I even have a Microsoft Band. I’m a Microsoft Most Valuable Professional (MVP) in Visual Studio and Development Technologies and I wrote several books on Microsoft stuff like Azure, C# and Visual Studio Team Services. I think Microsoft is the best. And I think Microsoft is changing, a lot, and I’m changing with it. It’s changing so much that I started learning Linux and Java and that I have ordered my first ever MacBook. Not because I’m leaving Microsoft but because I’m embracing the new direction that Microsoft is going in.

Live as a Microsoft fanboy

Open Source

My moment of revelation was on April 2014 during the keynote of the Microsoft Build conference. Anders Hejlsberg – C# lead architect and inventor of TypeScript – made a huge announcement on stage in front of thousands of Microsoft developers: he open-sourced the C# compiler and language. Yes, you read it correctly: Microsoft open-sourced one of its biggest projects and put it on GitHub (ok, first it was on Codeplex but that got quickly fixed). That was the first time I started really thinking about open-source and what that would mean for my future. Of course I already used some open source software such as jQuery but I hadn’t given it much thought.

Since April 2014 a lot has changed. One big step is that Microsoft started the .NET Foundation:

The .NET Foundation is an independent organization to foster open development and collaboration around the .NET ecosystem. It serves as a forum for community and commercial developers alike to broaden and strengthen the future of the .NET ecosystem by promoting openness and community participation to encourage innovation.

And the .NET Foundation is doing a lot of work. Big frameworks like .NET Core, the .NET Compiler Platform (Roslyn), ASP.NET Core, Entity Framework Core, MSBuild, and NuGet are all open sourced by the .NET Foundation. They accept pull requests and work completely in the open. You can read the language design notes for C# and you can view recordings of the discussions the ASP.NET team has on YouTube. Outside the .NET Foundation Microsoft is also running a lot of other projects on GitHub. PowerShell, CNTK (Microsofts AI framework behind Cortana), the JavaScript engine in Microsoft Edge and much more. Microsoft is even the top open source contributor on GitHub.

Cross platform

The .NET Core initiative is worth pointing out. This is a major initiative to make sure that .NET isn’t a Windows only platform. .NET Core supports Windows, Linux and Mac OS. Combine this with the Xamarin tooling and you can suddenly write .NET code for platforms ranging from the Microsoft Hololens to an iOS tablet, a Docker container or Raspberry Pi. On top of .NET Core, Microsoft builds ASP.NET Core: a cross platform framework for building modern web applications that can run anywhere. To support this new cross platform movement, Microsoft has also released SQL Server on Linux and made PowerShell run on Linux. This doesn’t mean that Microsoft is abandoning Windows but the world is definitely getting bigger from Microsofts point of view.

Developer tools

And that’s not the only thing Microsoft is doing. When you look at the developer tools and languages that Microsoft builds, there are also a lot of changes. Where Visual Studio previously meant a rich desktop client aimed at developing applications for Windows, Visual Studio now spans a whole family of products:

  • VS Code is a super optimized cross platform code editor that’s developed in open source. A fun fact is that Google uses TypeScript (developed by Microsoft in open source) and VS Code to build Angular 2.
  • Visual Studio for Mac is a fully featured IDE that runs on the Mac and lets you build ASP.NET Core and Xamarin applications.
  • Visual Studio Mobile Center offers cloud and lifecycle features for your mobile applications. Automated builds, cross device testing and distribution are all integrated and the product is growing rapidly. You can get started with just a GitHub account.
  • Visual Studio Team Services is a cloud hosted SaaS solution for DevOps. VSTS helps you with your Agile and Lean processes, gives you a hosted continuous integration and continuous deployment option integrated with automated testing, package management and monitoring solutions for all kinds of languages and environments.

The Cloud

And then there is Microsoft Azure. Microsoft Azure is the cloud solution that Microsoft builds and operates. Azure is huge. It has the highest number of datacenters of all cloud providers and supports a lot of different platforms. If you look at the Azure Marketplace you see solutions like Ubuntu, Oracle, Java, PHP, Hadoop, Blockchain services, and of course .NET. In whatever language on whatever platform you choose to develop, you can run it on Azure.

For me these are really exciting times. I’m eagerly waiting on my first Mac while playing with Bash on Windows and use Pluralsight to get up to speed on the Java world. I can’t wait to see what the future is going to bring but for now I can already say: it’s a great time to be a Microsoft developer.

Questions? Feedback? Please leave a comment!

Exploring Visual Studio “15”: Code Styles

Styling your code is important. You are reading your code more often then you’re writing it. Making sure that reading is as easy as possible, especially when you work with multiple developers on a project, can be a challenge.

Fortunately, Microsoft is investing in Visual Studio to help you with styling your code.

Code Styles in Visual Studio “15” Preview

How do you style your switch statements? Do you use indentations for your curly braces { } ? Where do you place your open brace? Does everyone on your team agree? How do you enforce these kinds of rules?

Visual Studio “15” helps you. If you go to the options menu in Visual Studio “15”, you will find a new group named Code Styles in Text Editor –> C#.

Code Styles - General

It’s now really easy to configure styles for your liking. The Options dialog box shows automatically updated sample code that follow the styles you configure. Figure 2 shows your preferences for indenting the content of a case statement in a switch.

Code Styles - Switch formatting

You can also apply coding styles to the naming of your elements. For example, you can enforce PascalStyling in the names of your symbols. If you go to Options –> Text Editor –> C# –> Code Style –> Naming, you can create a new naming rule. The following configuration enforces PascalStyle naming:

First, you select which symbols you want to apply the naming rule to.

MatchAllElements

Then you define the naming rule. In this scenario, only Pascal Case Name is chosen for capitalization.

PascalCaseStyle

Then finally, you configure the severity of the rule. In this case, I made it an error.

ConfigureNamingRule

Now, if you create a method that doesn’t start with an Uppercase letter, you get an error and an automatic code fix in the editor.

PascalCasing_UppercaseB

Some things that I would like to see for Code Styles is the ability to configure styling as a part of your project in Visual Studio. That way, you can bring your Code Styles under source control and share them with your team. Maybe we can even move the Code Styles to a NuGet package allowing us to share rule sets over multiple projects.

What do you think of Code Styles? Any feedback or comments?

Typings for TypeScript

When using TypeScript, you will need TypeScript definition files to work with external libraries. A lot of those definition files are available on GitHub: DefinitelyTyped. At the time of writing, there are 1708 entries which is to much to show, even for GitHub.

Let’s say you want to work with jQuery. If you look at the DefinitelyTyped folder for jQuery, you’ll find a couple of files:

jQuery-DefinitelyTyped

The extension .d.ts signals that the file is a TypeScript Definition file. To use these files in your project, you can choose to download the Definition file and copy it to your project. But manually downloading and searching for files doesn’t sound like the best option.

Fortunately, there is an easier way: Typings.

Using Typings for TypeScript

One scenario where I used Typings is while developing the open source Folder Management extension that you can find at GitHub.

The Folder Management project uses Node Package Manager to download external libraries that it uses. If you look at the package.json file you can see which packages are used in this application:

{
 "name": "folder-management",
 "version": "1.0.0",
 "description": "Microsoft DevLabs Folder Management extension",
 "keywords": [
 "vsts",
 "tfs"
 ],
 "scripts": {
 "initdev": "typings install",
 "copyfiles": "copyfiles -f node_modules/vss-sdk/lib/VSS.SDK.js node_modules/jquery/dist/jquery.min.js scripts/lib",
 "setup": "npm run initdev && npm run copyfiles",
 "package": "tfx extension create --manifest-globs vss-extension.json",
 "publish": "tfx extension publish --token <token> --manifest-globs vss-extension.json"
 },
 "author": "ALM Rangers",
 "license": "MIT",
 "devDependencies": {
 "copyfiles": "^0.2.1",
 "grunt": "~0.4.5",
 "grunt-cli": "^1.1.0",
 "grunt-contrib-copy": "~0.8.2",
 "grunt-exec": "~0.4.6",
 "grunt-typescript": "*",
 "jquery": "^2.2.2",
 "requirejs": "2.1.22",
 "tfx-cli": "^0.3.19",
 "tsconfig-glob": "^0.4.0",
 "typescript": "^1.7.5",
 "typings": "^0.6.6",
 "vset": "^0.4.24",
 "vss-web-extension-sdk": "^1.96.1"
 }
}

The dependency we’re now interested in is typings. Adding this line to your package.json makes sure that the typings library is downloaded to your node_modules folder. If you then look at the script sections you see a line named initdev that runs a typings install command.
The Task Runner Explorer shows the custom tasks that I defined in package.json. The initdev task is the one we’re interested in.

Task Runner Explorer - NPM tasks

When you run this script, typings looks for a typings.json file and starts downloading the definition files that you need. The typings.json file for Folder Management looks like this:

{
 "dependencies": { },
 "devDependencies": { },
 "ambientDevDependencies": {
 "Q": "github:DefinitelyTyped/DefinitelyTyped/q/Q.d.ts#4de74cb527395c13ba20b438c3a7a419ad931f1c",
 "jquery": "github:DefinitelyTyped/DefinitelyTyped/jquery/jquery.d.ts#470954c4f427e0805a2d633636a7c6aa7170def8",
 "knockout": "github:DefinitelyTyped/DefinitelyTyped/knockout/knockout.d.ts#4de74cb527395c13ba20b438c3a7a419ad931f1c",
 "tfs": "github:microsoft/vss-web-extension-sdk/typings/tfs.d.ts",
 "vss": "github:microsoft/vss-web-extension-sdk/typings/vss.d.ts"
 }
}

You configure a name and a url to each definition file that you want to have. In this case, I’m downloading the files for Q, jQuery, Knockout and the TFS and VSS sdks. The easiest ways to get the URL, is navigate to the file in GitHub and use the ‘Copy path’ button.

If you have the typings dependency downloaded through NPM and you have the typings.json file, you’re ready to run the typings install script. Running this script will give you a new folder named typings. In this folder, there is a main.d.ts file that references all your downloaded definition files. All you have to do, is add a reference to main.d.ts from your TypeScript files and you’re done.

Solution Explorer showing typings

And that’s all there is. Feel free to download the code from GitHub and open the solution in Visual Studio. You’ll then automatically download the NPM packages and be able to use the Task Runner to run the initdev script to download the typings.

Feel free to leave a comment!

 

Why I’m starting to like Git – Part 2

In the previous post, I looked at the distributed nature and local history of Git. In this post I discuss another feature that makes Git particularly powerful: branching.

Branching in Git

If you look at the guidance for branching in TFVC, you will learn that branching is something you should try to avoid as long as possible. There are scenarios where you do need branching but branching in TFVC is hard and easily leads to merging conflicts and branching hell. Often the best branching strategy is having no branches at all.

Git is different. Git promotes branching. In Git it’s customary to create (and delete!) multiple branches a day. Branching can be done completely locally without having to contact the server. When you start working on a new feature, you can easily create a local branch, do your work and merge the changes back to the main line. This allows you to keep development on several features nicely isolated.

Branching in Git is fast. Creating a new branch and switching between branches are operations that run locally on your machine. You don’t have to contact a central server to branch. Merging between branches is also easier in Git then in TFVC.  Since Git knows the completely history, it can see which changes where made since you branched and use this to do a merge as optimal as possible.

While working on some Git projects for VSTS extensions, I created a branch for every new feature I started working on. When finished, I did a pull request (a topic for a future post) or merged the changes locally to the main branch. This is a nice way of working. It makes it easy to have different versions of your application locally and switch between these when the need arises.

Do it yourself!

The following script starts with a new Git repository. You then add two new files and commit these to the current master branch. After that, you create a new branch named dev and switch to it. You then add a third file and commit it. If you now switch back to master, you’ll see that the third file is not visible in your working directory.

git init

New-Item index.html -type File
New-Item readme.md -type File

git add .
git commit -a -m "Initial commit"

git checkout -b dev

New-Item script.js -type File

git add .
git commit -a -m "Added script"
git status

git checkout master
dir

What’s next?

Gits distributed nature gives you a local history and lets you easily create and switch between branches. Another powerful feature that Git offers is pull requests. That’s what the next post will discuss.

So what do you think? Git: love it or hate it?

DevOps on the Microsoft Stack – Pre-order now

The last couple of months I’ve been bussy working on my new book: DevOps on the Microsoft Stack

DevOps on the Microsoft Stack Book Cover 3D

DevOps is a popular subject and Microsoft has a very good tool suite in the form of Visual Studio, Visual Studio Team Services, Team Foundation Server and Microsoft Azure. This books takes you on a tour through these tools.

You’ll learn about a host of features like:

  • Agile Project Management
  • Version Control with TFVC and Git
  • Technical Debt Managament
  • Package Management
  • Continuous Integration and Continuous Delivery
  • Testing and test automation
  • Monitoring

Pre-order now

Writing is almost finished and you can pre-order the book on Amazon or directly from Apress. If you order a copy, please let me know what you’re looking forward to! You can reach me through the comments on this blog or by sending me a tweet (@wouterdekort).

My first Visual Studio Team Services Extension is live!

One of the many privileges of being an ALM Ranger is that you get the chance to participate in private preview programs where you work closely with the product group.
The latest opportunity was around the new Visual Studio Online Extension model. The new Extension model allows you to create your own extensions that plug directly into the VS Team Services web access.
I started out with a simple extension: Folder Management. This extension allows you to create new folders directly from Web Access in both TFVC and Git repositories.
And I’m very pleased to announce that my new extension is now live! The code is at GitHub and will be completely open source from now on. There is also a blog post at the ALM Rangers account with some more details.
If you want to install the extension on your account, please join the Visual Studio Industry Partner Program. This is completely free at the basic level and will give you access to the new Extension model.
Questions? Feedback? Please leave a comment!

Azure Dev/Test labs preview is getting started

Today I woke up to an email inviting me to the new Azure Dev/Test Lab preview program. The preview program can start any moment now!

I’m really excited about this new feature. Especially when it comes to Application Lifecycle Management and Azure, Dev/Test is something a lot of my customers are interested in.

While working in the preview program, you get to directly interact with the product group and the team who’s building the new features. This means you learn from the people who really know it and you have a change to influence the direction of the product!

If you want to know more about Dev/Test labs checkout my previous blog post or Claude Remillards talk on Build (at 18:30). And of course you can also apply for the preview program.

Questions? Anything you would love to see in the Dev/Test labs? Please leave a comment!

Have you seen Build vNext?

Build is an important part of Application Lifecycle Management. Every DevOps pipeline starts with a Build. Visual Studio Online and Team Foundation Server use the XAML based build system for some time now. I’ve used this system in a lot of scenarios, ranging from small applications to complex scenarios with a multitude of customized builds working together.

But now that I’ve seen the new build system and had some time to play with it I’m completely sold. In this post I want to give you a quick intro to Build vNext and show you what it’s all about.

Why a new Build system?

The old build system is based on Windows Workflow Foundation. Microsoft created a set of components that you can use to create build templates. You can also create your own components (such as the Code Metrics I blogged about) and add these to your templates. A template could become very long. The following image shows you the outline of the default template that ships with TFS 2013.

An outline for the Default XAML build template

These Windows Workflow Foundation builds are run by what’s called a Build Controller and a Build Agent. The Agent does the actual work, the Controller manages one or more Agents and distributes the work to them. The Controller and Agent can only run on Windows. This means that cross platform builds, for example build an Xamarin app on Linux and Mac, are not possible out of the box.

Another limitation is that a Controller is linked to one, and only one, Team Project Collection. This means that sharing a build infrastructure between different collections is impossible. This required careful planning and sometimes resulted in customers having multiple build controllers without any real need for it.

Builds are configured by a build definition that uses a specific build template. These build definitions contain all the settings for your build such as which code to build, which tests to run and what do to with the results. The build definitions are not stored in version control. This means there is no audit trail and no way to go back to a previous version.

That’s enough info on the old build system. Let’s look at how the new Build system solves all those
issues.

Introducing Build vNext

While working on this post, Build vNext is now available in public preview on Visual Studio Online. If you go to your VSO account (and if you don’t have one, please create one! It’s free) and select a project you will see a new tab in your menu: Build Preview. This Build System will also be the default build system that’s shipped with Team Foundation Server 2015. Of course the XAML builds will be there for backwards compatibility but whenever possible, the new build system is recommended.

Configuring everything that has to do with your build definitions is now done from Web Access. This means you don’t have to use Visual Studio anymore for configuring builds, immediately making the build system configuration cross platform. Everyone with a browser can create a build.

Builds are no longer based on complex build templates. Instead, a build is simply a list of tasks. Tasks can be anything from running a Visual Studio build, executing a set of tests, calling a PowerShell script or even a custom task you create yourself. In the old build system, creating build tasks required a far amount of knowledge (if you look at tfsbuildextension.codeplex.com you find some extensions created by the community). Fortunately, the new build system is very extensible and much easier then the old one.

A list of tasks that form a new build

Build tasks are essentially a JSON file shipped with other required files (like a PowerShell script). The JSON file describes your tasks with things like a name and description. It defines the  parameters that are required to configure the task and finally it contains the actual logic that needs to run when the task is executed. And best of all, there are plenty of examples already! With Microsofts new open-source focus, it shouldn’t surprise you that the build tasks are developed in the open at Github: https://github.com/Microsoft/vso-agent-tasks.

So, a build is a list of tasks. In addition to the tasks and their configuration, you can set numerous other properties on a build definition such as variables that you want to share between tasks, retention policies (meaning how much finished build results need to be kept around) and the triggers that should start a build. If you look at the next figure, you will immediately see a difference with the old build definition: there are checkboxes instead of radio buttons. This means you can now have a single definition with multiple triggers. Previously, you would have to clone your build definition and configure a different trigger each time to achieve this.

Selecting multiple triggers for a build

Build definitions now also keep track of their history. Any change you make will be saved as a new version. You can view the history of a build definition and compare different versions with each other to quickly figure out what has changed.

A diff showing the changes made to a build definition

There are also changes in the way a build runs. Web Access will give you a live view of the output a build produces. This output is grouped in steps that you can easily navigate and is stored with the build result.

And of course there is something that has to run a build. This is done by the new build agent. A cross-platform, Node.js based runner that can be installed with a simple script on Linux, Mac and Windows. This way. Microsoft has taken the build system completely cross platform, allowing you to have a farm of different build machines that can all be used together.

How does the build system figure out which agent to use? This is done by setting Capabilities on the agent and Demands on the build. Capabilities are automatically discovered by an agent. So installing Visual Studio on a build machine will let the agent know that it can run Visual Studio Builds. This removes the need to manually tag build agents and then add those tags to your build definitions to make sure that a build ends up on the correct machine (if required you can add custom capabilities and demands). There is no concept of a Controller linked to a Team Project Collection anymore. So agents can finally be shared across collections! Does this mean there is no way to restrict agents or have some form of prioritization?

Fortunately, there is. Microsoft introduced the new idea of Pools and Queues. A Pool is defined at the level of your VSO account or TFS Application Tier. Pools can be shared across Team Project Collections. They are used to define permission boundaries. Queues are scoped to the Team Project level and belong to a Pool. This way, a build can be assigned to a queue and then run on Agent.

Configuring Queues and Pools

How can I start?!

Since Build vNext is in public preview on Visual Studio Online, the easiest way to get started is by using your VSO account. Here are some resources to get you started:

And that’s it for now! I encourage you to start using the new build system and if you have any questions or comments, you know where to find me!

What do you want to know about ALM?

Have you ever visited an Ask The Experts event? For those of you who haven’t, ATE are session held at events where you can connect to experts in certain areas and ask the question you want.

For example, at a recent event I spoke at I also did an ATE session. People could just walk in and ask questions. I received questions about optimizing build performance, choosing a branching strategy and the idea behind Release Management and Continuous Deployment just to name a couple.

I did this event together with Hassan Fadili and after that we discussed if it would benefit the community to run ATE sessions online as a webinar.

ATE with the ALM Rangers and MVPs

So we want your feedback. Do you think it’s valuable to have online ATE events around ALM, DevOps and Agile?

We think the best way to find out is to just get started.

If you have any questions around ALM please leave them as a comment on this post. We will collect all questions and then schedule  an online Webinar where Hassan and I and other experts will answer your questions.

One important thing to understand is that we can’t discuss anything that’s under NDA. So questions like when is feature x going to be released? When is the next version of TFS or Visual Studio coming? are not going to be answered.

If there is enough response, we would love to host these sessions once a month for about 30 minutes each time.

So now it’s up to you. If you have any questions or feedback please leave them as a comment. When the questions start to come in we will schedule our first webinar and invite you all to join.