I'm planning to setup my own build server. I'm primary building C#, C/C++ and Java projects. I would also like my build server to run some external programs/scripts such as my unit tests, code static analysis and doxygen.
Suggestions?
Use Hudson Continuous-Integration software.
We're using JetBrains TeamCity. It's easy to configure, user friendly, has convenient plug-ins for notifications on build events, you can install multiple build workers, define any build engine (.net, java...), it can output artifacts, it can trigger automatically on check-in, it can execute any custom build script etc, etc... and most of all - it's free (for up to 20 configurations).
We've looked far and wide, and we found this to be the best...
Hardware: Discs. Quite some, or a decent SSD. A lot of the stuff you do will be disc based from the compiler side. Not talking about the get latest version (alone), but for example a c++ compiler generates QUITE a number of interim files in the build process. A decent fast subsystem can make a recognizable difference. Especially fi this is not for you but for some colleagues as well, sotit may run a lot concurrently.
Well, enough RAM and a modern multi core CPU go without saying.
I've used Trac and Bitten, which worked quite well. I used it for C# and Python projects.
I have it building, creating docs and running unit tests. Currently I'm investigating running dotCover for test coverage, which shouldn't be too difficult, because bitten basically allows you to call any shell command you need.
Actually, I usually run the build system on an old (not-so-fast) system - it doesn't need to be very quick for me. I like to have developers behind the fast machines ;-)
Related
We've got a quite complex deployment scenario and want to make use of continuous deployment. Currently we've got a huge MSBuild script for everything, however, MSBuild is ok for building but not really suitable for deploying.
We'd love it if there would be some kind of C# project where we could write the deploy code directly with C#. Is there some C# scripting language which is suitable especially for deploying applications?
While it's not a C# project, you can use my company's product BuildMaster to handle deployments. It's designed to solve some of the problems you're already having, and some you probably don't realize you have (configuration file deployments, database schema updates, process automation, approvals, etc.)
However, if all you want is to write C# scripts for deployment, there's a tool called con-dep which looks like what you're describing.
Well, with Roslyn now I suppose that you can technically now use C# as a scripting language. I don't know if it would be terrible appropriate to do so...
Depending on your deployment solutions you might want to look into the NAntBuilder IDE. We used this for continuous ddeployment together with SVN server. If you have TFS why don't you just look into the details and many possibilities of Build Process templates?
You can use the .NET integrated C# compiler.
The advantage is that you can use the same DLLs/APIs in a C# 'script' as you do in your own software.
I use it in our production software. Our production engineers are able to write some small programs for special stuff.
See this answer for details.
You may want to look into using a tool that's specifically designed for handling deployments. If you're using Team Foundation Server, Team Build + InRelease provides a well-supported, well-documented way to handle your builds and deployments. Now that Microsoft owns InRelease, it'll be part of Team Foundation Server pretty soon.
If not, you can always write PowerShell scripts to handle your deployments. PowerShell isn't C#, but it's built on top of the .NET framework (so all the framework methods you're familiar with are still available), and the learning curve isn't very steep.
Please recommend a good continuous integration that would build and integrate with the .net stack and the visual c++ as well.
Some recommendations I have got are
Jenkins
CruiseControl
Teamcity
Because of the polyglot nature of the project, which continuous integration solution would you recommend?
I have used all three over several years. Some of the answers below state that most of the work will be producing your own build scripts. This has been true in my experience as well. We use a combination of MSBuild and Powershell scripts for our build process, which can be run under just about any CI tool, so picking one comes down to what you're looking for in terms of customization, integration with other systems, performance, and ease of use.
Short answer:
I recommend Jenkins. So far it seems to be the best combination of the above qualities. It has a ton of plugins, some localization and is actively developed by the OSS community.
Long answer:
I started with Cruise Control .Net. It was easily configurable with a text file and I found it highly reliable. However, we moved away from it because Thoughtworks was moving toward a paid product (Cruise, now Go) and future development was in question. A new team has since forked the project but there is little word about future development since.
We moved to TeamCity, which is free and has a great ajax-y UI. It is easy to setup and get going and has a lot of features for distributed builds. We quit using TeamCity for several reasons. The server does a ton of stuff and it was a bit overkill for our basic needs. Even so, it was not very customizable (see Time Zones and notification contents) and we often found the administration UI confusing. That was all still okay, but we also had steadily worsening performance problems. We started with a standard HSSQLDB out-of-the-box, moved our installation to SQL server when we started experiencing degraded performance, then had to quit using the server at all as performance continued to degrade over time. I'm not sure what the culprit was but I couldn't find any cleanup to do that would explain the constantly worsening performance as the Tomcat web server fought with SQL Server for resources, even when there were no active builds running. I am sure it's my fault and I was missing some crucial setting or needed to feed the server more memory, but this is a shared utility box, we did not have these issues with CC.Net, and most of all, I am not a Java/Tomcat guy and don't have a lot of extra time to keep fighting with these issues.
We've moved to Jenkins now. It seems to be working fine so far but we've only been with it a short while. It was easy to set up, does not seem to be taking nearly as many resources as TeamCity and has a ridiculous number of plugins. The only downside so far is like many OSS products, it does not seem to have the best documentation and it does so much that I may be tweaking knobs for a while to get it set up the way we want.
Between CruiseControl and TeamCity, TeamCity is faster and easier to set up, but you may need to check on licensing for it. I can't speak to Jenkins, never having used it.
Jenkins has the big advantage of being very extensible (currently over 400 plugins), which allows you to combine it with a huge number of other tools. So it gives you complete freedom in your other tool choices. I recently read that this is one problem of TeamCity, that you get locked in using the whole stack of tools (e.g. using SVN or Git as version control system will not be possible).
I am using Jenkins myself for our projects which has both Java and C++ code, and I am very happy with the tool. We had CruiseControl before, and have not once regretted the switch.
I have tried both Cruise Control and Jenkins, and Jenkins impressed me with very fast and user-friendly set up.
The three you list are all sensible choices, and the main problem will be producing the build script(s) needed to do produce the build artifact(s). If you manage to make them do everything needed, changing CI system shouldn't be a big issue.
After implementing all three in different shops, I'd chose all of the above. Pick one.
I know that there are a number of tools for analysing .NET code and calculating the coverage, plus identifying classes/methods/properties etc that are never going to be hit.
However, I am trying to clean-up a legacy application that I am certain contains an amount of unused code - however a lot of code is accessed via some arbitrary and complex reflection tecniques that will disguise the intent to the compiler - thererfore any coverage tool that only analyses the compiled code is unlikely to generate any reliable reports on code useage within this application.
Are there any tools that work rather like profilers, whereby they listen to a running application and log what classes/methods/properties are actually hit and generate the coverage based on this data.
I hope Ive made everything clear - thanks in anticipation
we are using ncover, and it works really nicely: http://www.ncover.com/.
But it's commerical, or you use the trial version, if you just need it once.
You can use the VS2010 Code Coverage tools - they do use Instrumentation (which means reflection won't trick it). Syed Aslam Basha has a post on it in his MSDN blog on how to enable it for manual testing (which it sounds like you will need to do).
Just remember you will need to click every feature etc. while its running; or just think twice before deleting code - but it should give you a good starting point.
Two open source versions currently exist that support .NET2 and .NET4 runtimes
PartCover - is the oldest but only supports 32 bit (supported by teamcity)
and
OpenCover - is the latest, it again supports .NET2 and .NET4 but also supports 64 bit, it also has recently added branch coverage (though reporting is up to the user)
Both OpenCover and PartCover can be used with TypeMock and Moles should you need to.
Commercial versions include (but no limited to)
NCover - the most well known
dotcover - integrates well with team city when unit testing
Clover.NET can do this. But it is commercial and I didn't manage to find a link to the .NET version (I've used it several year ago).
Can't think of a tool other than a profiler, but how about using logging?
Use static analysis to discover static calls, and put logging into the reflective invocations to show what is being called. After a few runs you'll know what is being run.
After all the reflective invocation will know what's doing.
Speaking about compiled languages (c# in my case) I think that problem would always remain, no matter how performant your develop machine is. Build time could be more or less depending on concrete environment, but often it's enough to make your attention wanna move from your task to something else like stackoverflow, youtube, twitter etc. and it's just very annoying.
I'm happy for java developers because of Java's dynamic class loading, but what can .net (and others) developers do to make build process less painful and obtrusive?
We use multiple build configurations to trade-off between speed and a comprehensive build.
A full build does time-consuming things like FX cop analysis, ASP.NET compilation, all unit test projects, Entity Framework view pre-generation, etc.
A "fast build" typically takes just a few seconds and those the bare minimum needed to get the project running.
Developers switch between the full build and the fast build throughout their workflow, as needed.
Don't the class files have to be build as well? Wouldn't that just put the workload to runtime in contrast to compile time? That's not really a difference isn't it? The bigger software grows, naturally, the longer it takes to build it, depending on the machine and not on the language or framework - this is the tradeoff for things like strong typing, interpreted byte code (or binary code depending on the language/compiler) instead of interpreted source code at each run (as you have with php and python etc). I don't think java improves things much, there will a timeframe you have to build your application in.
I think in comparision to C and C++ both C# and java have improved immensely on the account of compile time.
Just use the time for slacking off:
source
Some things to try:
Defragment the drive containing your source code
Exclude your source code folders from the virus scanner
Exclude your source code folders from the Windows Search indexer
Disable any Visual Studio extensions that you are not using
The remark in your question about one's attention wandering off-task reminded me of this Joel on Software post.
So investing in solid-state disks (since I'm assuming you're talking about the build process on a dev box while you're developing and debugging) could help.
Besides, making your computer faster in general can't hurt, right? :)
In addition to many of the other suggestions to get a faster machine, remove unnecessary projects from your solution, etc, consider Visual Studio 2010 + a multicore machine. VS2010 can take advantage of all of your cores when doing a build. Check out this thread for more on how to set that up.
Are you doing a rebuild all every time or do you have everything in the same assembly? I'm working with quite large projects and my build time isn't that high. I got several assemblies and I only modify a few each time I do changes to the project.
If you find yourself modifying assemblies all over the place, you might try to refactor your code structure. Or maybe you haven't taken yourself time to do unit tests? They do not only help you with the testing, but to get better code structure (hard to test apps with lousy design).
Another alternative is to use tools that speed up builds, for instance: http://www.xoreax.com/
I've worked on some very large C# projects and have rarely seen Debug build times exceed 2 minutes.
What generally sucks time are things like static analysis (e.g. fxcop), unit tests, code signing (if using a code sign service), etc. The easiest way to keep these under control is to either limit them to Release builds or to have a separate build definition for 'Full Build' and exclude these steps from your Debug and Release builds.
If these aren't your problems, look to your computer performance as others have said. Fragmentation, slow build disks, anti-virus, etc.
What is the best continuous integration setup for a Devleopment department that codes in multiple environments?
At my company we write some code in C# and some in Java, I've previously used CC.Net but I've never done CInt with Java.
I'm aware of Continuum and was recently told about Hudson, but I've never used either.
Would it be better to use two CInt services one for each platform or to use a single one for both?
Why don't you try Team City from JetBrains? It is both for Java and C# and Professional version is free up to 20 user accounts and 3 build agents.
You could simply use the Java version of CruiseControl and have two setups.
As you already know how to use CC.Net and CC.NET can run any build task that outputs XML. Why not just use CC.NET with ant for your java code as well as your C# code.
Or do you need to build on none Windows machine? CC.NET may work with mono, I have not checked.
Remember that any continuous integration setup that compiles all your code and run your unit tests give you great benefits. On most projects having the perfect setup only give a smaller improvement over having a continuous integration setup that works. So I would just pick something you are happy with and start using it now.
Imho, its almost alway better to use one CI for all platforms you plan to deploy to - easier to sort out problems that way.
shameless plug: try Bamboo, the CI server from Atlassian. Its one click setup, built-in support for Ant and Maven and works on all platforms with JVM. It can also do distributed builds on different platforms.
It also integrates with Atlassian Jira Issues Tracker and Fisheye Code Repository Browser if you have those products.
Hudson. I've used it for both .NET and Java projects and it works well to have both platforms using the same continuous integration server.
Note this assumes you want to build the same code on multiple platforms. Hardware has gotten cheaper so use virtual machines or multiple physical servers I'd go with virtual machines and just buy one powerful server to run them on but if you have a lot of old mid range hardware that may be a cheaper option. Set up a main source control repository on one server, and set up servers with the client operating systems you want to build for. For example have a svn server containing your operating system of choice, a Linux server to do Linux builds and a Windows server to do Windows builds. Then just install what ever continuous integration software works best for the given code base and operating system.