What We Need From You

1. Download your favorite distribution. Along the way you’ll be asked for your email address. This tell us how many people are actually participating vs. how many indicated interest, which helps us plan for future beta programs, and ensures we have an open line of communication with each participant.
2. Learn about the benefits that Deployment Projects, the foundation of Bamboo 5.0′s new deployment capabilities, have to offer your team.
3. Install Bamboo 5.0 and start exploring! You can set up a test instance and import a copy of your Bamboo data (If you need a new license, you can get a evaluation license from my.atlassian.com). We’re especially interested in the setup process, so if you remember to note how that goes for you, we’d love to hear about it.
4. Look for an initial survey from us about 1-2 days after you download and install–should take five minutes or less.
5. As you’re using the beta, relay your thoughts about things you like or dislike by clicking the “Feedback for Bamboo 5 Beta” button, found at the top of each page.
6. Look for a second survey after you’ve been using the beta for about a week. Again, shouldn’t take more than a few minutes.

What We’ll Provide in Return

1. Participants who step through both surveys will get a nerd-tastic Bamboo t-shirt.
2. Our product owner and user-experience specialist will follow up personally with as many participants as possible to dig deeper into the aspects of Bamboo 5 that you don’t love (yet).
3. The development team will prioritize their work between now and release time based on your feedback.
4. A final release of Bamboo 5 that is tailored for our users, by our users.
5. Our eternal gratitude n’ stuff 

Ready… Steady… DEPLOY!

We’re excited to usher in a whole new era of build & deploy orchestration with Bamboo 5, and can’t wait to hear from you!

Download the beta

The Problem

I hate it when I make a trivial change, something like:

Then a few minutes later.. *BOOM*

What the heck? How did changing the capitalization of a letter break the database migration tests?

Hmm.. maybe they’re flakey. Let’s re-run the build. *BOOM*

Arggh!

Oh wait. Of course. I know what heinous crime I’ve committed!

Little did I know, one of my co-workers had broken master at some point in the past. My crime: branching from their broken commit. A simple merge from master at this point (providing it’s green) will remedy the situation, even if it does make the history a bit uglier.

Wouldn’t it be nice if we could avoid this whole situation altogether?

The Solution

What if git warned you when you switched to a dodgy ref? Something like:

Then you could easily switch back to a better ref for your branch point, or slap the build breaker until they fix it.

I’ve built a little client-side git hook that does exactly that. It will work work for any git repository built by Bamboo or hosted by Stash, and is super easy to install.

Just run this command from the root of your local clone:

You’ll be prompted for the url and credentials of either:

• the Bamboo server that builds your repository; or
• the Stash server that hosts your repository (if you’ve set up your CI server to notify Stash of build results).

It works by registering a post-checkout hook that hits a little known REST end-point in Bamboo that provides all build results for a particular SHA.

The project is up on Bitbucket and I’m very open to pull requests.

Well friends, Christmas is coming early this year. In early May we’ll kick off the Bamboo 5 Early Access Program (ie, a beta). Milestone builds will be available for download in all the distribution forms you know & love, and you won’t need a special password to get them. If you’re a current customer, no changes to your license is needed to take Bamboo 5 for a spin. If you haven’t yet tried Bamboo, an evaluation license can also be used for the EAP.

We’ll make an announcement here on the Bamboo blog as soon as we’ve got the first build ready for public consumption, and will make additional builds available as we get closer to the official Bamboo 5 launch date. If you’d like to be notified as soon as a new builds touch down and receive notes on each milestone from the dev team, drop us your email address.

Send me the updates!

*If not… can I tempt you with uber-flexible deploy workflows? Per-environment deploy permissions? How ’bout a quick way to find out where your bug fix is living?

And so what?

If you’re lucky enough to never have branched from a bad commit, let me share with you how ugly it can be. You have worked on this new feature, the code has been reviewed and you are ready to push it to master for the world to see, but you see on Stash that the builds are red on your branch. You start checking the builds wondering how your change could have broken all these tests. After a while you realize these tests were broken on master when you branched, but since master is green now everything should be ok. You push your change and move on. After a while build wallboards start getting red all over the office with your face on it. You did break some tests after all… But all that pain can be avoided if you take care to branch from a good commit in the first place.

