• Google Play just hit 25 billion downloads in total (15 billion downloads in the last year)
• over 670,000 applications available on Google Play
• over 100’000 registered developers on Google Play
• over 500 million activations of Android devices, 1.3 million being added every day

Taking into account this rapidly increasing popularity we have decided to take one of our ShipIt prototypes, make some polishing and bug fixing and publish it as an alpha version of the…

Clover-for-Android Plugin for Eclipse!

It offers you an Eclipse IDE where:

• you can integrate your Android projects written in Java with Clover in just a few clicks,
• you can get code coverage from unit test execution as well as from manual tests - both from emulator and real devices,
• you can explore results and focus on most important code sections using Clover’s fantastic reports like Coverage Explorer, Test Run Explorer, Clover Dashboard, Cloud Map, Tree Map
• you can export HTML / XML / PDF reports.

Feel free to try it! We’re waiting for your feedback!

Learn More

This is a guest post from Alex Van Boxel, Software Engineer working at Alcatel-Lucent Antwerp. His pet interests within software are to keep the quality high, smooth running builds and the engineers productive. He believes having the complete Atlassian tool-chain certainly helps.

Finally we got it working… we wanted to know what our total test coverage was on our product with all the effort we did over the last year by adding new tests. It wasn’t easy because once you leave the path of simple unit testing you come in the terrain of multi-server setups. With multiple server it’s not easy anymore too collect all your metrics and get a descent report. But we pulled it off. So here’s our story.

We’re using the complete tool chain of Atlassian, so this story involves their tools. In this case Clover (the code coverage tool), Bamboo (Continues Integration server) and Maven (as out build tool). Let’s start with Clover. Clover is quite a clever coverage tool. It integrates in your build tool to create a special version of your product. It changes the source by injecting code to do the instrumentation. At the same time it will build a database with a collection of all the methods that are instrumented. With the special build of your product and the database it will collect metrics while your tests are running. So with a single Maven command line we had a complete coverage report of our unit tests.

But the tight integration with our build tool comes at a price. That price is not knowing what magic is going on behind the screen. And you need to know how everything fits together whenever you want to get more out of your tools. And that’s what we wanted… Let’s start at the beginning and start building our instrumented server.

Building the instrumented server

As I said, the Clover plugin for Maven does a lot a magic and after a normal Clover maven build you get a nice report of what the code coverage is of your unit tests. Getting this into Bamboo (our integration server) is easy. Start a source code checkout, do the clover maven build as you would on the commandline and publish the report as an artifact. Set this up first before you go any further. This will be the basis for our next phase and will already provide some usefull insights. Then it’s time to think about what we need if we want to get metrics on our server running on different machines. Lets have a look at the components.

Our instrumented product. Thats the easy part, your instrumented server will be located at the usual place in your maven project after a build. Just make sure that you don’t deploy this special version to your local or remote repository, so limit yourself to package (this still runs the unit tests).

This special build needs the clover.jar to be present on the application server. In our jboss server it’s enought that it’s present in the lib folder. Make sure to look at the server logs when you deploy your ears. If you find clover related NoSuchMethod exception the jar is in the wrong place.
Last thing we need to get on the server is the clover.db, without this database you will not get eny metrics.

The last component we need to worry about is how to get the instrumentation metrics in a consistent manner so we can get it easily from the remote server back to our Bamboo agent for later processing.

Looking at the list, the biggest problem is the clover.db, by default each maven module within a maven project has it’s own database. This would be a pain if we wanted to distribute those to a different server. Luckily we can force clover to build a single database by providing a path to the database. Although this had the strange effect that the report was generated in an unstable location (it’s actually the last module in the maven reactor). But you can force the report path as well. Here is an example of the modification in our parent pom:

<properties>

  <clover.version>3.1.0</clover.version>

  <clover.liclocation>/opt/clover.license</clover.liclocation>

  <clover.databasepath>/opt/work/clover/example</clover.databasepath>

  <clover.reportpath>${clover.databasePath}</clover.reportpath>

  <clover.enabled>false</clover.enabled>

</properties>

...

<build>

  <plugins>

    <plugin>

      <groupid>com.atlassian.maven.plugins</groupid>

      <artifactid>maven-clover2-plugin</artifactid>

      <version>${clover.version}</version>

      <configuration>

        <licenselocation>${clover.licLocation}</licenselocation>

        <cloverdatabase>${clover.dbPath}/db/clover.db</cloverdatabase>

        <historydir>${clover.dbPath}/history</historydir>

        <includetestsourceroots>false</includetestsourceroots>

        <excludes>

          <exclude>com\example\**\*</exclude>

        </excludes>

      </configuration>

    </plugin>

  </plugins>

