Skip to main content

Public Projects in VSTS Preview: First Look

·5 mins

Since April of this year, VSTS has the ability to hold public projects. I have set one up in my account and will show you what it does and how to use it yourself in this post.

What are public projects? #

When working with VSTS, you had to explicitly grant access to certain users who were only then able to access the project. You could say VSTS is private-first, unlike for instance GitHub which is public-first. In fact, until now, you weren’t even able to create public projects with VSTS. 

Public projects allow you to create GitHub-like repositories to which anyone can have (read) access. Of course, all of this in a VSTS UI as we all know and love.

I have been using public projects for a little while now for my project of which I have written a couple of other short learnings. Read here on how I implemented slugs or attempted to get better external link previews.

How to use public projects? #

Since August 2018, public projects have gone into public preview. Which means you can use it yourself, right now! To enable this, go into your VSTS account and find your account settings. I will assume, that since you want to use this preview, you have already enabled the new navigation UI.

Log into your account and to go Admin Settings in the lower-left corner. There, find the Policy portion and set the Anonymous access to projects option to Yes as seen in the screenshot below.

Enabling public projects for your account

With this setting, you have now enabled the public projects for your account. At this point, you can start making projects public on a per-project basis.

Making a project public #

Now, navigate to the project that you want to make public and go to that same lower-left corner we saw before, but this time to go to Project Settings. There, on the first page find a little section called Visibility (ironic that is is so small, no?) and click the Edit button, you can see this in the screenshot below. You now have the option to make this project public to the world! Read all the fine print, set the option to public and save.

Setting your project to public

Setting your project to public

If you want to see what it looks like in this actual example, navigate to and see the result. You should be able to inspect the builds and releases that have been going on there.

Now what? #

Before I tell you about what you can and can’t do with public projects, let me redirect your attention to another new feature of VSTS. It has nothing to do with the public projects feature, really, but it still comes in very handy in my opinion.

You can now select which services of this project you want to enable or disable. Since forever, you have been stuck with and work items and your repository and build/releases and testing. But no more, you can now decide that you don’t want to manage your work items or testing and just code and building. Or, in my case, just building and releasing. All the rest you can just switch off and you don’t have to look at it.

Enabling or disabling services in your VSTS project

Enabling or disabling services in your VSTS project

You can find this in the Project Settings where we just enabled our public project.

Now, in terms of what you can and can’t do, basically, it is what you expect from it. In regard to builds, for example, you can inspect what builds happened when and see their logs. You can also download the artifacts, etc. what you can’t do is look into the actual build definition configuration. Of course, that is what you would expect. There probably is sensitive data in there that you don’t want to expose. But it comes in real handy that the logs are visible so that someone who opens a PR on your repository can see what went wrong with integrating their code.

For the repository, it’s the same story. All code is available upon inspection, it can be cloned and read. Also, associated objects like commits and PRs can be reviewed. If you want users to be able to fork, create branches and submit pull requests, you will have to invite users to contribute.

All of this is also true for work items and the relatively new VSTS feature: wiki. Everything you would expect is there. Your anonymous users will have just enough rights to see everything they need to see without compromising any sensitive data.

Wrapping up #

All documentation on public projects can be found on Microsoft Docs. Since it is in public preview right now, go check it out for yourself!

What the future is going to be for this? No one knows. Microsoft has now acquired GitHub, so the need for these public projects in VSTS has shrunk to a minimum. Microsoft is also still figuring out how they want to handle the amount of hosted build minutes. Right now, you have 240 minutes to spend on builds per month for free. If you are maintaining a popular public repository which validates PRs, etc. you can quickly burn through them. That is something they are still looking into. 

Their competitor AppVeyor, has the policy of giving you unlimited builds if your project is open-source. I’m not sure if Microsoft will follow, but that would be a great gesture and I think a great boost for the number of users who will land their build definitions on VSTS.

If you’re thinking about making a private repository public, check out this handy checklist that Microsoft has created for you with things to consider.

From me you can expect more blogs on my findings in this area and particularly on how to deploy the CFP Exchange project with the help or ARM templates, running Azure Functions and leveraging a service bus. Stay tuned!