General questions

Hi,

 As a new participant of the beta testing we've just browsed thru some of the documentation to get the grasp of the product and how it relates to FBS. As a somewhat heavy user of FBS some general questions do not seem to be addressed in the docs.

  1.  Is Continua CI going to replace FinalBuilder Server?
  2. How the product is going to be licensed, and what kind of cost can we look forward to as a site licensor of FinalBuilder?
  3. Is Continua compatible with FinalBuilder Server? Can the server component and/or agents be installed in a system currently operating FinalBuilder Server 7?
  4. Documentation contained an empty page intending to discuss operating Continua in a virtual machine. Are there any limitations and/or considerations there that should be taken into account, as our current build infrastructure is totally virtualized?
  5. As we have not yet had the opportunity to actually test the software (partly due to not knowing answers some of the previous questions), it's somewhat unclear how Continua manages building multiple versions of the same product(s) hosted as a branches in same Subversion repository? Currently we have a Build -folder in the repository branch containing build script and related resources specific to particular version. As development environment etc. changes the build script evolves and the single script cannot build older versions.
  6. How are builds requiring resources from specific branches of multiple repositories handled? We have some third party code residing in a separate SVN repository and that's required for the build.
  7. How agents are managed concerning the specific requirements of the development environments? Currently our build requires specific versions of some third party components being installed to the build system and sometimes only one version of such component can be installed at a time. Therefore despite build systems/agents A and B both having Delphi XE installed, only A is capable of building previous release of our products as B has newer and incompatible component version installed. 
  8. Are there specific issues in using SQL Server as the database engine?

I'm sorry if I've missed answers to some of these in the documentation, or if they are already addressed in the forum somewhere.

In general the product appears impressive, but as a rather heavy user of FBS we find the migration and licensing as primary concerns.

If you are able to provide any migration suggestions, we would be glad to hear them.

Hi,
Thanks for the great set of questions - I’ll re-use my answers here to fill out our doco.

1. Yes. We will continue to support FB Server with the view to eventually migrate customers to Continua.

2. The licensing model is per concurrent build. That is, you have unlimited users and unlimited projects but pay more depending on how many builds you want to have running at the same time. You can queue up as many builds as you want, but only the licensed number will build concurrently.

Continua will come with one concurrent build for free, and you will be limited to running one agent. After you have paid for a concurrent build, you can have as many agents as you’d like. The price per concurrent build license is around the $200 mark.


Roughly, we’ll migrate one licensed FB Server user license to half a Continua concurrent build license, assuming you have active Software Assurance on your FB Server licenses. So for example, 6 FB Server user licenses would translate to 3 concurrent build licenses (giving you 4 concurrent builds in total).

3. There should be no issues running FB Server and Continua in the same environment/on the same host. However, they are completely separate products and won’t interact in any way .


4. The main consideration when it comes to VMs is I/O. Continua is pretty I/O heavy as it’s moving your source around, performing builds etc. There’s absolutely no reason why Continua won’t work perfectly in a VM, but if your VM host handles I/O poorly then obviously Continua may run somewhat slower than it would otherwise.

5. This is a really good question. For distributed version control systems we have the concept of ‘feature branch builds’ which does exactly what you’re talking about. With the current SVN support it would be possible to do what you want by defining one Continua repository per branch, but I don’t think it would be as clean and easy as we’d like. We’re going to have a look today to see if we can get SVN to behave in a similar way to the DVCSs. I’ll get back to you.

6. A configuration (which is what defines your build process) can have multiple repositories associated with it. Getting specific branches of more than one repository is the same scenario as q5 - ie it works for DVCSs but I’ll have to get back to you once we’ve seen what we can do with SVN.

7. Hopefully this part of the walkthrough will help answer this. Please let me know if it doesn’t: http://wiki.finalbuilder.com/display/continiua/Setting+up+a+real+world+project#Settinguparealworldproject-Agentcompatibility . The walkthrough is probably the most complete area of the doco currently, but it is easy to miss. We’re in the process of fleshing out the rest at the moment.

8. There shouldn’t be. We did most of the development against SQL Server (and a couple of us still use it on our dev machines). However when we added Postgres support we were surprised at how much we liked it, and we now use it on our build server.

In terms of migration between FB Server and Continua, we’ve been over this a lot here but we can’t think of a sensible way to automate it. Continua is much, much more scalable and flexible than FB Server and many of the concepts don’t cleanly map between the two. This is particularly true of complex FB Server setups, which (hopefully!) be a lot simpler in Continua. We will write some guides that walk through the manual migration process.

Again, thanks for the great questions. I’ll get back to you on SVN, but if there’s anything else you’d like to know (or if any of my answers need clarification) please let me know.

Cheers,

Ben

1. Yes. We will continue to support FB Server with the view to eventually migrate customers to Continua.

So there will not be any new major releases of FBS, only bugfixes etc for the 7.x series?

Roughly, we'll migrate one licensed FB Server user license to half a Continua concurrent build license, assuming you have active Software Assurance on your FB Server licenses.

Is it possible for us to use FBS and Continua concurrently using the "same" licenses?

I'm mostly concerned about migration - it's not feasible for us to try to migrate everything to Continua at once.

