Hosted agent VMs are destroyed after each use, making them far safer. You don’t want to be running arbitrary code on a private build agent. I should note that using a hosted build pool is critical for security if you want to build pull requests from public forks. No other host can do this easily today using a hosted build pool. It’s possible to run a single build on all three at the same time (fan out/in), like how VS Code does.
Windows, Linux, and Mac build host support in one system.
This is where release management fits in as a central part of CI/CD. That is, they can build artifacts….but then what? How do the bits get where you want, like NuGet, MyGet, a Store, etc. Sure, they have different strengths and weaknesses, and some offer free OSS builds as well, but none of them really has a Release Management story. The existing build systems like AppVeyor, Jenkins, TeamCity, and Travis, can all build a project. This is key since there’s no point in using their builds if users can’t see the results. So why move to VSTS? There’s three reasons for me: A huge thank you goes out to them for their past and ongoing support for OSS. Up until recently I was using AppVeyor for builds, as they have provided a generous free offering for OSS for years. Over the past few weeks I have been moving the build system for the OSS projects I maintain over to use VSTS.
0 kommentar(er)
