VSoft Technologies Blogs

rss

VSoft Technologies Blogs - posts about our products and software development.


Introducing Continua CI - Beta

We have now opened up the Beta program for Continua CI. 

What is Continua CI

Continua CI is our next generation Continuous Integration server product. This product will replace FinalBuilder Server once it's released.

Continua CI is a far more advanced CI server than FinalBuilder Server, it's not tied to FinalBuilder (although it works very nicely with it), Continua CI supports FinalBuilder, MSBuild, ANT, NANT & Visual Studio as build engines (more will come in updates). The builds are performed by Agents, either on the same machine or on other machines as the Continua CI Server.

Version Control Support

In the initial release these version control systems will be supported :

Bazaar, Git, Mercurial, Perforce, Subversion, SurroundSCM, TFS & Vault

Note that we have absolutely no plans to add support for Source Safe(it's long overdue for retirement). We will add support for others in the future where there is demand.

System Requirements

Server :

Windows Server 2003 or higher (no windows XP), .NET 4.0, SQLServer 2008 or higher, or PostgreSQL 9.1.3 or higher (this is the default db an installed with the server)

Agent : Windows XP SP3 or higher, .NET 4.0 - other platform support is currently being investigated.

Browser : HTML5 capable browser - IE9, Google Chrome 21 or higher, Firefox 14 or higher.

Licensing

Out of the box, Free of charge, Continua supports :

  • Unlimited Users
  • Unlimited Projects
  • Unlimited Configurations
  • 1 Local Agent(on the same machine as the server)
  • 1 Concurrent Build. 

After that you can purchase concurrent build licenses. Once you have at least 1 license installed, you can use as many remote agents as you like, agents do not take up licenses, concurrent builds do.

We explored many different licensing schemes and we believe this scheme will work out better for most people. The most common complaint about FinalBuilder Server was the per user licensing. Managing user licenses is easy when you have a small local team, but for larger distributed teams it becomes problematic. Most build servers have lots of projects but they are typically only running a few projects concurrently. Also, by not licensing agents, it allows you to have agents with specific capabilities. Agents report their capabilities to the server and are chosen for a build based the requirments of the project and the agent's capabilities. Say for example you have a project that is rarely built and it uses a specific tool and only installed on one machine, installing an agent on that machine will not tie up a license, it will only use a license when that project is being built.

Moving from FinalBuilder Server

There is unfortunately no direct migration from FinalBuilder Server. The two products are very different, so unfortunately the only option at this time is to start from scratch. We do have someone working on migration scripts, but those scripts will not get you fully up and running in Continua CI. The main issue has to do with where the FinalBuilder project files live in FB Server (on the server) vs Continua CI (in your version control system).

I recommend reading this page to help understand the different concepts between the two products.

How much will I have to pay when it's released?

If you have a current FinalBuilder Server Users Software Assurance Subscription at the time of release, we will convert your FinalBuilder Server User licenses into Continua Concurrent Build licenses (2 users = 1 concurrent build license).

New Concurrent Build licenses will be priced at US$199.

How do I get it?

The beta download links are pinned at the top of the Continua CI General Discussion forum

Can I see some Documentation?

Yes, the product documentation is here. The documentation is still being written however there is fair bit there already.

What if I find a bug?

Please post as much information as you can about your environment, the build of Continua CI you are using and the bug in the Continua CI Bug Reports forum.


Introducing Delphi Mocks

Delphi has had Unit Testing support (in the form of DUnit) for many years, but until now there very little in the way of Automatic Mocking. By contrast the .NET and Java worlds have plenty of mocking frameworks to choose from. 

So what are Automatic Mocks anyway? Simply put, they are mock objects that you don't have to hand code. What's wrong with hand coding mock objects you might ask? Well nothing, really, but consider the following example, where we pass an instance of our hand coded mock object to the object under test. 

type IFoo = interface
function Bar(param : integer) : string;
end;
procedure TTestSomething.SimpleTest;
var
something : ISomething;
mockFoo : IFoo;
begin
something := TSomething.Create;
mockFoo := TMockFoo.Create;
something.UseFoo(mockFoo);
end;


 What does our mockFoo mock object actually do, what is it's behavior, how many times will Bar be called and what will it return? It's not obvious from looking at the above code, so you would have to go off and find the TMockFoo

implementation. Not so hard, but what happens when someone else comes along and adds a new unit test that also uses TMockFoo, what happens if they change the TMockFoo implementation, will that break your existing tests. This is where automatic
mocks can help, because you define the behavior and expectations on you mock object right there in the unit test method :

procedure TTestSomething.SimpleTest;
var
something : ISomething;
mockFoo : TInterfaceMock 
begin
something := TSomething.Create;
//create our auto mock
mockFoo := TInterfaceMock .Create;
//define the behavior of IFoo.Bar
mockFoo.Setup.WillReturn('hello something').When.Bar(1);
//define our expectations of how  many times TSomething will call IFoo.Bar
mockFoo.Setup.Expect.Once.When.Bar(1);
//now lets test ISomething.UseFoo
something.UseFoo(mockFoo);
//Now verify that ISomething used IFoo correctly
mockFoo.Verify;
end;

The auto mock object is defined right there in our unit test, and the behavior is not going to change unless we change it in our unit test. This sort of mocking makes it simple to focus our testing effort on TSomething rather than TFoo (our real IFoo implementation) or TMockFoo.

One of the reasons auto mocking hasn't really happened for Delphi is the lack of detailed and easy to use runtime type information (Rtti) and the lack of runtime code generation (yes it's always been possible, but not through a well defined interface like Reflection.Emit in .NET). Auto mocking involves creating types on the fly, in the case of interfaces, creating a type and implementing an interface. That's not an easy thing to do. There are some examples of this in Delphi's SOAP code, but they are not easy to follow. Delphi XE2 introduces some new features in the RTTI that make creating interface proxies simple. TVirtualInterface creates an implementation of an interface at runtime and marshals the method calls to the OnInvoke method. 