</build>

...

<reporting>

  <plugins>

    <plugin>

      <groupid>com.atlassian.maven.plugins</groupid>

      <artifactid>maven-clover2-plugin</artifactid>

      <configuration>

        <licenselocation>${clover.licLocation}</licenselocation>

        <cloverdatabase>${clover.databasePath}/db/clover.db</cloverdatabase>

        <historydir>${clover.databasePath}/history</historydir>

        <outputdirectory>${clover.reportPath}/clover-report</outputdirectory>

        <excludes>

          <exclude>com\example\**\*</exclude>

        </excludes>

      </configuration>

    </plugin>

  </plugins>

</reporting>

The most importing thing to note here is the database path. This is a shared location we create that is available on each Bamboo agent. The user that the agents are running with need to have access to that location, so don’t forget to set the correct access rights. This location is outside of the normal Bamboo working directory because we’re going to manage it ourselves. It’s that working location that we are going to replicate on our test servers as well.

To create the first job of our master plan, we started out with our normal maven clover build. The build, with our adaptations, already produces the database, the instrumented server and the metrics of the unit test. Now we only need to add scripts to manage our central location. A cool feature of Bamboo is it’s task infrastructure. A job can comprise out of different tasks, as jobs can run in parallel, tasks will run sequential within a job. A lot of task types are provided or you write your own. One of the tasks that’s used here is the inline script task. Very useful for prototyping your CI build and you still can decide to later put the script in your source repository (Bamboo is able to do multiple source checkouts within one job) as the checkout is modeled as a task. Our pre-clover maven build prepares our shared location, basically cleaning up leftovers and recreating the structure we need.

Next task in our “Build Instrumented Server” job is running maven. Always start cleaning everything, followed by clover2:setup which will build the database and modify the source code. Then do a package, that will build the server, run the unit tests and output the metrics.  Finally the clover2:clover will generate the report of the unit test part.

The nice side effect off having the single clover db is that all the metrics are saved at that location as well. That makes it easy to create the post execute script. The script is another inline Bamboo task that removes the database and tar’s the data in a single file.

Finally we publish the clover database, instrumented ears and the metrics as a shared artifact that will be used in a later stage.

Running the integration tests

Stage two in our plan is running the different test suites. The different stages are jobs grouped together in a single stage. That makes it possible to run the tests concurrently on different agents. Building the job for the integration test can get a bit tricky. Not only are their 2 machines that come into play, now we need the use the instrumented server and the clover database as well.

As the clover.db and the instrumented server are published in the previous stage they are available to all the next stages. We only need to specify the artifacts we are interested in the location where we like to have them. When we got our artifacts we can use them in our task. Here is the list of tasks we have in one of our jobs:

1. Checkout the server. Needed for generating the scoped report after the run.
2. Checkout the test suite, in a sub-directory so it doesn’t conflict with the server.
3. Inline script to cleanup old data, create a mirror of our working directory on the remote server, install the instrumented server and the clover.db on the remote server.
4. Maven build that runs the integration run.
5. Inline script to get the metrics back from our remote server to our agents.
6. Maven build that uses the metric and our server source code checkout to generate a report (scope to these tests).
7. Script to remove the clover.db from our working directory and pack the metrics data in a tar (just like in our server build).

Quite a number of tasks. Lets show one of them in detail. The inline script we’re showing here is the script that prepares everything and sends everything to the remote server.

The rest of the scripts are trivial, just collect the data from the remote server and continue. Don’t forget to setup your remote server by adding the clover.jar to the libraries of your app server and add a VM parameter to tell clover where to find the database -Dclover.initstring.basedir = /opt/work/clover/example/db. The other test suites have similar setups, so we’re thinking about adding the scripts to a small git repo, so they can be reused in different jobs, with an extra checkout.

Creating the aggregated report

The final stage is not that difficult. In this stage we want to collect all the information collect throughout the previous stages. Again we use the artifacts shared by the previous stages, put them in the desired place and start a script to unpack them alongside the clover database. Because the metric data file names are always unique they will not clash with the files produced on the other machines. So we only need to place them in one place and start the maven clover report build again but now on all the metrics (unit-, api- and ui tests). Here’s a example of what the unpack script could look like:

Conclusion

Creating this plan took a while, but I think the information you can collect from the code coverage is worth the cost. With this information we can adapt our test plan to write extra tests for the code that’s not covered and we thought we did. A special thanks to Francois and Bert for dedicating some of their time to make this plan possible.

…And an extra-special thanks to Alex for sharing all this hard-earned knowledge!  Got a how-to blog post involving Atlassian dev tools that you’d like to share?  Drop a comment here or hit us up on Twitter at @AtlDevTools.  It’s all about community, baby!

Not using Bamboo? Learn about easy import from Jenkins

Image courtesy of NASA

NASA’s Jet Propulsion Laboratory (JPL) uses a host of Atlassian products to build the software used for flight mission planning as well as modeling data sent back from satellites and Mars rovers. I sat down with David Mittman, lead software developer and “default Atlassian guy” at JPL to get a closer look at what they’re up to.

JPL was founded in the 1930s as a place to test new rocket technologies, and—after the creation of NASA in 1958—was chartered with developing the robotic spacecraft needed to explore our solar system. These high-profile programs include the ongoing Voyager mission (which is currently traveling beyond our solar system), the Ulysses solar mission, and the Pathfinder rovers sent to Mars in the 1990s –and that’s just a tiny fraction. JPL also has an Earth-observing program for tracking weather and climate change using robotic observers in space. “We are constantly developing new technologies for exploring space,” says Mittman. Over the next hour, he backed that statement up with example after mind-boggling example.

A Truly “Ensemble” Cast

Developing part of the vast amount of software that allows humans on Earth to operate this panoply of unmanned explorers is a joint effort between JPL in Pasadena, CA, the Ames Research Center near San Francisco, and the Johnson Space Center in Houston. To make this all as efficient as possible (these are our tax dollars at work, after all…), they have created a project called Ensemble to solve the common problems they face such as mission planning, parsing the raw scientific data sent back, and compiling visual maps to represent an explorer’s traverse.

So Ensemble is all about collaboration across disparate geographical areas, which is what led them to the Atlassian ecosystem. “We need an infrastructure to let us develop it efficiently,” Mittman explains “and we’re using Atlassian products.” Their collection currently includes JIRA, GreenHopper, Confluence, Bamboo, FishEye and Clover –which are largely suitable for even JPL’s crazy-advanced purposes right out of the box. Notably absent from that list is Crucible. “We do a lot of pair programming, so code reviews are conducted up front…We may add it as collaboration between the three teams increases.” Fair enough.

Image courtesy of NASA/JPL-Caltech

At present, Ensemble’s biggest project is a Mars rover named “Curiosity,” launched in November 2011 and due to touch down on the red planet this August. Curiosity is an unmanned science lab which will use rock-evaporating lasers, camera/spectrometer hybrids, and high definition stereo cameras to investigate whether it’s landing region could (or did in the past) support microbial life. It will also help scientists understand the radiation environment on Mars in preparation for eventual human missions there, targeted within the next 10-15 years.

As with the Spirit and Opportunity rovers currently calling Mars home, data collected by Curiosity will be sent back to Earth once a day, around the time of the Martian sunset. (Being solar-powered, the rovers are field geologists by day, and happy slumberers by night.) Using Ensemble and a transient, cloud-like computing hive of “about a thousand CPUs,” Curiosity’s operators will crunch through the day’s data, and within a few hours, send up it’s task list for the next day. Now THAT’s agile planning!

Behind the scenes, Bamboo is powering a continuous deployment pipeline that makes the whole works even more agile by delivering software updates to their private cloud as fast as the Ensemble engineers can crank them out. Code from six active branches is built using custom scripts that sit on top of Eclipse and SVN, and invoked by Bamboo. Each successful build is then deployed to, and rigorously tested on, two preliminary environments before going into operation. (Just imagine bragging to your friends that the code you wrote today will be driving rovers on Mars tomorrow! That ain’t science fiction, baby; it’s science fact.) Mittman & team are also moving toward a continuous deploy model for sharing their work with other developers building operational software for the International Space Station.

Ensemble’s Upcoming Performance

Image courtesy of NASA