3. There should be no issues running FB Server and Continua in the same environment/on the same host. However, they are completely separate products and won't interact in any way .

 Ok, that's good to hear. We very much want to test this, but cannot provision entirely new build infrastucture, so it's good if we can run this on the same systems we are running FinalBuilder Server.

4. The main consideration when it comes to VMs is I/O. Continua is pretty I/O heavy as it's moving your source around, performing builds etc. There's absolutely no reason why Continua won't work perfectly in a VM, but if your VM host handles I/O poorly then obviously Continua may run somewhat slower than it would otherwise.

 

Are both the Server and Agents I/O heavy, or is either significantly more I/O intensive than the other?

BTW is there a way to limit what is moved to the Agent? For example our documentation resides in the same repository, but obviously is small part of the total source tree. We could provision an agent specifically building documentation, but moving the whole source to that agent would be waste.

In terms of migration between FB Server and Continua, we've been over this a lot here but we can't think of a sensible way to automate it. Continua is much, much more scalable and flexible than FB Server and many of the concepts don't cleanly map between the two. This is particularly true of complex FB Server setups, which (hopefully!) be a lot simpler in Continua. We will write some guides that walk through the manual migration process.


Is there any kind of general guidelines as to what parts of a FinalBuilder script should be migrated to Continua project and what parts should be left as FinalBuilder scripts run by Continua?

If you wan't to take closer look of our scripts or other parts of the setup, that can probably be arranged.

That’s correct - there will be no more major releases of FB Server, but maintenance on 7.x will continue.

We won’t ‘revoke’ your FB Server licenses when we issue you with the Continua ones, so you will be able to run both concurrently. 


I/O depends on usage (obviously). If you have a lot of users hitting the web front end, there will be significant I/O from the database (we do what we can to minimise this). Likewise if you have a lot of repositories that Continua is monitoring. 

Agents don’t do much other than get source and run builds, so I/O for them really depends on your build process and the size of your source.


There’s currently no way to move only part of a Continua repository to an agent. However, you could define a separate Continua repository that only referenced the doco path of your SVN repository.

As an aside, the source is synced to the agents in the background, so other than disk usage, there’s not usually much of a hit from sending source you don’t need.



In terms of migration, broadly speaking:
  • you will no longer need to get your source in your FB project
  • your FB project will need to be in a source repository that the build uses

So as an initial setup, you might just take the source control actions our of your FB project and run it with a single action in a single stage. As you get more comfortable with Continua and want to get more benefit from it, you can modify your the build process. For example:

    •  it may make sense to split the build process into multiple stages. We have Build, Test, Installer and Deploy stages. This can make better use of some of the Continua features (unit test metrics, stage gates, agent selection etc)
    • you may like to replace parts of your FB project with actions in Continua. In general Continua actions are more coarse-grained than FinalBuilder, so here we tend to use them when we can, and use FinalBuilder for the more fiddly/highly configurable things
    • If you have a complex build environment you may find that some of the features and concepts in Continua mean that your build script needs to do less

Again, thanks for the questions.

Cheers

Ben




2. The licensing model is per concurrent build. That is, you have unlimited users and unlimited projects but pay more depending on how many builds you want to have running at the same time. You can queue up as many builds as you want, but only the licensed number will build concurrently.


Does this really mean per concurrent build, or rather per authorized agent? The language of the UI would seem to suggest the first, but the functionality the latter interpretation.

 In basically trivial case these might be roughly equivalent, but in non-trivial setup this is definitely not the case. In our setup we might have 5-6 build servers with different configurations for different products and releases. However it would be exceedingly rare for us to have more than 2 builds running concurrently, despite having 2-3 times the number of agents available. As the agent configurations are different they are not equivalent, making them actually not very interchangeable.

Therefore in our case we would be quite happy if Continua is licensed on concurrent build basis, however as our product portfolio is expanding, and the number of versions we have to support and need to have the theoretical capability of building is increasing, licensing model based on the authorized agents might very well be prohibitively expensive.

Hi Olli,
It’s per concurrent build, not per authorized agent. I think the confusion comes in because you need to have installed at least one license to “unlock” the ability to register remote agents. 

Once you have bought a license for one concurrent build (giving you two in total - the free one and the one you bought) you can have as many registered agents as you like. 

Below is an excerpt from an article I’m writing which hopefully explains things more clearly (it’s still being drafted/reviewed so I can’t link you to the article itself).

Cheers,

Ben


Licensing that scales fairly

It’s free to get started with Continua. Out of the box you can run one build at a time with one agent. You can queue up as many builds as you’d like, and they’ll run sequentially. If you find that you need to run multiple builds concurrently you can purchase as many concurrent build licenses as you need.

Unlimited projects. Unlimited users. Always

With Continua you can organise and configure your projects in the way that makes the most sense to you, without worrying about running into limits. You can give access to as many users as you’d like, or even connect to Active Directory and give your whole organisation (or parts of it) access.

Unlimited build agents for paying customers

After you have purchased a concurrent build license you can create an unlimited number of build agents. Again, this allows you to configure your environment in a way that suits you and your build process.

Ok, I see now how it’s intended to work. Thanks.