This is the documentation for Bamboo 5.5. View this page for the

Unknown macro: {spacejump}

of Bamboo, or visit the latest Bamboo documentation.

Bamboo is a continuous integration (CI) server that can be used to automate the release management for a software application, creating a continuous delivery pipeline.

What does this mean?

CI is a software development methodology in which a build, unit tests and integration tests are performed, or triggered, whenever code is committed to the repository, to ensure that new changes integrate well into the existing code base. Integration builds provide early 'fail fast' feedback on the quality of new changes.

Release management describes the steps that are typically performed to release a software application, including building and functional testing, tagging releases, assigning versions, and deploying and activating the new version in production.

On this page:

Related Pages:

CI overview

What problem does Bamboo solve?

If you are a solo developer, then using Bamboo gives you:

  • an automated, and therefore reliable, build and test process, leaving you free to code more.
  • a way to manage builds that have different requirements or targets.
  • automatic deployment to a server, such as the App Store or Google Play.

If you work in a team, then as well as the above advantages, using Bamboo also means that:

  • your build and test process is not dependent on a specific local environment.
  • builds and integration tests are triggered automatically as soon as a developer commits code (continuous integration).

If you work on a large, complex application, then, in addition to all the above advantages, using Bamboo means that:

  • you can optimise build performance through parallelism.
  • you can leverage elastic resources.
  • you can deploy continuously, for example to user acceptance testing (UAT).
  • you can implement release management.

How does Bamboo do this?

  • Bamboo is the central management server which schedules and coordinates all work.

  • Bamboo itself has interfaces and plugins for lots of types of work.

  • Bamboo first gets your source from a source repository (lots of plugins here for a variety of systems).

  • Then Bamboo starts the build - that can be done by calling something like MSBuild to build your Visual Studio solution, or Maven to call your compiler and linker - whatever you use.
  • Once your solution or project is built, you have "artifacts" (build results, for example, an executable app, config files, etc.).
  • You can do additional things with the build artifacts:
    • zip them up into a ZIP file and copy them somewhere.
    • run an install builder on them and create an MSI.
    • install them on a test server to make sure everything installs just fine.
  • Bamboo provides a web front-end for configuration and for reporting the status of builds.

 

What does Bamboo need?

Bamboo schedules and coordinates the work involved in building and testing your application. Therefore, to use Bamboo, you will need to already have the following set up:

  • a code repository that contains the complete source code for the project.
  • build scripts
  • test suites

It is generally assumed that the person who commits a change to the code is responsible for fixing any resulting build errors immediately.

How is a Bamboo workflow organised?

Bamboo uses the concept of a 'plan' with 'jobs' and 'tasks' to configure and order the actions in the workflow.

Project
  • Has one, or more, plans.
  • Provides reporting (using the wallboard, for example) across all plans in the project.
  • Provides links to other applications.
Plan
  • Has a single stage, by default, but can be used to group jobs into multiple stages.
  • Processes a series of one or more stages that are run sequentially using the same repository.
  • Specifies the default repository.
  • Specifies how the build is triggered, and the triggering dependencies between the plan and other plans in the project.
  • Specifies notifications of build results.
  • Specifies who has permission to view and configure the plan and its jobs.
  • Provides for the definition of plan variables.
Stage
  • Has a single job, by default, but can be used to group multiple jobs.
  • Processes its jobs in parallel, on multiple agents (where available).
  • Must successfully complete all its jobs before the next stage in the plan can be processed.
  • May produce artifacts that can be made available for use by a subsequent stage.
Job
  • Processes a series of one or more tasks that are run sequentially on the same agent.
  • Controls the order in which tasks are performed.
  • Collects the requirements of individual tasks in the job, so that these requirements can be matched with agent capabilities.
  • Defines the artifacts that the build will produce.
  • Can only use artifacts produced in a previous stage.
  • Specifies any labels with which the build result or build artifacts will be tagged.
Task

  • Is a small discrete unit of work, such as source code checkout, executing a Maven goal, running a script, or parsing test results.
  • Is run sequentially within a job on a Bamboo working directory.

  • No labels

 

 

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.