I've been wondering how you go about doing CI-style testing when you're dealing with physical devices.
I imagine you have a suite of tests, and a pool of devices against which they can be run.
Additionally:
Some tests may require specific device models.
Some tests may require the use of more than one device.
What CI servers have support for this?
I'm still interested in those which have partial support, either natively or through plugins, as I'm interested in how it's done.
Continuous Integration enables a team integrate & test their work frequently. Automated builds are meant to compile, link and run unit-tests. You want your CI to run fast, especially if you run it at every check-in. That is why you would want to restrict CI activities to simple confirmation of the build and unit tests alone. What you're asking seems more-along the lines of quality assurance (QA) testing...and having QA failures mixed into your CI efforts would detract development efforts from progressing.
As such, I'm more under the impression activities associated with CI are not dependent upon the final physical machine said work may eventually be migrated to.
Now...this doesn't mean you CAN'T take the CI-compiled package and run it against some final target-machine....but again...that is really considered a seperate activity.
This seems to be re-enforced in the following article by Martin Fowler.
Notice he doesn't talk about the final targeted devices...only the build machine.
I can suggest Test Manager that is part of the TFS suite of Microsoft. I have not tried it with many different environments apart from windows based though I know there are many connectors. For windows based environments I believe it will satisfy most needs.
I use it for nightly builds to perform smoke tests (Turn it on, see if any smoke comes out) but you have to be careful to keep tests small in order to have them finished in a matter of hours and not days, if you want it to be part of your CI.
Then when you have a good enough quality you can proceed onto regression tests and integration tests if needed.
I wouldn't get too caught up in what a CI system is supposed to do or not do. Instead I would focus on the problem you are trying to solve. It sounds like that problem is to facilitate development on multiple platforms. You can use the concept of Continuous Integration and add to it successfully address the issue. I know, because I've done it in the past.
I implemented a build system for code that needed to compile and test successfully on 4 different platforms (nt, wince, linux-arm, linux-x86). The CI server would:
Used a linux and winnt build server compilation (and cross compilation)
The compiled tests and supporting libs would then be copied to the appropriate devices and an automated test run executed.
After the test suite was completed the log would be copied back, (or it was written to a network mounted fs)
If the test suite was successful we would tag the source, and package the libs and executables.
This same platform was reused for developer verification before commits. Developers would run a partial build and test (only updated source would be recompiled and those tests rerun). The CI would execute a full build (from scratch).
Our build were pretty fast because we had a proper DAG for build dependencies. This allowed for concurrent compilation within a platform build. Each platform build was also concurrent. As a result partial builds took a few seconds, full builds took ~30 minutes. Our build servers were quite beefy (optimized for fast compiles) and the codebase was of moderate size (I don't remember the stats).
Related
I am 'relatively new' to unit-testing and TDD. Only more recently have I completed my first production application that has (at least in theory) 100% code coverage. I have done unit-testing in previous projects as well for some time, but not in true TDD fashion and with good code coverage. It had always been an after-thought. I feel I have a pretty good grasp on it now though.
I'm also trying to train the rest of the team on TDD and unit testing so that we can grow togeather and start moving forward with doing unit testing in all of our applications, and eventually progress to doing full TDD w/ automated builds & continous integration. I posted a thread here regarding my plan of attack / training agenda for comments & critisism.
One of the replies (in fact the highest voted) suggested I first setup infrastructure before I go forward with the training. Unfortunately I have no exposure to this, and googling on the topics is difficult because the pages for CruiseControl.NET / nAnt / etc do not really explain the 'why' we should set this up and the 'how' everything connects togeather.
We are a small shop (about 10 developers) and use almost exclusively microsoft technologies and do our development in VB.NET. We are looking to eventually start using C# but that's for another time. I've been using the MSTest project that comes with VS2008 for my unit tests, and I've been building my apps using Visual Studio, and deploying using MSI setup projects... We also (unfortunately) use VSS for our soure control - but that is also on the chopping block and I'd really like to get rid of it and use subversion.
I know that I need to use CruiseControl.NET for CI, and either nAnt or MSBuild for building the applications. And I probably need a build server to run all these builds. But I just can't find anything that 'connects' the dots and explains how they interact with eachother, what should be on your build server, when you should build with your build server (is it just for deployment builds, or even when you just want to compile the app you're developing after making a small change, on your local environment?). I'm also planning on axing MSTest as I've found it to be buggy and will use nUnit instead.
Can anyone perhaps illuminate this gap I have from 'knowing how to do TDD' to 'setting up the proper infrastructure so the whole team can do it and work togeather'? I do understand what continous integration is, but again, I'm not sure how a build server should be setup and how it connects with everything, and why we need one (e.g. the pitch to management).
thanks very much for your time.
What portion of finalbuilder do I need? It seems there's some overlap with final builder and teamcity. Finalbuilder server seems to be a CI server, so I'm guessing I don't need that. FinalBuilder seems to be a build server - but I thought TeamCity is also a build server... And Automise seems to be a visual windows automation tool, like some kind of development platform for winforms apps...
_I also don't see support for final builder in The Team City Supported Apps Diagram : _
Take a look at a webinar I did a few weeks ago - How To Start Unit Testing Successfully. In that webinar I've talked about tools and unit testing best practices and it was aimed at developers just like you who want to introduce unit testing in their organization.
First order of business you want to put a CI (Continuous Integration) process in place and for that you'll need three tools:
Source control
Build server
Build client/script
I hope you already have some form of source control in place so let's talk about the other two.
Build Server - checks the source control and when it changes (or some other condition met) runs a build script on some client (or same machine) there are several build server available I recommend JetBrain's TeamCity it's easy to install and use (great web interface) and is free for up to 20 developers (that's you).
Build Script - on your build client you want to run a build script that would build your solution and run your unit tests. TeamCity has some basic build & test capabilities but for more advanced options (build installer, documentation etc.) you'll need some script runner at work we use FinalBuilder - it's not free but has very good editor. If you're looking for a free alternative have a look at ANT or NANT - but be prepared to edit a lot of XML.
Other tools - Because an important part of successful unit testing is how easy it is to write and run tests on the developer's machines I suggest you check if there are better IDE's or external tools that would help the developers write & run their unit tests.
At work where we do LOB .NET/MSSQL developement, many projects we have are 2 person or even 1 person projects that have development life cycles of 1-3 months. The developers serve as business analyst/project managers/QA so things get done fast with minimal 'BS time' spent. We do get the bigger projects that can take 6 months and have a team of 5 devs on it, but these are more uncommon.
We're doing a push to initiate everyone doing TDD going forward (my most recent project has full code coverage and was developed solely), and I was doing research on the architecture required to take maximum benefit of it. It seems that most people doing TDD are doing CI, have a build server and are doing automated builds and have some kind of automated client build tool (FinalBuilder or nAnt) etc.
So my questions - I see the obvious benefits on the uncommon large projects where you have 5 people working on the same codebase at once - but will we see much benefit from doing CI on the small 2 man projects? What about on a 1 man project - for those is it just a complete waste since you're really not 'integrating' with anyone? And, how would you pitch CI / automated builds / build server to management?
Having an automated/repeatable build process, and being able to prove that the current build passes all tests and runs in a server environment is worth the effort on any size project IMHO.
I'd pitch it this way: manual builds are manual. Things can get mixed up even on small projects . An automated build solves this problem. The amount of time it takes to set up the build script will be made up many times over during the lifecycle of the application.
As far as CI with test runs etc... goes: It's a constant health check on the quality of the code base. It's good to know as soon as possible when one thing inadvertently breaks another thing.
On a small project, you don't need most of the infrastructure to do CI, especially the build server. What you do need is the tests, the build automation, revision control, and a controlled build environment. You can just as well have your build and test servers be virtual machine images you run on your workstations... just so long as the images are under revision control like the rest of the project.
my team is currently using buildbot to automate overnight and continuous-integration builds and regression tests. For builds and unit tests, the builder just invokes a script which syncs the sources from p4 and then runs xcodebuild. The regression tests are also launched by a shell script, and are themselves combinations of shell scripts and AppleScripts. The builds are all performed on one system but then buildbot triggers tests to happen on multiple Macs, with different architecture and OS combinations. The things I like about buildbot are the automatic triggers (so the tests run only if and when the build succeeds), and the reporting including the waterfall view to see the overall status.
However, I see a number of problems too. The "master" process which coordinates the builds is either leaky or just has a huge working set which means that it consumes a couple of gigabytes of memory. Occasionally network problems mean that a slave will be lost; rather than retrying later it will just fail the build. In fact if the slave is supposed to be triggered for a dependent build, it will fail the first build after it has otherwise successfully completed.
So what are the rest of you using to automate your Xcode builds and unit tests? How do those solutions work for you? Anything you would recommend?
I use TeamCity in a windows environment but I believe it will work on Mac and has xcode build agents.
Another similar question here.
Our team use Hudson with a script which converts the Unit Test output from XCode to NUnit format.
I know this is an older question, but for those using TFS to hold their Xcode projects, I created a custom build activity to make automating Xcode builds via TFS easier. The code is hosted on Codeplex here: http://tfsxcodebuild.codeplex.com/.
Hope someone finds it useful!
We worked out what was using all the memory - log files - older buildbot keeps all logs forever and keeps them in memory (possibly until a restart).
Newer buildbot can be configured to keep a fixed amount of history.
Buildbot build log files should be limited in size to avoid the problem.
I use the XcodeBuilder that's part of CruiseControl. Of course it helps that I wrote it. :)
But I did use it on a real multiple person project for an iPhone app (Surf) that's for sale in the app store.
Now that it's three years later I have my own answer to provide to this question. I'm using Jenkins, mainly for the plug-ins that it provides. It has a plug-in for building targets in Xcode projects (or schemes in workspaces). There's a plug-in to run the Clang static analyzer. It interfaces with my bug-tracker system, it'll automatically push builds to Testflight too.
Our software is built on linux and windows platforms. Depending on the preference of the developer a contribution is developed and tested on either platform and then committed to our subversion repository. It then turns out that the contribution doesn't build on the other platform, and a fix has to be made. The fix on the other platform may again break the build on the original platform, and so on.
I'd rather see that a contribution is built (and regression tested) on the other platform as well before being committed. We have a continuous build server (CruiseControl), but that server builds from the repository. I am looking for a solution where the continuous build server builds on the other platform as a pre-commit check and then commits the stuff if the build and test succeed.
Any suggestions?
Teamcity handles pre-tested commit, you may be able to do something with the new build chaining features in 4.0( http://www.jetbrains.com/teamcity/features/newfeatures.html ). Agents are cross platform and can be configured to only run particular bits of the build, so could possibly be configured to only run a subset of tests.
Note that I haven't actually done this :)
It might be easier to have two branches, one where people checkin, and another which they merge their changes into after they have passed continuous integration.
Matheiu Godlewski has made a good suggestion at the CruiseControl wiki
If you combine his suggestion with the veto element, I think you should be set.
We used a custom build and test rig that could remotely deploy to multiple OSes (and multiple Database products on multiple OSes). This was done as a nightly build with a rule that you fix your bugs the next morning.
No entirely continuous then, but that's potentially a lot of work to do on a pre-commit hook. Especially if your source control repository locks the affected files for the duration of the pre-commit hook execution.
I think there's a difference between a continuous integration test that runs during the day, per-commit, and a system integration test that runs nightly.
Douglas Leeder suggested an "integration" branch - the nice thing about it is that it's possible to automate. If the tests pass - merge to the 'trunk'.
Some version control systems (e.g. bzr/hg/git) make this easier than others, but it's possible on most.
Setting up an integration server, I’m in doubt about the best approach regarding using multiple tasks to complete the build. Is the best way to set all in just one big-job or make small dependent ones?
You definitely want to break up the tasks. Here is a nice example of CruiseControl.NET configuration that has different targets (tasks) for each step. It also uses a common.build file which can be shared among projects with little customization.
http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk
I use TeamCity with an nant build script. TeamCity makes it easy to setup the CI server part, and nant build script makes it easy to do a number of tasks as far as report generation is concerned.
Here is an article I wrote about using CI with CruiseControl.NET, it has a nant build script in the comments that can be re-used across projects:
Continuous Integration with CruiseControl
The approach I favour is the following setup (Actually assuming you are in a .NET project):
CruiseControl.NET.
NANT tasks for each individual step. Nant.Contrib for alternative CC templates.
NUnit to run unit tests.
NCover to perform code coverage.
FXCop for static analysis reports.
Subversion for source control.
CCTray or similar on all dev boxes to get notification of builds and failures etc.
On many projects you find that there are different levels of tests and activities which take place when someone does a checkin. Sometimes these can increase in time to the point where it can be a long time after a build before a dev can see if they have broken the build with a checkin.
What I do in these cases is create three builds (or maybe two):
A CI build is triggered by checkin and does a clean SVN Get, Build and runs lightweight tests. Ideally you can keep this down to minutes or less.
A more comprehensive build which could be hourly (if changes) which does the same as the CI but runs more comprehensive and time consuming tests.
An overnight build which does everything and also runs code coverage and static analysis of the assemblies and runs any deployment steps to build daily MSI packages etc.
The key thing about any CI system is that it needs to be organic and constantly being tweaked. There are some great extensions to CruiseControl.NET which log and chart build timings etc for the steps and let you do historical analysis and so allow you to continously tweak the builds to keep them snappy. It's something that managers find hard to accept that a build box will probably keep you busy for a fifth of your working time just to stop it grinding to a halt.
We use buildbot, with the build broken down into discrete steps. There is a balance to be found between having build steps be broken down with enough granularity and being a complete unit.
For example at my current position, we build the sub-pieces for each of our platforms (Mac, Linux, Windows) on their respective platforms. We then have a single step (with a few sub steps) that compiles them into the final version that will end up in the final distributions.
If something goes wrong in any of those steps it is pretty easy to diagnose.
My advice is to write the steps out on a whiteboard in as vague terms as you can and then base your steps on that. In my case that would be:
Build Plugin Pieces
Compile for Mac
Compile for PC
Compile for Linux
Make final Plugins
Run Plugin tests
Build intermediate IDE (We have to bootstrap building)
Build final IDE
Run IDE tests
I would definitely break down the jobs. Chances are you're likely to make changes in the builds, and it'll be easier to track down issues if you have smaller tasks instead of searching through one monolithic build.
You should be able to create one big job from the smaller pieces, anyways.
G'day,
As you're talking about integration testing my big (obvious) tip would be to make the test server built and configured as close as possible to the deployment environment as possible.
</thebloodyobvious> (-:
cheers,
Rob
Break your tasks up into discrete goal/operations, then use a higher-level script to tie them all together appropriately.
This makes your build process easier to understand for other people (you're documenting as you go so anyone on your team can pick it up, right?), as well as increasing the potential for re-use. It's likely you won't reuse the high-level scripts (although this could be possible if you have similar projects), but you can definitely reuse (even if it's copy/paste) the discrete operations rather easily.
Consider the example of getting the latest source from your repository. You'll want to group the tasks/operations for retrieving the code with some logging statements and reference the appropriate account information. This is the sort of thing that's very easy to reuse from one project to the next.
For my team's environment, we use NAnt since it provides a common scripting environment between dev machines (where we write/debug the scripts) and the CI server (since we just execute the same scripts in a clean environment). We use Jenkins to manage our builds, but at their core each project is just calling into the same NAnt scripts and then we manipulate the results (ie, archive the build output, flag failing tests etc).