Delphi-Mocks - https://github.com/VSoftTechnologies/Delphi-Mocks is an attempt to create an Auto Mocking framework for Delphi. It makes use of Generics and Fluent style interfaces. Currently only interfaces can be mocked, and it supports only Delphi XE2 at this time. I hope to add support for TObject mocks and earlier versions (D2009+).


EC2 Support in FinalBuilder 7.0

FinalBuilder 7.0.0.1497 adds support for Amazon's EC2 Cloud Services. The EC2 Actions allow you to interact with EC2 instances during your build process. This enables deploying to test or production environments running on EC2 services.

The EC2 support add's 16 new Actions to FinalBuilder :

EC2 Get Instance Properties - This action allows you to retrieve the selected property of instances available to you. You can filter which results to return using the optional filters.

EC2 Change Instance States - This action enables you to change the state of one or more instances.

EC2 Run Instances - This action enables you to run (create) one or more instances.

EC2 Terminate Instance - This action enables you to terminate one or more instances. Note that this action is permanent and cannot be undone.

EC2 Get Image Properties - This action allows you to retrieve the selected property of images available to you. You can filter which results to return using the optional filters.

EC2 Create Image - This action enables you to create an image from an instance.

EC2 Deregister Image - This action enables you to deregister (delete) an image. Please note that this action is permanent and cannot be undone.

EC2 Create Volume - This action enables you to create a volume, either as a blank volume of a specific size, or a volume restored from a snapshot.

EC2 Delete Volume - This action enables you to delete a volume. Note that this action is permanent and cannot be undone.

EC2 Attach Volume - This action enables you to attach a volume to an instance.

EC2 Detatch Volume - This action enables you to detach a volume from any instances it is attached to.

EC2 Get Volume Properties - This action allows you to retrieve the selected property of volumes available to you. You can filter which results to return using the optional filters.

EC2 Get Snapshot Properties - This action allows you to retrieve the selected property of snapshots available to you. You can filter which results to return using the optional filters.

EC2 Create Snapshot - The Access Key and Secret Key for your AWS account. If "Use Global Values" is checked, the values set in the options page (Tools > Options > Internet > EC2) will be used instead.

EC2 Delete Snapshot - This action enables you to delete a snaphot. Note that this action is permanent and cannot be undone.

EC2 Get Availability Zones - This action allows you to retrieve the name of availability zones available to you. You can filter which results to return using the optional filters.

 


FinalBuilder: now with NuGet-y goodness

