Setting up plan - best practice?

[Rob Carr]

I am starting to get Bamboo running and have a question about plans. I am trying to determine the best way to structure a project, and I am not too sure how to create the plans. Here is my scenario.

We are planning on running multiple projects with Bamboo. Each will have a CI build and a Test Build. The distinction is the CI build will run every time the repository is updated, while the Test build will run once per day (at night). CI as you might guess is the continuous build we do, while test is designed for our QA team to test each day.

So initially I thought I would set Bamboo up as follows (assume project called Rocket):

Project: Rocket-CI

Plan 1: Compile

Plan 2: Run Unit Tests

Plan 3: Create Database

Project: Rocket-Test

Plan 1: Compile

Plan 2: Run Unit Tests

Plan 3: Create Database

When we create the database in rocket-test we would be inserting a lot more data to facilitate testing, while rocket-ci would have the bare minimum data.

I am wondering if it might be better to have 1 project only, as follows:

Project: Rocket

Plan 1: CI

Plan 2: Test

...with each plan having compile, unit test and create database steps. I am just not sure if doing it this way makes it harder to see what is going wrong if something fails?

Does anyone have any opinions on this?

Thanks guys!

Rob

[Przemek Bruski · Accepted solution]

Go for B. You want to share artifacts between your Compile/Run/Create phases, so you need to define them either as tasks or jobs in separate stages, which means you need to have them in a single plan.

Try setting them up and the solution will become clear.

[ReneR]

This sounds like 2 plans to me. Each with 1 Stage and 1 Job.

Where are you creating this "Database"? On a remote host or on the agent where you're running the build?

Stages, Jobs and Tasks are no substitute for a well articulated build in a script or some build tool: ant, maven, gradle, rake, etc...

Your 'actions': "Compile" "Run Unit Tests" would rely on the same changeset that was fetched from the repository. So they should be executed together.

Stages are more abstract, bigger. Example:

- Compile once, generate an artifact with all executable code in it, share it

- Run tests on Unix

- Run tests on Windows

- Run tests on Firefox

- Run tests on Chrome

- If all of these test succeed, then FTP some file to a target destination

If you're talking about a single set of tests from a single repository checkout then all of that is 1 Job.

[Dennis Ryan]

Here's a jira issue youi might like to vote for

[Rob Carr]

Okay thanks. That was what I was looking for. So something like this:

Project: Rocket

Plan 1: CI

- Stage1: Build

- Stage 2: Test

- Stage 3: Inspect

- Stage 4: Create DB

Plan 2: QA

- Stage1: Build

- Stage 2: Test

- Stage 3: Inspect

- Stage 4: Create DB

[Przemek Bruski]

Yeah, that looks about right. Try not to add stages if you don't need them (for example you may consider putting Build and Test into a single Job).

[Rob Carr]

Okay. Could I put all 4 steps into one stage?

[Przemek Bruski]

Yeah, I'd recommend that.

[Przemek Bruski]

Start off with a setup as simple as possible and see if you need anything more.

In general, stages are used as points where jobs executed in parallel have to complete before transitioning to the next stage. Another use case for stages is when you want to run part of your build and resume it manually later on. With the description you've given, you shouldn't really need Stages at this point.

[Rob Carr]

Sounds good. Do I lose anything by not having more than 1 stage? Is it easy to see which step in the stage failed?