We're getting close to release of Continua CI. What we desperately need is more feedback from beta tests. Tell us how you are using Continua CI, what features you are using (in particular which VCS). Whist we are still doing plenty of in house testing, we're not regular users of every VCS (we use Hg and SurroundSCM in house), so it's still possible what we think is ok is not really the case in the real world.
If there's something blocking you from using Continua CI (bugs, missing features etc) then please do tells us about that.
My hope is to have a release candidate out later this week, and barring any major issues the release will be available next week.
How we're using it - pretty basic config I suspect (and it's all been working great the last few releases):
- Server + agent on the same machine (i.e. no remote agents) - 15 x Hg repositories (some duplicates - due to no repo mapping), monitoring both default branch and non-default branches with triggers - JIRA issue connector - DUnit - FinalBuilder 7 actions do most of our heavy lifting
Some future features that would help a lot (some of which I know are going to be addressed later):
- Repository mapping or the ability to specify different repository branches per config (this is our biggest request!! we have some big repos we have to add twice at the moment) - Ability to 'cleaup' work directories from the web interface. When builds fail, they leave the work dir behind - which is great for troubleshooting - but a way to clean them up from the interface would be great.
If I think of something else, I'll be sure to add it - but we're really happy with the improvements to Continua over the BETA phase and will continue to use it as an integral part of our workflow after release. The prospect of tighter integration with FinalBuilder is something to look forward to!
Thanks for the feedback, much appreciated. With regards to workspace cleanup, under Admin, there is a cleanup section where you can define how often the cleanup happens. You can also override that on a per project basis. We’ll look at adding a way to clean up individual builds on demand as well.
Here I’m testing it using my local machine as server / agent with no remote agents yet.
Tomorrow or new Core i7 3.6 ghz 10mb cache, 16gb ram will arrive and it will be setup with xenserver with 3 vm 1 build server, 1 build agent and 1 AD Server.
In my notebook I will let the agent installation and uninstall the server from it (will have to make a backup and restore in the new server)
Today the Continua CI is used for two of our projects each one with its mercurial repository and with subrepository, we have four stages for each project the first one the build, the second one is the unit test, the third is the code coverage and statistcs and the last one is the deploy.
All our builds was simplified now with continua, it just builds and setup its version information to the output file. Ps. Every Build is a Finalbuilder script, currently we have something like four or five finalbuilder scripts to build each project. The test stage runs DUnit tests builded during the build process The code coverage and statics stage runs our codecoverage tools, exports to xml and import it to reports inteface. Finally the deploy fase put its build results (new install setup, update setup, etc) to an dropbox folder shared with the development / support team, for internal teste / use.
Our plans is to add one more stage to tag our repository with the build number or something like that when an release is made to our customers. (We need to plan on how it will work)
We are using Plasticscm version control and have been long time final builder users and were hoping to get to use Continua. It is a very good DVCS that is much like git yet with a very nice GUI. And a much shorter learning curve. Will we be able to adapt this ourselves?
PlasticSCM is on the todo list, we just haven’t gotten to it yet. As far as customers extending Continua, that will be possible in the future, however at the moment that ability is disabled while we fine tune the api’s and functionality. I’ll see if I can get somone onto the plasticscm support asap.
The following is list of some misc items we’ve noticed while playing around with the most recent beta: - SVN Repository edit dialog is too high for reasonable sized window - Config Repository page show only icon for repository state without even tooltip indicating the actual state. - User full name and system generated email address (username@domain) is used in mixed way. — For example in build changes -view username@domain -version is used, while in details view only username is shown. In our case the username@domain -format is really never actually used, is confusing, and addtionally it’s not valid email address for us. — Build details -view shows build started by as username@domain -format. Full name would be preferred. - Repository issue connectors are not working correctly in Build Changes -view - the HTML -code for the link is shown instead of the link. - The event log could use the actual time of the event (preferably in ISO8601 format) in addition to the current way of specifying how long ago something occurred. The exact time is often important, and at least it’s bit frustrating of having to calculate the time of the event from “17 hours 9 minutes ago” -format.
Posted By Lars on 27 Feb 2013 03:01 AM Will there be FB6 support, too?
Only via the Execute Program action, which you can use to call fbcmd. For FinalBuilder 7, we modified the logging in FBCMD to output in a format Continua understands so it can provide a nice structured log.
It was already on the todo list, I suspect it’s been left in the too hard basket, the service doesn’t have any information about the web routing. I’ll take another run at it.
OK, wasn’t so hard after all… next build will have ProjectUrl,BuildUrl and ConfigurationUrl available in the build notification templates (I updated the default templates as well).