My team works on a Medium sized product which takes about 2 hours to build on a single dual-core machine.
As part of an effort to improve productivity I am looking for alternatives to improve our build process.
Currently we build C++ code and .NET code using VS2005 solutions, we also have some legacy code built using makefiles and we pack the products using installshield. We also have unit tests written in UnitTest++, Nunit, CPPUnit and some tests that we wrote ourselves without any testing framework. Everything is coordinated by a set of Perl scripts that we wrote.
I am looking for a product, or a suite of products, or a bunch of non-related products that will allow me to do the following:
Improve building time. I tried Incredibuild for parallelizing the build with some success. I will be happy to find more alternatives (cheaper ones???)
Improve the build process definition. I need something to replace our complicated perl scripts with something that will allow me to define the build process easily.
Improve our ability to discover problems in the build (maybe a web interface for looking at build outputs, highlight compilation errors, gather statistics on build times and build failures etc.
Any other nice features that can help us improve our build management.
Consider NAnt: http://nant.sourceforge.net/, CruiseControl: http://en.wikipedia.org/wiki/CruiseControl, and a faster build system. there are some .NET related links at: http://confluence.public.thoughtworks.org/dashboard.action
Edit: Gradle is probably the best choice now.
Try FinalBuilder it's very compreshesnsive build managment tool
Sakin,
I think you may be looking for two different tools - although occassionally you will find them packaged together.
One tool would be the build management system that schedules the builds, shows you the outputs, gathers statistics, etc. Tools like FinalBuilder, CruiseControl and AnthillPro play in that space.
The other tool would be the one that tears apart your build into parallelizeable pieces and speeds the build. Incredibuild is pretty good at what they do in that respect and certainly cheaper than some alternatives. There are free options built into some of the open source tools like gmake, but my understanding is that you'd need to do some pretty serious work to get that to work with solution files.
You should be able to mix and match at will. We have customers using Anthill with Incredibuild, gmake, and a number of other build speeding tools.
I used Automated QA's Automated Build Studio a few years ago at a previous job and it was pretty good and fairly cheap. I haven't used it since then, so I'm just recommending you look at it.
If you have an MSDN subscription you should look at TFS. TFS Build is pretty robust and is integrated into Visual Studio and works hand in hand with Team System/TFS Source Control (you didn't say what source control you're using).
We have a process similar to yours, although it's not a VS project. Up until recently we used perl scripts and tinderbox to build and track the status of the builds and unit tests. We've recently made the jump over to Hudson and it seems to work great.
https://hudson.dev.java.net/
Don't be put off by the java label, our projects are c/c++ and they work fine. Hudson can execute shell commands, so we can build our projects (makefiles) and run our unit tests fine. Right now we have it set on a timed build, which when it finishes (if successfully) kicks all our unit tests off in parallel.
It's a great system and worth checking out if it's what you're looking for. It logs console ouput and has tons of great addons (logs and charts warning counts, disk space used size, build on CM change) and a nice web-interface for the team to watch.
Oh yea it's free..
I wouldnt advise HUDSON .. there is unnecessary too much bragging about it ..
hudson is limited tools other than it can do much more and have a better bui8lt core architecture
The suggestion to go with anthillpro and incredibuild is a good one !!
With regard to the "Hudson has extensive plugins .. blah blah blah " its really is a sham ..
What ever hudson CANNOT achieve it is core architecture it does so as a plugin
Surprisingly if i have to mask a passsword or any credential i cannot do it without the "password masking" plugin ..
Ideally if a system is "enterprise scalable" this masking should be built into it core
This just one example .. i have a clear analysis for these tools but cannot upload a document here
Moving to the other side
Hudson "looks and feels" "nice & cute" and is relatively light weight
Related
Some years ago I´ve tried to work with BDD and some tools of Acceptance tests, like Selenium/Web-driver, Fitnesse and JBehave.
I´d like to back to work with that in my current project, so I would like to know what the community is using of tools to perform that!
My project is based on Java.
Acceptance tests tools ?
BDD tools?
Should I consider a scripting language ?
The most successful teams are using conversations and not worrying too much about the tools!
Having said that, here are a few Java BDD tools that are in use in the community:
JBehave* (still)
Cucumber for the JVM (I don't think it's been as maven-ized as JBehave)
Fitnesse (though I recommend putting "Slim" behind it instead of "Fit")
Custom DSLs (it's not that hard).
Selenium is still the automation tool of choice for Java and the web.
*I helped write JBehave. One reason we got into it in the first place was because the acceptance tests we saw using scripts were such an astonishing mess. Meh. Also, you can't collaborate with the business or have conversations about scripts. I strongly recommend having conversations first**, then worrying about the tools!
** If you're working on your own, buy a rubber duck.
I strongly recommend spockframework + Geb. You need groovy support though. We have lot of tests running as part of CI every night. The reports are in junit format (being enhanced to be used by business users soon) and hence can be published to servers like Hudson or Sonar.
You know, the next "big" and "enterprisey" thing from Microsoft.
Is it just me, or is it really hardly for humans? Main highlights are (IMO):
Absolutely cryptic syntax (-skip:objectName=filePath,absolutePath=App_Offline.* just for skipping App_Offline.html)
Manifest as an after thought
Lack of thorough documentation
Not a word about extensibility (except for several blog posts out there). Moreover, all these extensions developed in great pains have to be registered in GAC and registry
Waaay too low-level (metadata/metakey; all this IIS jazz)
No integration with MSBuild
Granted, MSDeploy and MSDeployAgent are quite powerful, but do they really need to be that complex for relatively simple tasks?
I too share your frustrations over the lack of documentation and the apparent low-level nature of this tool.
However what MS has done is finally create a free tool with which you can actually script whole server deployments, including parameterising addresses, configurations etc. This is unfortunately a very complicated thing to do - given how many bits of configuration actually go into a web server - and this is probably the best way to do it all.
What we need now is a really good GUI that can help build up these packages, and scripts etc. The GUI that is embedded within IIS is good - but again, short on explanation - so hopefully soon that'll be addressed.
On the functional side, I'm using at the moment to deploy a site from dev -> staging -> live with parameters to change bound IP addresses etc. I was deeply frustrated that it took me a few days to get it all working - however now I have it, I can remove a lot of the possibly of human error at the IT Support side - who are responsible for our deployments. I now only have the configuration of my master staging server to worry about - and can be sure that all the servers in the web farm will be kept in sync whenever I deploy.
As Sayed mentions, as well, there are MSBuild tasks in 2010 (the Website Deployment feature is now implemented using msdeploy) to work with this - which also brings the possibility of a true Continuous Integration environment to VSTeamSystem - having a team build that can actually perform a full web deployment as its last step is very exciting (and scary, granted!).
Actually there are MSBuild tasks for MSDeploy. They will be shipped with .NET 4/Visual Studio 2010.
Although a bit rough around the edges, I've come to like MSDeploy quite a bit. Using it to sync web servers in a farm is very useful as it is efficient (only copies changes) and takes care of actual IIS settings in addition to content files. It seems like MSDeploy is a building block for various scenarios and uses. Also, as previously mentioned, there is a MSBuild task for MSDeploy in .NET 4. I've taken advantage of this MSBuild task to make deployment of my web applications from TeamCity trivially easy. I've blogged here it here:
Web Deploy (MS Deploy) from TeamCity - http://www.geekytidbits.com/web-deploy-ms-deploy-from-teamcity/
I have recently started implementing a deployment pipeline and I found below links quite useful:
MSBuild commands I used for Continuous Integration:
http://www.troyhunt.com/2010/11/you-deploying-it-wrong-teamcity_24.html
WebDeploy sync commands, I used for deployment packages to production server:
http://sedodream.com/2012/08/20/WebDeployMSDeployHowToSyncAFolder.aspx
Also I used these references:
Video about MSBuild on dnrtv.com
Microsoft Press book called "Inside the Microsoft® Build Engine: Using MSBuild and Team Foundation Build" which you can buy PDF version from Oreilly
Finally, "Continuous Delivery" book, gave me good ideas about deployment pipe line, although the book is not focusing on MSDeploy, but it is really worth reading.
The statement of documentation is typical of a MSFT 1.0 product, unfortunately MSDN no longer have dedicated Developer Technology Engineers to fill the gaps --- instead, there is a blind faith that the web will provide it.
I am actually considering dusting off my writing skills and write a short ebook on it since there is likely a market for it....
Msdeploy definitely has a touch of the PowerShell to it: power over simplicity rather than worse is better.
There is no Windows alternative to it, however you can hybridize some of its powers to make automated deployments. For example:
Compile your solution with Team City and msbuild
Use msdeploy to transform your site and web.configs on the build server
Manually FTP a ZIP file of your site (it doesn't support FTP)
Alternatively, use its remote deploy capabilities. This requires port 8172 open, lots of security changes and as far as I'm aware no concessions for load balancing
Use msdeploy on the live site to sync changes
As a tool it's clearly aimed at service providers as it's an enormous Swiss army knife. You can do all kinds of things to IIS with it, which for the most part are over kill for small businesses. I've no experience of large scale IIS setups so maybe that's where it shines.
95% of my time I program ASP.NET (MVC) web sites.
Should I care about MSBuild?
We use MSBuild with CruiseControl.Net to manage the builds of most of our big ASP.NET projects. For every commit of one member of the team, a build is launched. It helps us detect
quickely incompatibilities before moving a feature to "staging" or "production".
I think it is really usefull when working with a team on the same ASP.NET project or if you are working alone on a big project.
That depends on your development environment.
If you have other folks that do deployment of your systems, and they take care of the build and deployment environment, then MSBuild probably won't be necessary for your work.
On the other hand, if you need to configure the build script to understand special situations that your code comes up with, then you will definitely need to understand MSBuild scripts.
Even for a one-man shop, it's a useful tool to know, especially if you are configuring a continuous integration server like Hudson.
No. Until you have to.
Its not absolutely necessary to know MS Build, but it is useful to know.
It might not be needed for all kind of projects, but it is extremely useful when you are working on a huge code base with automated custom build solution/ nightly build/developer builds so on and so forth.
It's unlikely, unless you choose to use it, or you start to make use of Team Foundation Server's Team Build.
Your development processes need to get to a certain complexity before automated builds really deliver their true value and/or if you find need for automatic deployment (including database changes if applicable).
The coming Visual Studio 2010 is going to make it far easier to use, but for now it retains a fairly steep learning curve which you can avoid by using alternatives, or commercial products (e.g. Visual Build Pro, Final Builder etc).
The nice thing is that it is part of the .Net framework, so it's already available as long as you have the framework installed (which it probably is).
So, in short, not really. It's something very useful and powerful though, setting up deployments using MSBuild can be very, very useful.
What should a developer know about MsBuild?
Every developer should know it exists and it's basic capabilities. If know it exists you won't duplicate its features and will know what it can do for you, when you need it.
Minimum:
As an exercise, build your project through the command line: msbuild myproj.sln
Know the role of continuous integration
A little more than minimum:
Hack your csproj (or vbproj) with a message task, so it outputs something during clean.
All done. When you need to know more, you'll figure it out.
I'm starting a new project using Flex3 for a reasonably intricate UI getting its data from a collection of RESTful web services. I wondering what experiences others have had in structuring a moderately complex Flex project. The issues I'm thinking about include:
I want to use our FlexBuilder licenses for visual editing of layouts and debugging code on Eclipse
automated build script so that we can use a CI server
testing strategies, particularly automatable unit tests
cross-platform Linux and Windows development environments (yes, I know the Linux version of FlexBuilder doesn't do visual editing, but everything else should ideally run cross-platform)
dependency management for at least the Java code (are there library dependency managers for Flex?)
I've just burned a day trying and failing to get a maven2/flex/jetty build setup working smoothly (based on Jeff Maury's tutorial). I'm not dead-against using Maven as we go forwards, but I'm sure there must be a less painful route. The main issue I had (other than maven documentation being patchy) is that maven's "single artifact per build" rule means that you have to jump through a lot of hoops with a complex build, and I'm not enough of a maven initiate not to trip over the hoops and fall on my face!
Would Ant and Ivy be a better option than maven2? What other choices are there?
I don't know Flex development but I know CI so I'll comment on that aspect.
I work on CruiseControl, so that's what I use (when not being paid to setup something else). And there are blog entries that describe setting up Flex projects under CC for both Windows and Linux. CC has been around for a long time so there is a large community of users and lots of 3rd party tools that work with it.
But other people are likely to recommend Hudson and it would be hard to argue against them. Hudson is very easy to get up and running and has a nice web based UI. This project is very active, has lots of fans and lots of buzz and has matured very rapidly. I don't have anything bad to say about it. This blog entry describes running acceptance tests under Hudson.
I don't know enough about Maven to offer advice there but I'm working with Ivy at a client right now and I really like it. We've got a combination of Java and C++ code and we're able to get Ivy to do what we need.
Well we are using maven. With some help of a lot of different web sties I have an enterprise application being built using maven.
This article via adobe has really help a lot.
http://www.adobe.com/devnet/flex/articles/fullstack_pt1.html
http://www.adobe.com/devnet/flex/articles/fullstack_pt2.html
http://www.adobe.com/devnet/flex/articles/fullstack_pt3.html
You really need a common configuration project that will be shared between both flex and java, and possibly your c++ code. This article explains how to set that all up.
Down side, if you are not knowledgeable with maven there is a slight learning curve.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
As recently as several years ago, the developers actually made the builds that went to clients. This was obviously a disaster for reasons too numerous to list.
Then when we started to learn the errors of our ways, we looked for a way to auto-build the entire application on a dedicated build machine. The culture at that time was very averse to bringing in outside tools, so we built our own autobuild system by writing a VB app.
This worked fine for a while, until the project's structure started to change, new projects were added, and we needed to build the application in different ways. Then then weaknesses of our hand-rolled autobuilder became apparent and, over time, increasingly onerous. This disease has progressed now to the point where QA (who owns our build process) can't even maintain the autobuilder because it requires more and more programming skill. Every time we add a project or change something in an existing project, it consumes more developer time just to make it work. There have been days when we were unable to produce a build because the system was broken.
I'm now in a position where I can change this process, and I'm looking to scrap the entire system and put something else in it's place. My goals are:
Have an autobuild system that can run with zero human interaction at a specific time every day. It should be able to gather all the source code, compile all the apps, create the setups, put the finished products on a network share, and possibly trigger the automated testing system to kick in (we use QTP).
The autobuild system should be flexible enough to easily adapt to changes in the project without rrequiring a major overhaul.
It should be simple enough so that QA can own the system and not require developer resources to make changes to how builds are made.
What are your experiences? Can you recommend an autobuild system? Should I have different goals?
I'm currently using CruiseControl integrated with Ant to control project builds. This allows flexibility of build schedules and means you can automate the entire build process fairly easily using Ant scripts. Also, during defect fixing periods you can have CruiseControl set up to watch for source control submissions instead of time periods and build when these occur. This allows developers very quick feedback on defect fixes.
I use FinalBuilder and FinalBuilder Server for nightly builds. It's a bit buggy at times, but if you think it through it's quite easy to create extensible projects that can build X project type, build it's database from change scripts and deploy it to a testing server.
It can also handle all kinds of wierd and wonderful things like ZIPing a nightly build and uploading it to an FTP or creating ISO images automatically.
Definitely look into MSBuild if you're on the Microsoft stack.
Joel is always going on and on about how great FinalBuilder is, so that might be worth a look as well.
We just migrated from a hand-rolled set of Perl scripts to a Buildbot setup. I found it because that's what Google's using for Chrome.
You can do nightlies, or it can integrate with source control to do an isolated test build whenever anybody does a checkin, or a variety of other things. It's also parallel; you can have more than one machine in the build farm, either for specialized duties or just to handle more load.
The entire system is written in Python, so it's platform-agnostic, which is important if you need to do builds on more than one platform. It can do anything you can do from the command line; we have it calling MSBuild for user-mode components, a DDK build for kernel-mode pieces, and running products for unit test builds.
Out of the box it supports most OSS source control tools, but if you're using TFS or something else you may need to modify the package that you install on the slave machines.
I think you are on the right track here.
Whoever looks after your automated build process needs to have a fundamental understanding of how your solution fits together. This doesn't necessarily mean knowing how to write code or architect solutions, but they will require a solid understanding of how the solution compiles, packages itself etc.
You might need to share responsibility for builds between people or teams to accomplish this. I'd say that a daily build is a "team responsibility".
I'd look at establishing a baseline build configuration which can be extended for "special use" builds (besides just building a release version), e.g. internationalized releases, fxCop/Quality Tools config, build + run Unit Tests, continuous integration builds, a build config to run on developer workstations, etc.
Instead, I'd aim to achieve the following:
Automatic versioning, signing etc
Ability to produce verbose output (logging) to help debug build breaks
On that point - it should handle errors properly, capture as much information and log it properly
Consistency - It should work the same way each time to produce repeatable outcomes
Run in a clean, limited access environment
Well commented/documented so that it can be understood by new staff, etc.
Option to generate release notes, compile metrics, produce reports (if this option is available)
Ability to deploy to multiple environments
Support different ways to obtain source code from source control, e.g. by changeset, label, date, etc
As for tool recommendations, I've used FinalBuilder, Visual Build Pro, MSBuild/Team Build, nAnt, CruiseControl and CIFactory plus and good old fashioned batch files.
Each has its pros and cons, I'm not going to make a recommendation except to say that the products with decent UI support were a little bit easier to work with, but at times were far less powerful. If you're working with VIsual Studio, MSBuild is very powerful, but has a somewhat steep learning curve.
As of tools delivered with MS Visual Studio you might want to use MSBuild. Additional Community toolsets for MSBuild will even give you the possibility to checkout code from Subversion and zip output.
We're using it successfully in our company. Projects consists of several solutions with 100+ subprojects. Works like a charm.
Visual Build Pro is nice, if your build machines are Windows. I think this would fill the requirement you have about QA owning the system. But don't get me wrong, it's pretty powerful.
We use CruiseControl.NET and UppercuT (which uses NAnt) to do this. UppercuT uses conventions for building so it makes it really easy for someone to get started by answering three questions (What is the solution named? What is the path to source control? What is your company's name?) and you are building.
http://code.google.com/p/uppercut/
Some good explanations here: UppercuT
We use the Hudson buildbot for for big Java web app building from ant build scripts. Hudson is pretty sweet for our purposes. It has a master/slave setup so builds can be done concurrently (on a timer or on-demand). Slave nodes can be any OS/hardware combo provided it has the needed build tools already on it and is on the network (and won't crash every 10 min).
Full web-based interface including live console output, change logs, artifacts from the build are available across the network including previous builds (if successful). Awesomesauce!