Scenarios:

On the Confluence team, we don’t have a 1:1 mapping between commits and builds. So given that, the results need to be analysed a bit.

• Commit with failed builds : obviously you don’t want to branch from there
  • This doesn’t mean that this particular commit broke the build. It could be caused by a previous commit build in the same time.
• Commit with green builds 
  • The more CI builds are exercising that commit, and the more of them that are green, the more reliable the commit is.
  • For the Confluence team, 5 builds passed means all “A1. Master Baseline” builds passed, and you can branch

Thanks to the Stash-Bamboo plugin we can start your branch on the right foot, but it’s pretty much useless if you forget to check the build status before branching. One way to fix this problem for good is to use Bamboo Gatekeeper, letting Bamboo push branch changes to master once the tests are green. Or you could put a sticky note on your monitor to remind you… but I don’t recommend it.

Get the Stash-Bamboo Plugin

That’s right, kids! An app for iPhone and Android that lets you keep tabs on your Bamboo builds no matter where you are. Here to tell us about it is the project’s development lead: Matthew Burnett from Addteq, an Atlassian Expert partner. Take it away, Matthew!…

Matthew graduated from the University of Tennessee with a B.S. in Computer Science. While in school, he studied various topics but fell in love with mobile development in one of his final classes. He joined Addteq shortly after graduating and has since been involved in several mobile application projects. He is currently leading the Mobile Development team as they venture into iOSdevelopment and the team’s first iOS application. In his free time, he enjoys watching college football and basketball and, when his wife allows, playing PS3.

Today we are lucky enough to have a guest blogger! Himanshu Chhetri is a developer at Addteq and works with the Configuration Management and Atlassian Solutions delivery teams. In his free time he likes to keep up-to date with the latest open source projects and the devops movement.

Most developers use Eclipse as their IDE of choice for Android development. Google provides the ADT (Android Developer Tools) plugin for Eclipse that simplifies the process of setting up new Android projects and going about development.

However, when setting up Continuous Integration for Android projects, we would need to build outside the IDE. The Android SDK is bundled with various command line tools to help us build Android projects. Ant is one tool which lets us compile and build the project into an installable .apk file.

The process of building Android apps using Ant is best illustrated by the description in the official documentation:

There are two ways to build your application using the Ant build script: one for testing/debugging your application — debug mode — and one for building your final package for release — release mode. Regardless of which way you build your application, it must be signed before it can install on an emulator or device—with a debug key when building in debug mode and with your own private key when building in release mode.

When it comes to Continuous Integration tools we prefer to use Atlassian Bamboo because it goes beyond build automation and has amazing features ranging from numerous built-in and third party tasks to seamless integration with Atlassian JIRA allowing users to assign issues right from the build result page. Also, Addteq is an Atlassian partner and we practice what we preach when it comes to developer tools!

For an Android project that we are working on, we wanted to setup Bamboo to provide the developers rapid feedback about any changes happening in the project. With Android SDK’s built-in support for Ant and Bamboo’s ease of use, we were able to quickly setup a build pipeline by following the anatomy of a typical Bamboo build.

We have a build stage that consists of  tasks to get the latest changes to the project’s Git repository (Which is managed using Atlassian Stash but we will save the details for a future blog post!), execute the Ant script via the Bamboo Ant task to compile the source code and create the APK package as well as generate the API documentation in HTML using Javadoc. To generate the javadoc we added a target to the build script and utilized Ant’s javadoc task. The build script also copies the generated javadocs to Apache web server’s default Document Root so that developers can access it from http://bamboo-host/javadocs

We have a second stage that runs various kinds of static code analysis tools for Java: Checkstyle and PMD.

We also utilize Bamboo’s feature of  running parallel jobs within a stage.