What’s next for the Ensemble team? Oh not much…only “the first Eclipse RCP-based application to run on the International Space Station,” says Mittman. (!) Using OSGi to pull various components into a single application, this application will operate a SPHERES (Synchronized Position Hold Engage and Reorient Experimental Satellites) robot, as part of NASA’s Human Exploration Telerobotics project. Ensemble’s role will be to command and monitor a SPHERES free-flying robot equipped with an Android “Nexus S” smartphone for data processing. Another project in their pipeline will also be used on the ISS, this time to demonstrate how a human up in the space station can control a robot down on a planetary or lunar surface.

Space robots? Check. Groundbreaking technologies? Check. All in a days work for the guys n’ gals of Ensemble. We at Atlassian are honored and humbled that our tools are supporting this intrepid crew of computer scientists. Preparing for awesomeness in T-minus 5… 4… 3… 2… 1!

For more information on these far-out applications of computer code, check the sites below:

• NASA’s Mars program http://marsprogram.jpl.nasa.gov/msl/
• Curiosity rover: http://msl-scicorner.jpl.nasa.gov/
• MSLICE tech Brief: http://www.techbriefs.com/component/content/article/5707
• Cloud computing at JPL: http://aws.amazon.com/solutions/case-studies/nasa-jpl/
• SPHERES robots: http://ssl.mit.edu/spheres/

 Special thanks to David for taking time out of his day to share these rare insights with us!

Setting some Goals

The FishEye and Crucible team had a few goals for the migration to Mercurial.

• Bring our history with us. The team wanted the Mercurial repository to resemble it’s Subversion counterpart as much as possible. We wanted to have the all the history contributing to our development branch (trunk) as well as our two supported release branches (2.2 and 2.3 at the time). Other branches such as ShipIt branches and 20% time were less important but ideally converted as well. We were happy to exclude accidental commits and commits of large files from the conversion.
• Tool Integration. We wanted to make sure the tools and software that we used for development provided the same level of integration with Mercurial as they do for Subversion. These were mainly FishEye, Crucible, Bamboo, Eclipse and Intellij IDEA.
• Incremental. The conversion should be performed incrementally. This was incredibly important in order to ensure that the history was how we expected it, system integration worked and everyone could perform their development tasks without running into problems due to Mercurial. This was also important in minimising the disruptions that would occur for developers.
• Replicate team process. At least initially, we wanted to replicate the current Subversion development workflow using Mercurial. We were happy the experiment with other workflows which aren’t possible in subversion after the initial migration.

The right tool for the job

Mercurial comes bundled with the command hg convert. This can be used to migrate many different types of SCM repositories to a Mercurial, including Subversion. We followed the helpful guide that is provided on the website. At first it looked quite promising. The conversion didn’t produce any errors. But as we started to to look at the resulting Mercurial repository some things just didn’t look right.

We decided to do a script based comparison of the Mercurial and Subversion heads of each branch and tag. We found that many tags and branches were very different and on top of this, Mercurial’s incremental conversions of new commits were taking at least 3 minutes. This was far from acceptable as we were used to committed changesets being available almost instantly in FishEye/Crucible.

We spoke to a few members of the Bitbucket team and they suggested that we give hgsubversion a try. The conversion using this tool was far more accurate and was faster at doing incremental conversions.

Converting using hgsubversion

Step 1: Create an SVN mirror

Regardless of the tool you decide to use for the conversion the first thing you should do is to set up a local mirror of your Subversion repository. The conversion tools will make numerous calls to repository for data and you will most likely perform more than one conversion.

The initial synchronisation will take a while and is dependent on the size of your project as well as the size of your repository. For example the FishEye team checks in jar dependencies. This meant that every version of those jars over time needed to be synchronised. Also if there are multiple projects in your SVN repository, the synchronisation needs to go through all the revisions which includes revisions which weren’t made by your project. These are later ignored by the conversion process but are still important in the Subversion repository. FishEye/Crucible repository took a few days for the initial sync.

Step 2: Create author mappings

Mercurial (as well as most DVCS products) has a different standard for author names than Subversion. In Subversion author names are controlled centrally and their structure is dictated by the administrator for that repository. DVCS does not enforce such restrictions (due to people being able to commit to their local repository) so a recommended standard was used Full Name <Email address>. For example: John Doe<jdoe@example.com>. To get a list of all authors in your repository execute the following:

Both hgsubversion and hg convert use a file to map between the subversion author name and the new Mercurial author name. The file uses the following pattern:

