Continuous Integration Service for .NET


#1

There are several services around for CI in other environments, mostly Linux-based, but for long time I haven’t found anything that could make the same for .NET applications.
The only alternative was an instance of TeamCity provided by CodeBetter (http://teamcity.codebetter.com) for Open-Source projects (I deployed couple of projects there), but had the disadvantages of

  • To have a project there you had to fill a form that had to be reviewed
  • The dedicated agents are generally very full
  • Confusionary view and administration (since a user as the full view of all the projects in the server)

I really appreciated the efforts by CodeBetter to support the Open-Source community.

Couple of weeks ago I found out (probably existed for much longer time though) about AppVeyor (http://appveyor.com), a service dedicated exclusively to .NET Continuous Integration.
It offers commercial plans, but it is free for Open-Source projects: in fact, I moved one of my projects (DeveelDB) to the platform, and so far I’m pretty satisfied.
The service offers the same features one can configure in TeamCity, but with an easier interface. It is also possible to configure the build using specific appveryor.yml files at the root of the repository (but I don’t like this approach).
At the present moment, I don’t like the limitation about * .nuspec files for packahing NuGet, which must be placed on the root of the repository: I will write them to request for a configurable path (I keep my NuGet specs in a specific folder).

If you have any other service you use similar to this, please share, r if you have any additional expertise on such specific one, that might be useful for us.


#2

We’re currently using AppVeyor for our dotnet/corefx repo and its working well for us. I don’t know of any options you haven’t already mentioned.


#3

Why not build and ship the NuGet packages on MyGet?
There’s a free for OSS plan, and MyGet Build Services integrates well with GitHub and VSO and is especially designed to handle and produce NuGet packages.


#4

For reference, here are two gallery feeds exposed by other Microsoft teams:


#5

On teamcity.codebetter.com: I took over maintenance of the agents. Still shared, but lots more libraries and tools on them now. We’re monitoring demand as well, so the more builds are run the more agents we will end up with. Feel free to give it a try and give me a shout if registration takes too long. Oh and on the projects overview, you can just “hide all” to get the clutter away :slight_smile:


#6

Yup. We are very familiar with myget and those two particular feeds. .NET Core is in the second feed, however, it isn’t a nightly build for us there and the code isn’t currently from our GH repo.

We are looking at what to do here. We do want nightly builds from the GH repo. We’ll share that plan when we have it. It should be pretty soon.


#7

I wonder why using special and dedicated NuGet servers, since de-facto nuget.org is the main stopping repository for packages. Especially if a project is open-source and has no limitations of usage and reference. I just don’t get it: I’m not trying to say it’s wrong.


#8

@maartenba I’m sincerely grateful to CodeBetter for having given me allowance to your servers for the CI, and I do thank you for the support you give to the open-source community. Anyway, I feel more confortable now using AppVeyor.
I really wish you good luck for the future developments of the ecosystem


#9

We love nuget.org. There’s nothing wrong with it, other than it doesn’t have a super great story for nightlies. There is pre-release and stable. We’d want something less than pre-release so that no one adds a nightly build to their app when they thought they were getting a beta or an RC.

The other issue is that we change package boundaries and naming a fair bit while we’re in the middle of a release. NuGet.org has a strong policy on packages. Once they are up there, they cannot be deleted or modified. That doesn’t work for us while we’re still figuring things out.


#10

I agree: nuget.org is not designed for CI or nightlies. It is a central “production” feed where all consumers get update notifications: you don’t want to annoy all those who are willing to try an early preview with over 200 CI updates until the next meaningful prerelease…

I think this is exactly where MyGet shines.

Set up a development or staging area, and only promote those packages you select to the upstream nuget.org feed. This allows those interested in CI builds to opt-in and out for these updates by enabling or disabling the myget feed in their registered package sources.

And myget feeds allow real deletes, in addition to unlisting.


#11

I see your point @richlander . I presume that is mostly on the strategy you use for deployments: in case of the project I wrote about before (DeveelDB), this wouldn’t apply, because a db-system is such an interconnected set of features (more like a shangai game) that it’s not possible to release a temporary version of it. In fact, I personally setup a deployment profile to only publish stable packages to nuget.org. Again, I might be wrong…


#12

@antonello: I have used Travis CI, which is free for OSS projects - it is useful for testing your .NET app on Mono runtime.
Then there is Appharbor service provider, though its is for web apps. It hooks to your GitHub repo and each commit to that repo will trigger a build on this platform. AppHarbor will also run any tests it finds under your solution (NUnit, etc.) and then will deploy your web app. So is more like a CD than CI.


#13

An interesting alternative would be UhuruSoftware and their support for OpenShift.


#14

#15

Just tried it on MyGet - works like a charm:

  • Add Github repo URL for corefx
  • Set VSINSTALLDIR to C:\Program Files (x86)\Microsoft Visual Studio 12.0 in build configuration
  • …done

.NET Foundation Website | Blog | Projects | Code of Conduct