Bamboo also allows for sending of immediate feedback of the build results via email notifications to developers. Another useful feature is assigning responsibility for build failures. Also, if you are using Stash you have the option to view Bamboo build results for a commit or pull request which is very useful.

Want to know more?

At Addteq we are official experts in Atlassian tools and highly competent in the arena of software configuration management. We’d love to help you answer any questions you may have. You can learn more about who are and what we do by visiting us at www.addteq.com.

Haven’t tried Bamboo yet? Learn about easy build import from Jenkins!

Apologies in advance, but… I’m gonna be “that someone”. Replace New Year’s Eve with every Monday through Friday. The bar you just walked into is JUnit. That other bar you should, like, totally make a b-line for is TestNG - an open-source automated testing framework.

Now, where this analogy breaks down (assuming it ever had legs to begin with), is that unlike the human confines of singular spacio-temporal existence™, you can use both JUnit and TestNG at once. Here are 3 reasons you should.

Groups

This is hands-down my favorite thing about TestNG because it’s the most flexible way to split your tests into sub-suites. Let’s jump right to a Bamboo-inspired example. Here we see two tests around ordering Tasks within a Job:

Each test has been assigned to groups representing functional area of the application, level of technology stack, maturity level, and whether it should be run as a post-deploy smoke test. This is incredibly powerful because you can use these assignments at run time to pull tests from disparate classes or packages and run them inside a single job. A job that runs all the API-level tests having to do with configuration functionality, for example. Or a job that runs all the tests for features that are still in development and not really expected to pass yet (TDD, anyone??).

And you guessed it: the logical next step is to create jobs that cover the fully body of tests you wish to execute, and run those jobs in parallel inside a stage. Check out this post for more implementation details.

@DataProvider

Let’s say you’re developing, oh I dunno… a continuous integration server. Let’s also say that your CI server needs to support switching between branches from build to build. There are loads of permutations you want to test, but you’re verifying the same functionality for each of them.

What’s a dev to do? Duplicate the hell outta their test code, making explicit sets of tests for each repo type/branch type combination? Oh, the humanity! But wait: up there in the sky! It’s a bird… no, it’s a plane… no! it’s @DataProvider! Here’s a simple example from TestNG’s site:

The output of that test will be:

But wait. Junit supports parameterized tests as of v.4.4, which is essentially what this is. So why bother with TestNG? First, TestNG’s implementation is slicker and easier than JUnit’s. Second, and more importantly, the reporting in TestNG is much clearer. TestNG tells you exactly which inputs were used for each execution, making it much easier to diagnose failures. JUnit just tells you which array the parameters came from, and their positions therein – clear as mud.

Skipped Tests

Adherents to the D.R.Y principal (and that’s most of us) rely on @BeforeTest or @BeforeClass set-up methods. But if something goes awry in set-up, there’s no point in trying to run the actual test. We know it just gonna fail. With TestNG, the default behavior is to simply skip a test if its upstream dependency barfs. I love this for two reasons.

First, executing the actual test is a waste of time and just means you wait that much longer to find out this revision of your code no es bueno. Second, when you look at your test results, your count of skipped tests makes it immediately clear that something fundamental to your application is borked. Much faster than diving into 350 test failures and, somewhere around number 20, noticing that they’ve all failed on exactly the same call.

And it’s not just set-up methods that can trigger a skip. If you’ve declared TestA as being dependent upon TestB, and TestA fails, TestB will be skipped. Here’s what that looks like in your build logs:

Two Can Play at This Game…

Incorporating TestNG into your arsenal is easy, and again: you can use it in concert with JUnit. Add it as a dependency in your Maven POM, or as an Ant task. Then get the TestNG plugin for Eclipse or IDEA and start sprucing up your tests. Visit testng.org for details.

Among the goodies in Bamboo’s latest release is native support for parsing TestNG results - @DataProvider, skipped tests… the whole works. Just add the TestNG Parser as a final task in the jobs that execute tests. If you’re running the tests by way of Maven, Ant or Gradle, be sure to disable test reporting in those tasks so there are no conflicts.