hgsubversion also provides a default host for repositories where the author in subversion maps directly to an email address in with the same user portion.

Step 3: Create an initial Mercurial conversion

Provided you have hgsubversion installed and on your PYTHONPATH, you should be able to convert the subversion repository. You have to make sure you include the path to the project in the mirrored repository url as well.

The initial conversion to Mercurial for FishEye/Crucible took a few hours, but other projects in Atlassian only took a few minutes.

Step 4: Sanitising the Conversion

In the history of most projects, someone always ends up screwing up a repositories history. Copying the wrong directory to the wrong location, adding massive log files or binaries into the repository. The list goes on. These mistakes you don’t necessarily want in your new repository, so you might want to exclude them from the history. We do this through creating a file mapping file. It looks something like this:

You can choose to include or exclude certain paths. In the above instances, we’re not excluding the trunk, we are excluding a time when someone copied the trunk directory into a branch directory instead of the contents of trunk contents. Another example from above is when someone committed the clover results from our bamboo server into the repository. These consumed a lot of space and weren’t needed. If you don’t want to look through your entire history, you can look into Mercurial’s internal data storage and see potential files for exclusion. The following command will list the files in descending size order:

Which will look something like this:

Step 5: Creating a Working repository

Now that we have a user mapping file and an file mapping file, we clone the subversion repository again:

This can be considered the full conversion. You may just want to use this repository, but the FishEye/Crucible team found that this repository:

1. Contained many branches that we were not interested in for day to day development
2. Contained conversions of complex tags which created large revisions which weren’t part of the mainline development
3. Was large. The full conversion for the FishEye/Crucible repository was 2Gb. This is because we commit jar files to our repository which take up a lot of space. Other repositories converted to Mercurial weren’t nearly as big.

We decided to create a working repository with a subset of the branches.

Step 5a: Excluding unrelated and irrelevant branches

Subversion does not model branches in a repository as a first class entity, but rather as a subdirectory. This means that branches can easily be created incorrectly and the converter sometimes is not able to correctly identify the branch. As a result you sometimes end up with multiple, unrelated histories in your repository. There were no occurrences of these during the conversion of the FishEye/Crucible repository but there were definitely branches we didn’t care about having in our working repository. We decided to keep three branches; Our main development branch (default) and the two most recent support branches (2.2 and 2.3).

Step 5b: Closing non-topological heads (optional)

Additional heads revisions on branches are sometimes created during the conversion process. A good example of when this would happen is when someone creates a branch from a tag of a project. Mercurial has the ability to mark these heads as closed. To get a list of these heads we compare the list of most recent commits on all branches to the list of all heads:

To close these heads we first update to them then commit using the

flag

Step 6: Rinse and repeat

In order to do this incrementally, you will need to first synchronise the subversion mirror again:

Then pull the latest changes into the full conversion.

You may need to close any newly created heads, which can happen happen under the conditions mentioned in step 5b but this is unlikely. Finally pull any changes made on the important branches into the working repository.

For the FishEye/Crucible migration, we used a shell script to automate this process which ran every minute.

All systems are go

In addition to converting the repository to Mercurial we also needed to set up our development environments for Mercurial development. The default Mercurial distribution for Mac OS X was used for mac users and either Machg or SourceTree for GUI clients. Tortoisehg was used for Windows which bundles the Mercurial command line tool as well as a GUI. We use Eclipse and Intellij IDEA for development. MercurialEclipse works well and is the defacto standard for Mercurial integration for Eclipse. IDEA X supports Mercurial through their hg4idea plugin. Using the combination of these tools we saw little to no difference in the tool usage. Many operations are actually faster due to them interacting with a local repository as oppose to over a network connection.

Integrating with our products was fairly straight forward. In FishEye/Crucible 2.5 and Bamboo 2.7+ you can add a Mercurial repository using ssh which works well with Bitbucket. However to minimise the amount of data being sent over the internet we set up clone of the repository inside the network our Bamboo and FishEye servers are. We were able to look at diff, annotations, build results and see if they were consistent with each other.Prior to the move, all the developers took a bit of time to clone the repository and set up their development environment in order to make the sure it all works as they expect.

On the actual day that we moved over, it was very little difference in the routine due to all the preparation before the conversion. The only difference was that in the morning, everyone pulled in the most recent changes from the central Mercurial repository. After that it was business as usual. No development speed was lost which was a huge win for the FishEye/Crucible. A big thanks to Matt Watson for converting the repository, preparing the team for the migration as well as supplying a lot of the information in this blog.

