are there any continuous integration service/hosting providers that I can just point at an arbitrary SVN server (given credentials of course) and it'll update to the latest source and build?
I'm interested in building C# projects, ideally, it would be something like the TFS Build manager, or cruisecontrol.net ... though it doesn't have to be those products in particular.
Since you're looking at C# projects, have a look at SourceAnvil. It's a beta at the moment, but you might be able to get involved. It's using TeamCity, which I can recommend as easy to set up if you decide to host your own.
Related
In my current project we are using a TFS Build server for continuous integration (build + run unit tests). We also have a set of automated acceptance tests written as SpecFlow features.
However, these are not integrated into the continuous integration workflow. Today, the application is deployed manually and the acceptance tests are invoked manually.
We would like to automate this in the form of a script/console application or some kind of existing CI tool.
This is what we would like to do periodically, e.g. once every hour:
Ask TFS if there are any new builds
If yes: get the latest successful build from TFS
Deploy the application to our test machine
Execute the SpecFlow tests against the deployed build
Collect the result and present it on some form of web page
Are there any existing tools or frameworks for this? I have read about existing CI servers but they doesn't seem to fit my description. If not, any advice on how to achieve step 1, 2 and 5 programatically or by using command line tools?
In my humble opinion TFS is capable of doing everything that you listed without involving any additional tools. What you might need to do is to setup a Lab Environment and use specific Workflow build definition to achieve it. You need also Test controller and test agents.
The easiest way might be to setup Standard Lab environment which might act in this way -
Build - Deploy - Test workflow
Build got triggered, then got deployed into the lab environment (might be a bunch of either physical or VM machines with installed test agents on them and connected to the Test controller), after that all test are executed and the result is consolidated as a part of the build results.
Hope this helps a bit!
-Rado
I'm looking at migrating from TFS (Team Foundation Server) to Git, but can't find anything matching TFS' support for gated check-ins (also called pre-tested or delayed commits).
Atlassian Bamboo has no support for gated check-ins. TeamCity does support it ("delayed commits" using their terminology), but not for Git. Using Jenkins by itself or Jenkins+Gerrit has huge drawbacks and doesn't come close to the gated check-in functionality in TFS. (Drawbacks explained by the creator of Jenkins himself in this video: http://www.youtube.com/watch?v=LvCVw5gnAo0)
Git is very popular (for good reason), so how are people solving this problem? What is currently the best solution?
We have just started using git and have implemented pretested commits using workflows (I finished testing this just today).
basically each dev has a personal repository which they have read/write access. The build server TeamCity in our case, builds using these personal repositories, and then if successful pushes the changes to the 'green' repository. Devs have no write access to 'green', only TeamCity build agents can write to that, but devs pull common updates from 'green'.
So dev pulls from 'green', pushes to personal, TeamCity builds from personal, pushes to green.
This blog post shows the basic model we are using, with GitHub forks for the personal repositories (using forks means that the number of repositories doesn't get out of hand and end up costing more, and means that the developers can manage the personal builds, as they can fork and then create the team city build jobs to get their code pushed to 'green'):
This is more work to set up in TeamCity as each developer has to have their own build configuration. Which actually has to be 2 configurations as TeamCity seems to execute all build steps (including the final 'push to green' step) even if the previous build steps fail (like the tests :)), which meant that we had to have a personal build for the developer, then a another build config which was dependent on that, which would just do the push assuming the build worked.
Check out Verigreen - A lightweight, server side gated check-in system. It verifies each commit before it finds its way into the branches the system protects. Verigreen will not allow any failed CI commit to break the integration, release, or any branch that need be protected.
Moreover – it's a free, open-source project.
How it works:
Verigreen intercepts check-ins and runs verification in an ad-hoc branch - so that in case of failed commit, only the relevant developer is affected.
A pre-receive hook intercepts and creates an ad-hoc branch of the code.
Verification is run via a Jenkins job. The verification job content is fully configurable.
The verified code is merged back into the protected branch whereas a failed commit is blocked with a notification sent to the developer.
Decisions are made based on the following flow:
For more information, please see the wiki or Verigreen.io site
I think that after October 23, 2013 the answer can be - Automatic Merge in TeamCity.
git has different philosophy - commits are easy, commit as you wish. If something wrong, you can change it later. And merges are easy. So, you could organize a appropriate workflow, e.g. developer(s) could commit in a separate branch(es). When a branch is tested, it could be merged into a main branch.
Why not use TFS as the central repository and make use of GIT as a local DVCS solution?
This would allow you to build and commit locally and then push what you want to the TFS server and do a gated build.
Sometimes it is good to have the best of both worlds...
With VS Team Services (fka Visual Studio Online) and TFS 2015 or newer you can use branch policies requiring a passing build for a pull request as a gated checkin workflow with Git.
I'm starting out on a new project and a team member has decided to use C# as the implementation language. I don't have a lot of experience in C#, but a brief reading shows that it's very capable of being a complete cross-platform vm. Beyond the language, I've been having trouble selecting tools and workflows for managing the code as the project grows. It should be fairly small (<10K lines) but I would like to have the ability to generate documentation as the project grows, manage any external dependencies that we decide to use, and automate builds and testing. I am wondering what tools are commonly used or considered best practices for this language.
I am mainly concerned with how would a build system potentially work on *nix as well as windows? Are there C# specific tools or is Make more common? In addition, I'd like to use a dvcs, but it doesn't look like Visual Studio and MonoDevelop support the same ones. What's the common vcs of choice for C#? For testing sort of Unit testing is available for C#/Mono? Finally, I know that there are good doc generators, but with the question of the build system, I would really like to have that just be a single step in the build similar to how testing is a step. Normally I'd automate with Hudson, but I am wondering if there is something more specific to the platform.
Overall, I'd love to see a solution that provides a decent workflow on both windows and *nix without a heavy admin burden. I am pretty sure this is the holy grail of project management, so anything that puts me on that path is awesome.
In a project I work on, we use Visual Studio 2010, MonoDevelop/XBuild, Git, and monodoc. Project files created by Visual Studio 2010 can easily be read by MonoDevelop and XBuild. Also, Git is an excellent VCS for distributed development (I especially like its branching). Monodoc, with some tweaking of command line parameters, can generate documentation from XML comments in code.
You can use any dvcs you'd like with it. MonoDevelop (at least in the trunk, not sure if it has been released yet) as Git support built in. There are some plugins for Visual Studio that give you Git too.
Either way though, you don't need your source control to be integrated within the IDE, infact I prefer it not to be and use Git from TortoiseGit if I'm in windows, or from the command line on OS X (although I'm looking at Gitti for the OS X side).
For build, I would suggest TeamCity, since it supports up to three remote agents allowing you to build on Windows/Linux/Mac with the free version.
For build I'd use NAnt, although xbuild under mono works with solution files so that might be easier rather than maintaining two build scripts. I like NAnt for CI simply because I find it easier to break apart into build, test, cover, package, deploy etc.
I've found that the combination of MonoDevelop, Git, TeamCity and NAnt gives you a few nice cross-platform development setup.
I suggest you try to use one IDE mainly. Most Mono IDEs support Visual Studio formats I guess. At least SharpDeveblop does.
http://mono-tools.com seems the correct way to develop for .NET and Mono only in Windows (not free). I think this is the best option if I ever take developing for mono seriously ina commercial environment, but not 1005 sure.
http://sharpdevelop.com looks promising too, but still fells like the poor man option.
http://monodevelop.com/ is the way to go for developing for Mono in Linux.
For DVCS you can always use Tortoise stuff and be IDE independent. git works great in Linux and TortoiseGit on Windows is very nice. However, it terms of fame, SVN (not DVCS of course) is still dominant, especially it's client can connect to TFS via bridge. Mercurial and Git are starting to take place in C# community though.
CruiseControl.Net is a pretty good build / continuous integration system. It can integrate a load of applications into the build process; we use NAnt for builds, NUnit unit tests and FXCop for code analysis.
Cake (C# Make) is an open source build automation system with a C# based domain specific language that can do things like compiling code, copy files/folders, running unit tests, compress files and build NuGet packages. It has tons of other built-in functionality and can easily be extended with custom code. It's available for Windows, Linux and OS X and can be used with several continuous integration systems such as AppVeyor, TeamCity, TFS, VSTS or Jenkins.
Time to ask the pros, since I can't find a good answer anywhere else and I'm venturing into a side of the world that I'm just learning.
I'm in a primarily open source shop that has recently begun taking in a lot of internal tools and partners that are .Net based. That got me to thinking that I may be able to utilize the best of both worlds by leveraging C#/mono in certain spaces. On a small scale I've been very successful and it's working great. However, pressing 'Build' and scp'ing the exe into place isn't going to scale well.
I'd like to step it up a bit and get some more resources behind it, so here's my question; what are the baseline resources I need to establish a good dev/testing/staging environment.
I don't need uber-detailed information and I'm willing to consider both commercial and open source solutions, I guess I'm more looking for good advice on resources. 99% of the items developed on either side of the OS line will be services.
What sort of Unit/Regression testing tools are recommended, is NUnit the standard?
What sort of deployment mechanisms are recommended for service level software?
What, if any, additional tools have you found useful or indispensable during your development/design work?
The first 2 items are of interest since they are the last things I'm lacking before I have workable, repeatable development and deployment process.
You might want to look into http://go-mono.com/monovs/
It will alow you to debug on Linux from within Visual Studio.
The unit testing framework in Visual Studio is rather good as well,
but if you use the standard or free version of Visual Studio, NUnit is a good option as well
(And there is the option of Visual Studio integration)
Aside from that I've come quite attached to Refactor Pro (and other products by that company)
http://www.devexpress.com/Products/Visual_Studio_Add-in/Refactoring/
As for scp'ing the files to your linux/mac machines, it might be easier to
configure MSBuild to do that for you automatically.
This might help: http://bartdesmet.net/blogs/bart/archive/2006/04/13/3896.aspx
Many more msbuild tasks can be found here: http://msbuildcontrib.codeplex.com/
I hope this helps.
For build and deployment you might give NAnt a try. It'll handle your builds, and has tasks for running your tests, doing clean SVN checkouts, zipping up releases, that kind of thing. You can embed C# too. Grab the nightlies rather than the releases and don't worry too much about the lack of recent activity. Also the nant-contrib project is full of additional goodies.
Another option is to try msbuild (I believe there's a Mono equivalent, although I'm not sure to what degree). Truth be told there's not a lot of difference between the two.
I have built effective build/test/deploy infrastructure with the following:
NUnit
CruiseControl.NET (or CruiseControl)
NAnt (and NAnt Contrib)
or MSBuild (depends on your environment)
We also use subversion to manage both source control, as well as deployment (for things like CMS and website systems)
A few of the build tools we use are:
Simian
NCover
NDepend
Powershell (for both build automation as well as deploy automation and machine control)
Of course any of these tools can be substituted for other tools you like (perl, python, ruby, Ant, etc).
This is roughly how I've set up my environment at work:
I use NUnit as a unit-testing platform
I use TestDriven.NET as a plugin to easily run my unittests from within my IDE
I've set up a separate computer, which runs CruiseControl.NET
This CruiseControl.NET computer checks my source-repository on regular times. When it sees that something has changed, it gets the latest version from the source-repository and builds it. It also performs unit-tests, and runs fx-cop over the targets.
Next to that, i've configured it so that it performs a nightly build as well. This does roughly the same:
When something has changed during the day:
remove every file that exists locally
get the latest version from the source repository
build it
run unittests
run fxcop
create documentation using sandcastle helpfile builder
when the build was successfull, copy the build output to a separate folder which is named 'build-yyyymmdd'.
I've setup my source-repository so that I can keep different versions (branches) from my project.
In short, my source-repository looks like this:
I have a folder which is called
'devtrunk', which contains the actual
codebase. (On which I'm actively
developping)
I have a folder calles 'releases'.
Every time I release a new version, I
make a branch of the trunk, and I put
this branch in a new folder under
'releases'. This allows me to fix
bugs in a version that has been
released, without disturbing my
actual work on the trunk.
Since I'm working on the Windows platform, I use MSBuild to create my build-scripts (which are executed by Cruisecontrol), but, you can use NAnt instead. (Which I've used as well).
I want to create an ASP.NET build server for the first time since I've never used it.
Does anyone have a tutorial or resource on how to make an ASP.NET build server?
Or can anyone tell me how it's done?
If by "create" you mean "setup a build server" then I suggest you take a look at TeamCity from JetBrains.
TeamCity is a multi purpose build server and can be used to build ASP.NET projects as well. You can get up and running for free, and its very easy to set up, compared to CruiseControl.Net.
Take a look at MSBuild to see how to do specific ASP.NET build stuff.
MSBuild reference
How to use MSBuild to do ASP.NET compilation (video)
You might need something from the msbuildtasks open source task collection
If you really want to create your own build server from scratch (but why?), I can't help you.
You could make a build server using CruiseControl.NET which can build your project.
CruiseControl.Net Tutorial – Part 1
CruiseControl.Net Tutorial – Part 2
There is no ASP.NET build server as such.
Do you have a one-click build script? If not, you should create that first. Once you are able to run a single command and get a complete build, then it is easy to set up CruiseControl or some other build server.
Given the strength of the build servers out there it's really not sensible to spend any time developing your own.
You will, however, need at the minimum
a one-click build script
a source code repository (e.g. Subversion, TFS, or even [shudder] SourceSafe)
a server to use as a build box (I use a virtual image)
You may also find a one-click deployment script written using something like Powershell to be useful, too.
Note that a very effective alternative to CruiseControl.NET and TeamCity is Hudson. Although it's written in Java it's ridiculously simple to get going with a J2EE server like Tomcat.
The key strength of Hudson is the range the plug-ins, which allow you to monitor most version control systems and then not just build (through MSBuild or even the command line) but also run unit tests, acceptance tests, and so on.
You might look at Web Deployment Projects -- they allow you to build your site and merge all DLLs into a single file, for a fully pre-compiled site. You can use it with MSBuild.
An option on the automation side is Team Foundation Server's (TFS) automated builds. TFS also includes source control, bug tracking and many other features you may or may not need.