For more test automation tips and best practices, be sure to check out our new resources page with all sorts of helpful info. Even automation gurus are sure to find at least one new idea!

Haven’t tried Bamboo? Learn about easy build import from Jenkins!

Jenkins is great. With its $0 price point, Jenkins has helped spread the gospel of continuous integration far n’ wide. And CI is freeing us from the shackles of waterfall-style development, and ratcheting up the rigor of quality assurance – to the benefit of product teams and customers alike.

But many teams are ready for more

More flexibility in their build pipeline. More integration points with JIRA. More advanced support for Git. More ways to take advantage of Amazon’s EC2. More attention to UI and usability.

More, in other words, of what comes from a team of developers and designers dedicated to one product, with one mission: to build the most intuitive, integrated build server on the planet. To help you spend more time coding, and less time configuring.

If your team is ready for a build server like that, then your team may be ready for Bamboo. And now it’s easier than ever to find out for yourself.  Our latest version of Bamboo includes an importer tool that converts your Jenkins or Hudson build projects in minutes. Just upload your Jenkins config data, then sit back and nibble your way through the last few chocolates in that Valentine’s sampler. (I won’t judge if you throw out the maple cream ones – bleh!)

Ready to learn more?

Great! We’ve got a host of helpful resources. Browse interactive screenshots, get the Bamboo cheat sheet for developers, and watch the recording of our webinar from March 21st: ”Moving from Jenkins to Bamboo”. See you there!

Learn More

No, really: I love pull requests. But I’ve learned to be more than a little nervous when accepting them. If only I had a dollar for every time an innocent-looking pull request completely threw the spanner in the works, broke every build, and had my team Nerf-pelting me because of the test failures. I’d be a rich man who wouldn’t have to sling code for a living!

To avoid being subjected to guerrilla Nerf warfare, I need to check the build status of the development branch before approving the request. So I go back to my Bamboo server and find the associated branch build. Scanning the history, I can see the results of builds triggered by the commit in question.

If the tests passed, I accept the pull request and merge into master (woo-hoo!). If they failed, I fire a warning shot across the office to the perpetrator. Time spent: 5 minutes (add another 5 minutes if its an unusually enthusiastic Nerf battle).

Cease fire!

We wanted a better way to see whether the changes in the pull request are passing the build. A way that takes less time and does not run the risk of a full scale Nerf armageddon.

So the Bamboo and Stash team got together and built a Notification plugin. Using Stash’s new Build Status API, Bamboo sends a build’s result over to Stash. Stash then cross-references the commits included in that build with any open pull requests. If a match is found, a simple pass or fail icon is displayed as part of the pull request. Bingo: the info we need, right where (and when) we need it.

Checking the build status in Stash before you accept the pull request

Ready to try it yourself?

The Bamboo Stash plugin is a free download via the Atlassian Marketplace for all Bamboo 4.3, 4.4 and Stash 2.1 customers. Hurry over and “Git” it before Nerf-ageddon strikes you!

Get the Stash plugin for Bamboo

Now don’t laugh when you see what bubbled up on our backlog. The common thread tying this motley mélange of a release together is you: your votes, your requests. Here’s a sample:

• Native support for TestNG – a new parser that reports on the full matrix of results from @DataProvider tests
• Amazon VPC – fire up elastic build agents inside a VPC subnet
• Task toggles – enable or disable tasks with a single click
• Jenkins importer – make Bamboo do the heavy lifting of converting your builds while you savor a heart-shaped truffle
• Performance improvements – up with caching, down with page load times

Check out the release notes or our What’s New page for more details on Bamboo 4.4, then upgrade today. You’ll be feelin’ the love in no time.

Learn more about importing from Jenkins

ps: If you’re wondering why this blog was uncharacteristically short n’ sweet, I’ll let you in on a little secret: we’re conserving energy. The team is cooking up something big and beautiful for Bamboo 5 – coming this spring – and every last molecule of bandwidth is devoted to that. Whatever your preferred flavor of “agile delivery”, you’ll dig what we’ve got in store!