Atlassian Bamboo in Pictures

    In this article I would like to share their experiences of using Atlassian the Bamboo - a continuous integration system from the company Atlassian . In the Java project we are working on, initially JIRA On Demand was used as a control system , i.e. cloud version of JIRA installed on Atlassian servers . At some point, there was a need to introduce a continuous integration system. An important requirement when choosing such a system was support from the box of the Gradle automatic assembly system . Only a few continuous integration systems met this requirement: the well-known Jenkins , Jetbrains TeamCity andAtlassian Bamboo . Under the cut out how it works and why we chose Atlassian Bamboo. Caution - a lot of pictures!

    Home page



    This is what the Bamboo homepage looks like, displaying a list of so-called build plans , i.e. independent sets of tasks that need to be performed at regular intervals either when certain conditions are met or when manually started. Each plan can use the same source code, but run at different intervals or deploy the application to different servers. For example, in our case, it was required to deploy the application daily to the test server in automatic mode and collect the source code intended for uploading to production, but not upload it. The main page displays a list of plans, their status and recent changes in the code. You can also start the plan manually or go to the settings page.


    On the “Current Activity” page, you can see a list of plans that are currently being executed and a list of previously launched plans.


    The My Bamboo page contains a list of plans that contain changes made by the current account. Since Bamboo On Demand uses the same account as for JIRA, a list of JIRA tickets assigned to the current user and a list of plans that contain changes related to these tickets are displayed. There is also a list of favorite plans.

    Plan page



    Each plan has its own page, which contains a summary table of previous launches of the plan (builds), as well as graphical data on the ratio of successful and unsuccessful builds.


    The build page contains information about the duration and success of the build and allows you to add comments.


    In addition, there is a list of JIRA tickets and commits included in the build. Clicking on the ticket opens the corresponding JIRA page, and on the commit - the commit page in Bitbucket (as it turns out, is owned by Atlassian and is well integrated with other online services). In our case, we are talking about Git commits, but other popular version control systems (Subversion, Mercurial) are also supported. From the same page you can download the full log file related to the build, or see statistics on passed automatic tests. If the build is currently running, the green panel is a scale that displays the current build progress, and the log file is updated in real time and displayed at the bottom of the page.


    On a separate page, files generated during the execution of the plan (the so-called artifacts ) are available for manual download . The JIRA On Demand version of Atlassian servers stores up to 1 GB of such files.

    Plan setting



    Setting up a plan is a series of pages that let you set a plan name ...


    ... a list of source code repositories used and settings for connecting to them ...


    ... a way to work with source code branches (branches). Bamboo has several useful features when working with branches. Firstly, you can collect not only the main branch (master), but also all other branches of the repository, whose names satisfy the given regular expression. For example, when using Git Flow, you can collect all branches containing feature /. This allows you to be more confident that changes made in feature branches will not break the build when injected into the main code. Secondly, automatic synchronization of changes between the master branch and feature branches is supported. Here it is possible to choose between two strategies: inject the successfully collected changes from the feature branch back into the master branch ( Gatekeeper ) or inject the changes from the master branch into the feature branch ( Branch Updater ). If the branch name contains the ticket name from JIRA, then such a branch will be automatically attached to this ticket for a quick transition.


    The Triggers page allows you to configure the conditions under which the plan is launched. For example, a build can be launched periodically at a given time and only if changes have been sent to the repository. You can run the build at the end of the commit using the post-commit hook mechanism, or just once a day, as many teams do.

    Bamboo plan consists of a set of stages ( stage ), each of which may contain one or more jobs ( job ), which in turn consist of tasks ( task) If one of the work ends with an error, you can restart only this work, and not the whole plan. In addition, work in one stage can be performed in parallel. For example, you can create three stages - the assembly ( the build ), testing ( testing ) and deployment ( deployment ). In each of these stages, several source code trees can be assembled, tested, and deployed on different servers.


    The set of built-in tasks is not very large, but it contains everything necessary for our needs. For example, you can build a project using Ant or Maven, run JUnit tests (or PHPUnit if you write in PHP), execute arbitrary shell scripts, deploy a war file for Tomcat or Heroku, add tags to the version control system, copy files using SSH and more.

    Admin panel



    The Bamboo Admin Panel has many options. I will not describe such standard options as managing user access rights or viewing log files. The most important setting in Bamboo On Demand, from my point of view, is setting up Amazon instances used to execute plans. The thing is that Atlassian does not provide the computing power of its data center for the assembly of your projects. Instead, Bamboo uses your Amazon Web Services API key to create virtual machine instances and run plans on those instances. In the admin panel, you can specify your data for working with the AWS API, the type and number of created instances, the used images of virtual machines (AMI) and the EBS volume. When you start a plan, Bamboo checks to see if an instance is already running, and if it is not there, it creates the required instance. By default, 300 seconds after the completion of the plan and in the absence of other tasks in the queue, the instance is turned off. When specifying the instance configuration, you need to take into account that Amazon On Demand pays for at least an hour of work, so in order to save money, it makes sense to think about choosing a less productive instance if it takes an hour to complete all plans. You can also use snapshots of EBS volumes to store a relatively recent version of the source code, as this will avoid a significant consumption of traffic when loading a complete source tree each time the plan is executed (in large Git projects, the repository can be hundreds of megabytes or even gigabytes in size). When specifying the instance configuration, you need to consider that Amazon On Demand pays for at least an hour of work, so in order to save money, it makes sense to think about choosing a less productive instance if it takes an hour to complete all the plans. You can also use snapshots of EBS volumes to store a relatively recent version of the source code, as this will avoid a significant consumption of traffic when loading a complete source tree each time the plan is executed (in large Git projects, the repository can be hundreds of megabytes or even gigabytes in size). When specifying the instance configuration, you need to consider that Amazon On Demand pays for at least an hour of work, so in order to save money, it makes sense to think about choosing a less productive instance if it takes an hour to complete all the plans. You can also use snapshots of EBS volumes to store a relatively recent version of the source code, as this will avoid a significant consumption of traffic when loading a complete source tree each time the plan is executed (in large Git projects, the repository can be hundreds of megabytes or even gigabytes in size). to keep a relatively fresh version of the source code, as this will avoid a significant consumption of traffic when loading a complete source tree each time the plan is executed (in large Git projects, the repository can be hundreds of megabytes or even gigabytes in size). to keep a relatively fresh version of the source code, as this will avoid a significant consumption of traffic when loading a complete source tree each time the plan is executed (in large Git projects, the repository can be hundreds of megabytes or even gigabytes in size).

    Integration with JIRA



    Atlassian Bamboo is well integrated with JIRA and other Atlassian services. If you specify the names of JIRA tickets in the commit descriptions, you can easily navigate between Bamboo and the pages of these tickets. In addition, the execution status of each plan is displayed in the JIRA (Activity Stream) status bar.

    Conclusion

    I do not think that Bamboo is significantly different in its capabilities from other popular continuous integration systems. However, it is very convenient to use with other Atlassian cloud services due to its good integration and consistent user interface. Bamboo can be used in the cloud or downloaded and installed on one of its servers. Pricing information can be found here (in short, starting at $ 10 per month or $ 10 for downloading and a license for 10 developers). For small projects, the cost and time to support Bamboo On Demand is much lower than the similar costs of deploying a continuous integration system on your own servers, and good integration with JIRA allows you to increase productivity, which is why we chose Bamboo for ourselves.

    Note
    If for some people the pictures seemed small in size, the full archive can be taken from the link .

    Also popular now: