When and how to use multiple configurations and stages

I was just wondering if there were some more advanced tutorials / help topics available that describe use cases for when you would create multiple configurations vs. multiple stages vs. just simply having multiple actions.

I have set up a basic project, with a single configuration and stage that builds based on a repo trigger, and I got this working.  Now I’m looking to see how it might be possible to divide up our build into different components, where one component might be dependent on several others.  I was thinking that we could then build only the components for which source code has changed in order to save build time.  To do this, I have tried setting up a second configuration but cannot get it to work because there is a separate workspace from the first configuration.  I was hoping to be able to use the binaries built from the first config to speed up building the second one.  Is this possible?  Or am I misunderstanding what a config is for? Should I be using separate build stages instead?

I’ve found plenty of help describing how to create configurations, build stages, and stage gates, but, so far, I haven’t seen anything describing what they should be used for.  Some examples / use cases would be great!

Thanks,

Jesse

Hi Jesse

Using multiple stages is really about splitting up the build process, or where you have differing requirements that are met by different agents. So for example, when we build Continua CI, we have the following stages :

Build - builds the source, can run on any agent
Obfuscate - obfuscates parts of the product, only runs on one agent as the tool we use is expensive
Test - runs the unit tests, runs on any agent.
Package - creates the installers
Deploy - uses finalbuilder to upload the installers to the website.

The Obfuscate stage has an agent requirement set for the obfuscation tool, which is only met by the single agent where that is installed.

As far as splitting up the build to only build components that have changes, what you are looking for is dependencies, which unfortunately are not implemented in Continua just yet. It is a feature we are working on, so you will be able to create a configuration for components, and then have other configurations depend on the output of those component configurations (ie, take the binaries produced by them). I don’t have a timeframe I can share for this feature but it is the top priority for the team.

Ok, thanks for the clarification.  We definitely could use the up and coming dependent configuration feature.

Regarding the build stages:

We currently use FinalBuilder + FB Server, so at first I was thinking that the stages were nothing more than FB Action Group equivalents.  However, judging by your explanation, it sounds like you can instruct some agents to skip certain stages while others might run all of them?

Posted By Jesse on 27 Mar 2014 07:22 AM
Ok, thanks for the clarification.  We definitely could use the up and coming dependent configuration feature.

Regarding the build stages:

We currently use FinalBuilder + FB Server, so at first I was thinking that the stages were nothing more than FB Action Group equivalents.  However, judging by your explanation, it sounds like you can instruct some agents to skip certain stages while others might run all of them?


Hi Jesse

Apologies for the delay in replying, I missed your reply before. Stages are like Action Lists in FinalBuilder, except that they cannot be called directly, they execute one after the other.

Only 1 agent at a time will run a stage. The server selects an agent  to run a stage based on what the stage requires and the capabilities of the agent, when that stage is done (and assuming it succeeds) the server will select and agent for the next stage and so on... There is an automatically promote option which is on by default, which determines if the build continues on to the next stage or it stops and requires user intervention to continue. If you turn that option off, you can specify conditions that control whether to automatically promote the build to the next stage.

In an upcoming update, there are conditions that can control if a stage is skipped altogether (similar to the promote conditions).