What’s Next

In my next post, I’ll be talking about how the FishEye & Crucible team reacted to the switch to Mercurial. What was different? What did we learn? Stay tuned.

Where to next?

• Get all the details on Bamboo 3.0 and the Release Management plugin
• Read about how continuous deployment has helped our team build and test software
• Download a free 30-day eval of Bamboo 3.0

ATLASSIAN ANNOUNCES THE RELEASE OF BAMBOO 3.0 AND ACQUISITION OF THE SYSBLISS RELEASE MANAGEMENT PLUGIN

Bamboo’s new continuous deployment, release management capabilities help automate your product development lifecycle.

San Francisco, CA (PRWEB) February 16, 2011 – Atlassian today announced the release of Bamboo 3.0, its continuous integration server software, introducing features to improve build speed and effectively implement continuous deployment into the build process for agile teams. Bamboo 3.0 also includes support for Git and Mercurial DVCS, a fresh UI, a new artifact sharing feature, tighter integration with JIRA, and dozens of new features, updates, and bug fixes.

In addition, Atlassian is announcing that it has acquired two plugins from Sysbliss: Bamboo Release Management and JIRA Workflow Designer. In July 2010, Atlassian announced it had received a $60M round of funding from Accel Partners to accelerate growth, including new M&A. The acquisition of these plugins follows the acquisition of Bitbucket.org in September 2010.

“Bamboo has come a long way in providing some of the most powerful features in any CI server,” said Mike Cannon-Brookes, Atlassian CEO and co-founder. “In version 1.0, we introduced the concept of “build telemetry,” a feature that provided terrific metrics around software builds. In 2.0, we announced infinite scalability via distributed builds in Amazon EC2. In this version, we offer continuous deployment which gives teams greater confidence and speed in software production.”

From CI to CD

Atlassian Bamboo is a powerful continuous integration (CI) server that allows users to automate their build process and kick off software testing. As a result, agile development teams can shave off precious hours from their software development time, identify problems early, and gain new insights into their development practices. Bamboo was the first CI tool to leverage Amazon’s EC2 to effortlessly scaling large builds in the cloud. Agile teams have learned to “test early, test often,” and continuous integration servers enabled them to automate this painful task. But there was still one painful step left when building software… deploying it.

This latest edition provides features focused on continuous deployment. Bamboo 3.0 provides the structure and tools that are required to automate the deployment and release process. Bamboo allows teams to map their complete deployment process, starting with building the software to deploying software into a testing or even production environment.

DVCS

Bamboo now has support for the two most popular DVCS tools in the market. Git and Mercurial are supported out of the box, and Bamboo makes it easy to test a project, whether it’s hosted behind a company’s firewall, on Bitbucket or on GitHub.

Release Management

Available for free today to Bamboo customers, the Release Management plugin allows users to run a release build, publish the artifacts, tag the version in SCM, release the version in JIRA, create a branch for the next version in SCM, switch the build to use the new branch… all with a single click of a button. Jonathan Doklovic, the developer and founder of Sysbliss, has joined Atlassian and will continue development on both the Bamboo Release Management and JIRA Workflow Designer plugins.

Continuous expansion

Over 1200 customers in 53 countries use Bamboo. In addition to the latest features, Bamboo features tight integration with JIRA, the world’s most popular issue tracker, as well as Atlassian FishEye, Crucible, and Clover. For a free 30-day evaluation or Bamboo and the Release Management plugin, visit www.atlassian.com/bamboo.

About Atlassian

Atlassian provides software development and collaboration tools to help teams conceive, plan, build and launch great products. More than 22,000 organisations of all sizes use Atlassian’s issue tracking, collaboration and agile software development tools to work smarter and deliver quality results on time. Learn more at http://www.atlassian.com

JIRA and GreenHopper State of the Union Video

My colleagues, Ken Olofsen and Edwin Wong, have already done a much better job than I could ever hope to at summarizing all things JIRA and GreenHopper. So sit back and enjoy the fruits of their labor!
The first 45 minutes of the video are JIRA and GreenHopper; after that it’s the dev tools (FishEye, Crucible, Clover, Crowd, Bamboo) state of the union and Q&A for the whole session. I encourage you to check out the whole thing – and if you’re hungry for more, check out all the videos at our Summit 2010 mini-site.
If you’re not convinced yet, here’s just a few of the topics covered in the video:

