At the moment, we are running our automated (not CI as such) builds via FinalBuilder via a very simple homegrown Apache interface that just launches the FB scripts on our server. (I like FinalBuilder, and will keep it, but it's CI server, FinalBuilder Server just doesn't cut it IMHO -- especially it doesn't support any "agent" concept at the moment to distribute builds across machines.)
We are doing native C++ development on Windows with a bit .NET mixed in where it's needed and makes sense.
Our current FinalBuilder scripts do everything quite well, from creating nightly builds to full releases (build / automated translation / build / unit test / create setup / put created artifacts on a network share / ...), but our webinterface, queuing abilities, user traceability and reporting is pretty limited.
I have looked around and it seems that TeamCity and Bamboo tick similar boxes, but most descriptions I can find cover only Java and/or .NET simple builds.
So my specific question is, given
several (20-30) complicated FinalBuilder Scripts that work to my satisfaction and that I will have to integrate into ("call" from) the new automation/"CI" server
Native Windows C++ and .NET projects
The actual build (= compiler invocation(s)) is done via a few Visual Studio solution files at the moment
Currently one build server machine, wishing to scale to 2-3 atm.
Using JIRA as issue tracker
using AccuRev as SCM
which tool is better suited, and why: TeamCity (currently 6.5) or Bamboo (currently 3.1).
(Note that I also hope to get some highly subjective answers on the TeamCity and Bamboo forums.)
For TeamCity side, it integrates with Jira, has AccuRev plugin, and has a good support for VisualStudio/C++ projects. It can also run arbitrary scripts.
You can trigger a build and obtain some build results via HTTP-based API. In the UI, you can see which changes have been built and in which build configurations. Easily integrate any custom HTML reports into TeamCity UI (no coding), publish artifacts.
Probably, you should try both solutions and see which one is more suitable for you (with Teamcity, you can use full-functional server for free, the only limit is number of build agents and number of build configurations).
Disclaimer: I'm a TeamCity developer
I found Bamboo more credible than TeamCity. Here are my reasons:
Those Jira plugins for VS or Eclipse are Bamboo plug-ins too. :) no extra add-ins needed.
Better support for Jira integration.
Nice user interface, like the one you used for Jira.
Ability to better integration with other Atlassian tools, such as FishEye.
Cheaper. A 10$ license will suffice your company.
More add-ons on Bamboo than TeamCity, lots of plug-ins.
For completeness' sake: I ended up using Jenkins + Finalbuilder. :-)
I worked in a similar environment using FinalBuilder for build automation, AccuRev for source control and a native windows projects.
I ended up selecting Electric Commander as the best CI solution for the job. It is possible to reuse parts of the FinalBuilder scripts and call them from Electric Commander but simply calling the FB script as one build step would result in you missing out on some of the key advantages of using Electric Commander - realtime log file processing, the ability to parallelize right down to individual step levels in Electric Commander and data collection and reporting.
Electric Commander has an API that exposes all product functionality which can be used in combination with AccuRev triggers to achieve a very flexible solution.
Disclaimer - I liked Electric Commander so much I joined the company and am currently employed by Electric Cloud.
You can try Electric Commander by going to www.electric-cloud.com and clicking on "Try It!"
Related
I wonder if you have any mobile test automation tool that you can recommend? After trying several tools I simply cannot find one that meets every criteria. Ranorex can be used on both devices but after facing too many issues I have chosen not to use it. The best tool I have encountered is robotium, although it only works on Android and therefore is not interesting.
Criteria:
Possible to CI integrate.
Can be used with Nunit or a similar structure.
Can be used on both iOS and Android.
Is stable.
Please do not recommend one of these recording tools, since they (in my opinion) do not test anything.
Have a nice day an thank you for all the help.
Automation of applications on real devices for Hybrid/Native/Mobile Web can be achieved by using Appium which is an open-source framework.
Appium allows you to create once and use everywhere capability for mobile web apps, e.g., same script would be running on Android as well as iOS.
Its rich function library support enables you to automate even complex mobile application gestures e.g., tap, pinch, precise tap, swipe etc.
For more details on appium, visit: http://appium.io/
Maybe Tosca Mobile+ would be of interest for you:
http://www.tricentis.com/tricentis-tosca-testsuite/tosca-mobile-plus/
Tosca follows a model based approach - it's not script based, and it's also not a Capture & Replay tool. The identification of the controls is done via technology-related properties and IMHO the most reliable way for a stable automation.
Beside of Android & iOS, Tosca does support many more technologies (UI and Non-UI).
Tosca can also be completely integrated into your CI (using e.g. Jenkins, TeamCity, QuickBuild or any other build tool).
For more details you can also look at the Tosca Mobile+ Documentation:
https://documentation.tricentis.com/en/840/index.htm#tbox/mobile.htm%3FTocPath%3DTBox%7CTosca%2520Mobile%252B%7C_____0
May be it is bit late to answer this question - you can try M-eux from Jamo Solutions. It works well for android and iOS. Supports native, hybrid and web apps on both android and iOS. Continuous integration is possible. By default there is no out of the box integration but you can write unit test cases in junit. Compile them and put them in CI using jenkins.
Other option could be seetest from Experitest. Same features are available with this tool as well. Both of these tools are not open source or freeware.
You could try out Calabash. It can be used with both IOS and android and is easily integrated into a CI pipeline.
Have you tried SIGOS App Experience (formerly Keynote Mobile Testing/DeviceAnywhere)?
It integrates with many of the leading CI/agile tools including Appium, HP UFT, Selenium, and SAP. They offer testing on real devices and you can choose what type of deployment you want-- public cloud, private cloud, on-premise.
SIGOS App Experience also offers app performance monitoring, which not all test automation platforms do. https://appexperience.sigos.com/
I am a Qt/C++ developer. I would like to setup a continuous integration environment whereby after committing the source code, it triggers a build process that build the code for the 3 platforms I'm using:
Linux
OS X
Win32
If possible, how do I setup such environment. Any hints or links are welcome.
I've read around about Jenkins, but I can't find any good tutorial for it.
I also suggest Jenkins for several reasons:
It will run on all of the platforms you listed.
It can be configured to start a build when the repository is updated (hint: configure the Job to "Poll SCM" and you won't have to muck with your SCM tool to get it to tell Jenkins to start building).
It provides good support (mostly through plugins) for Unit Testing. [You're project is doing unit testing, right?]
The price is right
A bigger issue is going to have is that AFAIK, Qt doesn't really do cross-compiling for other platforms well. Using Jenkins (and the appropriate plugins), you should be able to solve this.
One method that comes quickly to mind is to have an instance of Jenkins on each platform. Each instance is responsible for building the version for its own platform. At the end of the build, the created artifacts are all put into a common, shared location.
Jenkins supports this feature via plugins for all major source control systems. If you seriously considering using Jenkins (and I would highly recommend it), consider buying John Ferguson Smart's Jenkins: The Definitive Guide.
Two solutions coming to my mind:
BuildBot
BuildBot is a highly customizable continuous integration system written in Python. The master component offers a nice web-based GUI to monitor and trigger builds; slave components are put on the target machines (usually virtual machines but they could be the Mac laptop of one of the developers). Docs are good enough to build up a basic system, customization could be a little tricky (at least it was for me). Using commit/push hooks provided by VC systems you can easily activate the master and trigger builds across the slaves. It also supports incremental builds (a must if your project is big).
CDash
Developed by the authors of CMake, CDash is a web application collecting builds coming from across the network, not exactly what you asked for but I think it's worth a try. Very powerful if you have a team of developers who could continuosly submit build result on their machines to the server (and if you use CMake it's almost transparent). You cannot trigger builds from the server as Buildbot does, but you could setup a bunch of VM with a cron which checks for changes and in case performs the build and sends results to CDash
Sure it's possible. Most of the version control systems are able to execute custom script on server side. Some of them (git, for example), has hooks to achieve the same locally. Have a look at git's post-commit hook.
All you need is to create a script that will trigger cross-platform builds.
Most version control systems allow post-commit hooks to allow you to kick off events like builds. Alternatively build systems can be configured to regularly poll a source control repository and manage their own build scheduling (this is how we use Jenkins).
Something to bear in mind is how long it will take to do a complete build across platforms and the typical number of check-ins in that interval. You might find batching check-ins a better way of doing continuous integration builds if you have an fair sized team or limited build server resources. Otherwise your build system could quickly end up trying to play catch up.
As for whether it is possible to build on all target platforms, that depends on your tool chain.
I've a question regarding Build Servers for .NET Projects. Currently I'm using TeamBuild in conjunction w/ TFS 2010 to do automated builds in the .NET world. Some older projects are built using plain old MSBuild scripts.
To get rid of the administrative effort I'm currently moving my sources to github. Github offers, as many other sites service hooks to trigger build servers for doing automated builds such as CI or nightly builds.
Sure I could use TeamCity OnPremise and dynamically create Build Agents in Windows Azure using VMRole and Virtual Disks, but I think this hybrid solution is a little bit moronic.
So what are your thoughts about the following architectural idea?
Let's say you're using github as source control platform. When commiting sources to your repository an Azure WebRole hosting a WCF Service will be triggered.
The WebRole itself will just use the Azure API to fire up a new instance of a custom Azure VMRole.
The Azure VMRole itself will use some kind of buildscript such as Rake or MSBuild to have as few developer tools installed on the build agent as needed. After building the entire project the artifacts will be published to Azure BlobStorage and the WebRole hosting the WCF service will be called again, but right now the Azure WebRole is going to terminate the BuildAgent.
While using such a setup you could minimize the costs for the build agent and build nearly any kind of project as far as you're able to install the required element for the build by using PowerShell.
So in bottom line: what are your thoughts on this architecture? Other Ideas? Is there an existing service offering such a solution?
Thorsten
have you looked at https://appharbor.com ? I know a number of people who are using it to do exactly what you are doing.
Check out Team Foundation Service as it can do the following:
Continuous Delivery to Azure
Deploy to production on Windows Azure with two clicks from Visual Studio, or automatically as part of your build process.
Just found this one http://www.appveyor.com/ AppVeyor is also free for OpenSource projects.
So, a friend and I have been discussing continuous integration and bat/powershell scripts versus CI servers like CruiseControl.Net or Hudson.
The following powershell pseudo script works to update from SVN, build using msbuild, deploy/copy out, update a build/revision number in the app, and emails on failed builds. The next step would be to add calls to MSTest and email results when not successful.
svn update
msbuild > build_deploy_development_out_msbuild
([xml](svn info --xml)).info.entry.commit.revision + [char]13 + [char]10 + (echo %date% %time%) > build_revision_number.html
$linenumber = Select-String build_deploy_development_out_msbuild -pattern "Build Failed" | Select-Object Linenumber
$smtp = New-Object System.Net.Mail.SMTPClient -ArgumentList localhost | if($linenumber > 0) $smtp.Send("From:Email","To:Email", "build failed", "build failed... some one must die!")
This has lead me to the question of the value of CI servers, when you can write your own shell scripts to accomplish the same goal, using the specific tools of the project (build tool, source control, unit testing) (i.e. msbuild, nant, svn, git, nunit, mstest, etc.)
I have not experienced the maintenance cost as of yet. I wanted to get others opinions on the roll your own shell script versus a CruiseControl.Net or Hudson. Please note, I do not have experience with CI servers, thus the question, so please don't take this as being critical of CI servers; I simply don't know the best answer, and thought I would ask the community.
Best wishes!
Pete Gordon
CI Servers give you several advantages:
Web access, usually with ability to integrate with existing authentication mechanisms (see Hudson's ActiveDirectory/LDAP support)
Tons of existing support for unit testing, zip archive creationg, etc.
Hudson (and others) supports slave build nodes, for doing distributed CI tasks.
No need to maintain it yourself.
Some of these may not be things you need now but are you sure they aren't things you might need in the future?
I've installed Hudson a couple of weeks ago to replace the current CruiseControl server. The greatest advantage I see in Hudson is that pretty much anybody can use it, while launching a parametrized build with CruiseControl (or a batch file) is still scary for a lot of people.
Usually I tend to write all my build scripts with Ant (because it's portable), insert a couple of parameters and I invoke them from Hudson.
Hudson gives your scripts a great visibility (everything can be seen on the front page) and they are self explanatory. Usually with a bash script, you need to write a readme (that nobody reads) and remember where they are located.
... or have it both. Ayende (the creator of Rhino Mocks) has done that recently. He wrote a CI server using PowerShell. Perhaps this provides new insights for your discussion.
For a year I've tried to maintain custom-written python scripts to do basic CI stuff: recieving notifications of commits via e-mail, checking out and building stuff, sending back blames and congrats, then when it came to publishing this for use by everyone else in my team, it turned out raaaather unusable without monitoring, web-access, etc, etc.
Then I've dived into buildbot and found it truly beautiful. I've set up basically the same process in a couple of days. Build script is a true python object, that is customizeable at the master, from where it gets transferred to slaves and executed there. Built upon twisted framework, that is lots of stuff out-of-the-box ;)
Web UI is minimalistic, though sufficient.
Well, this is unpublished too, though I'm close to it this time %)
Below are my thoughts on CI Server over a Powershell scripts
Highly Configurable Plugins are available for all different kinds of version control, notifications and testing.
Logs These are maintained wonderfully. Failure and succesful build logs are at your finger tip.
Scheduling You can set all kinds of scheduling including triggerring based on other succesful build
Security You can set different groups to be able to execute, view only or set to see some projects
Visibility You can use a web dashboard or cctray for different audiences.
Scalability. Easy to scale when needed.
Bottom line if you have to maintain lots of builds for different environment and team projects then CI Server is the way to go. Other than that a simple PowerShell Script is enough for small projects. Once the project grows you can just hook up the existing PowerShell Script to a CI Server.
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 8 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Cruisecontrol and Hudson are two popular continuous integration systems. Although both systems are able to do the automated continuous builds nicely, it just seems a lot easier to create a batch or bash build script, then use Windows scheduler or cron to schedule builds.
Are there better continuous integration systems available for C++ projects? Or is just using a script and a scheduler the simpler way?
We have been using CruiseControl for CI on a C++ project. While it is the only thing we use ant for, the ant build script for CruiseControl just starts our normal build script, so it is very simple and we haven't really needed to update it in a long while. Therefore the fact that CrusieControl is Java based has not really been an issue at all for us.
The main benefits of using something like cruise control are
A nice web page showing build status
Email after each build or after failed builds
Automatically build after a commit to the source control system
A firefox plugin to monitor the build status
Shows the output for any build errors.
Shows what files have changed since the last build (good for seeing which developer broke the buid)
Of course you can write a script yourself which does all of this, but why do all that work? In the long run the extra initial cost of setting up CruiseControl (or something similar) is probably much less than the cost of maintaining and updating a custom CI build script.
If all you need is to launch a daily build and a simple script started by cron is sufficient for your needs then by all means do that. However, one of the advantages of CI is that you get a build status report after every check in. Writing a script to do that takes more work and CruiseControl already does it.
We use Hudson for CI and SonarQube for code metrics. They're integrated, and Hudson has a handful of plugins that no cronjob can beat.
One great plugin is CI Game, which keeps a score about who breaks the builds and who commits without breaking it. Hudson has plugins to play with VMWare, Selenium, SVN, CSV, Git. It has RSS syndication, which can help you to automate even more everything else.
Hudson is great...
We've been using Dart Dashboard. It's open source but driven by KitWare. They've since changed the name to CDash which I presume is still as capable. We're doing several kinds of testing including nightly and continuous integration across 10 different platforms in both debug and release mode as well as running 1000s of application tests and reporting the results there too.
I've been using Buildbot for the Spring RTS engine project succesfully.
You can also try JetBrains' TeamCity. It's a commercial product but it gives a free license for up to 20 build configurations.
One of the nice features of a continuous integration (CI) tool is that a build gets triggered every time something is checked into your source control repository.
If that is not something you need then you are probably better of using the windows task scheduler or cron jobs.
In addition CI tools also come with a (web) dashboard and advanced logging capabilities.
Your question seems to me more "why would I use a CI tool" then "which CI tool should I use". If a batch script serves your needs, please use that. (Re)creating a build environment only becomes easier if you do not need a CI tool as an additional component. If you want source control triggered build, a dashboard, storage of old build results or other logging, use a CI tool and avoid developing all such functions in batch or shell scripts.