NuGet is a open source package management tool for .NET applications. It allows you to very simply install, create and share reusable assemblies. With the latest release, FinalBuilder now contains a set of actions to help you interact with NuGet as part of your automated build process.

 

First things first

To get started, you'll need to download nuget.exe from codeplex. Optionally, if you'd like to Push or Delete to nuget.org you will need an APIKey. You can get one by creating an account at nuget.org and going to the My Account page.

Once you have those, in FinalBuilder go to Tools -> Options and under .Net Tools select NuGet. Set the path to the folder where nuget.exe is located and if you have an API Key, add it in as well.

 

Installing packages

If you use nHibernate, jQuery or any of the 1500 other packages that are available from nuget.org, you can use the NuGet Install action to keep your build process up to date. This is particularly useful if you're using FinalBuilder on a continious integration server such as FinalBuilder Server.

You can install from the default (nuget.org) server or your own custom package feed. Having your CI server pull down the latest version of a third party library is a quick and easy way to see if the latest version has any breaking changes for your codebase. If it does, you can choose to install a specific version until you've modified your code to be compatable with the changes.

 

Sharing packages

If you develop an open source library for .NET and want people to use it, it makes a lot of sense to have it published on NuGet. And if you use FinalBuilder to build the library, it's pretty simple to add publishing into your build process. Or, if you have a lot of shared internal assemblies and are looking for a better way to distribute them, publishing to an internal NuGet server may make your life a lot easier.

FinalBuilder has 4 actions to help with the publishing process. If you're familiar with using nuget.exe from the command line they should be very familiar.

The Spec action creates a .nuspec file - either with placeholder data or with metadata from a project file (.csproj) or an assembly. The nuspec is an XML file, so after you've created it you can use FinalBuilder's XML actions to easily manipulate it.

The Pack action creates a .nupgk file from your nuspec, ready for deployment. Alternatively, you can create a package directly from a project file. The Pack action lets you choose which project configuration to use (if you're using a csproj), override the version number and use a pattern to exclude files from the package.

Once you have your nupkg, you can use the Push action to publish it to either the default server on nuget.org, or to your custom NuGet server. If you prefer, you can upload but not publish the package. That way you can manually go to the site and press the Go button before anyone will see it.

Lastly there's the Delete action, which removes the package you specify from the server.

 

Further information

NuGet.org is the place to go any lots more information. Scott Hanselman also has an excellent presentation that covers everything you should need to know (although we disagree with his choice of build automation tools :) )


Over the next few posts, I'm going to try to talk about some of the lesser known features in FinalBuilder, and show some ideas and techniques that I hope will help you improve your FinalBuilder projects.

Wouldn't it be great if a failed action could automatically retry if it fails?

Absolutely, it's a great idea, and its a feature that's been in FinalBuilder for several years. Unfortunately it's not as obvious as it could be, we ran out of screen real estate a few versions back and it got pushed into another dialog (rather than add another tab!)

Note that this feature should really only be used when accessing a resource which might occasionally fail, for example we use this on our SignTool action when codesigning/timestamping the exe's because the timestamp server (Verisign's) sometimes fails to respond. We found if we ran the build again straight away, the timestamp server usually responds just fine, the server availability issue is usually transient and the retry option with a suitable pause resolves this issue nicely. It makes no sense to use this option on a compiler action though, as the result would most likely not change.

I wish I could define local Variables!

In FinalBuilder 7, you can! The Action Group action in FB7 allows you to define local variables. These variables are then available to all child actions of the Action Group action.

 

How can I capture and process the output of my custom executable?

We get ask this one quite often, so I guess we haven't done a great job of publicising the Output Monitors feature. Output Monitors are available on all actions, and they allow you to process the logged output of the action. A typical example of the use of output monitors might be to fail an action if a particular bit of text is output from the action.

 

Variable Suggestion (F12)

This is another one of those features that has been there a while but is not well known. I showed this feature to some of the newer developers here last week and got lots of "oh wow, I never knew that" type responses. I have to admit I'd forgotten about it myself until I started looking for ideas for this post! The way it works is that pressing F12 on a text field will drop down a list of suggestions on variable usage. The list is weighted so that variables that replace the most of the original string will list at the top. This is a great help in making sure you don't hard code paths when the project needs to run on another machine.