• JIRA Release Time – How did we go from 10-13 month release cycles to 4-6? And why are we shooting for 3-4?
• JIRA’s UX Journey – Starting with JIRA 4.0 we started work on a revamped user experience. Why the change, and where does this journey lead?
• JIRA 4.2 New Features – The next release of JIRA is right around the corner — learn about the new features, including expanded keyboard shortcuts and other time-saving features targeting advanced JIRA users.
• GreenHopper 5 New Features – If you haven’t already checked out the freshly-released GreenHopper 5, you’ll learn about the multitude of new features and revamped UX in this video.
• What’s Next for GreenHopper – GreenHopper 5 was a big one…but there’s still more to do. Adding keyboard shortcut functionality to GreenHopper is just one of many ideas on the table.

The Atlassian Bamboo team is excited to announce the release of Bamboo 2.6. The focus of this release is scaling your Continuous Integration (CI) effort – more plans, more builds.

100 remote agents

We have improved Bamboo’s scalability so you can now build more plans simultaneously on up to 100 remote agents. Previously Bamboo only supported up to 25 remote agents.
With this dramatic increase in remote agents we also made some changes to the user interface to make it easier to manage your builds:

• Administration console - builders and JDKs are now grouped by their labels.
• Drag and drop - re-order builds in the queue with the ease of drag and drop.
• Remote agents tabs - online and offline remote agents are now separate tabs.
• Tooltips - improved tooltips on agents when specifying the capability requirements of a plan.

Dynamic Elastic Agents

Run Bamboo in the Amazon Elastic Compute Cloud (EC2) with more control by automatically managing the usage of the elastic instances. There are several flexible options which can be customized to your choosing:

• Default – balance the queue clearance rates.
• Aggressive – increase build queue clearance rates but with higher elastic instance usage (higher costs).
• Passive - decrease elastic instance usage but with lower build queue clearance rates (lower costs).

Automated Grails and Clover integration

Bamboo now offers continuous integration capabilities for Grails developers for their Groovy code.
Also, Java and Groovy development teams using Clover, our code coverage and test optimization tool, can already integrate with Bamboo build plans with Clover through one-click integration. We now offer one-click code coverage to Grails developers for there Groovy code. Easily run clover reports for Groovy directly from Bamboo.

Revamped Bamboo Dashboard

The “Current Activity” tab on the Bamboo Dashboard has be redesigned to include “better” activity streams and easier ways to manage builds.
The “Recent Activity” section, which shows activity streams of your build activity, now shows build comments on the dashboard. Hover over any build result and click on the comment “bubble” to provide an inline comment directly from the dashboard.
Administrators now have the option of using the “Queue” section to re-order their builds with the ease of drag-and-drop.
Also, the “Building” section now provide more information about the current builds that are running including an estimate of time remaining.

Over 140 improvements and fixes

• Performance

• 
User interface

• Security

Read the full release notes for Bamboo 2.6 or download now.

Deep Dive

Over the next couple of weeks, we will be doing a deep dive on some of the new features in Bamboo 2.6, so subscribe to the Developer Tools Product Blog, if you are not already, and stay tuned!

Get it today

Download Bamboo 2.6 to upgrade or get started with a free 30-day trial.

To shed some light on the vast number of webinars and topics we have covered in the past year and a half, I wanted to share the glorious list, in its entirety:

Voice of the Customer

Plugin of the Month

All webinars are posted to Atlassian TV where you can sort videos by products and categories. For upcoming webinars, please visit our events page. If you would like to be in our webinar series, please contact us.

• JIRA blog RSS
• Confluence blog RSS
• Dev Tools blog RSS
• News blog RSS
• Developers blog RSS
• All blogs RSS

Want to display your Bamboo plan summary on your JIRA dashboard? Or your FishEye charts on a Confluence page? The big list tells you how. There are gadgets that show information from Confluence, JIRA, GreenHopper, Bamboo, FishEye, Crucible and Clover. I’ve just counted – there are 35 gadgets on the list!

Are you wondering what the picture on the left has to do with gadgets? Nothing at all, except that it’s pretty. I took the photograph in the Manly Dam Reserve, somewhere near this big green arrow. It was early morning, soon after a summer rainstorm. The fierce Ozzie sun had found this twig but had not yet burned off the raindrops.