It was great to be one of the sponsors at the GOTO Chicago 2013 conference from Tuesday April, 23 – Wednesday, April 24th  It was awesome meeting a number of JIRA, Confluence, and Dev Tools customers  at the conference.  Herzum Consulting, one of our experts joined us at the booth as well.  Atlassian Experts help deliver an incredible experience with our products. If you need a plugin built, a deployment tuned, help with setup and configuration, or coaching on going agile, we’ve got the expert for the job.

Technology, Innovation, and Fun

We enjoyed two full days of technology, innovation, and fun with some amazingly bright minds.  We heard from Dan North sharing on how we tend to cling to structure.  He challenged us how to thrive in an uncertain world.  Mike Lee talked candidly about how innovation happens at the intersection of creativity and commerce. His take is that innovation, the hard core engineering, commands sacrifice.  Mike encourages developers to seek feedback from peers as well as end users on making their application better.

We also heard from Atlassian’s own Tim Pettersen.  Tim, originally based in Sydney, was one of the developers on the Stash team.  He now joins us in San Francisco as a developer advocate.   Stash is Atlassian’s on-premise, enterprise grade Git solution.  He shared with all of us how to use Git as a platform.  He used examples from tracking configuration changes in a Wi-Fi router to seeing change history in the German legislature.  Tim of course hosts his slides in Git!

New to Git?

For those of you who are new to Git, Atlassian has two Git solutions: Stash and Bitbucket.  Stash is enterprise Git for an on premise solution.  Bitbucket is all of the goodness of Git hosted in the cloud.

Want to learn more about Git? Check out our Git center on the web.

Git Tutorials and Training

SourceTree is a free Git desktop client for developers on Windows. Say goodbye to the command line and use the full capabilities of Git through SourceTree’s beautifully simple interface (and stop being jealous of what your Mac friends are using).

A simple, powerful Git client

SourceTree for Windows simplifies how you interact with Git repositories so you can focus on coding.

• Get your team up and running using common Git commands from a simple user interface
• Manage all your Git repositories, hosted or local, through a single client
• Put Git commands at your fingertips: commit, push, pull and merge with just one-click
• Use advanced features such as patch handling, rebase, shelve and cherry picking
• Connect to your repositories in Bitbucket, Stash, Microsoft TFS or GitHub

Perfect for Git newbies

SourceTree was built to make Git approachable for every developer – especially those new to Git. Every Git command is just a click away using the SourceTree interface.

• Create and clone repos from anywhere
• Commit, push, pull and merge
• Detect and resolve conflicts
• Search repository histories for changes

Visualize your repositories

SourceTree keeps track of code activity and provides an at-a-glance view of everything from projects to repositories to changesets.

Use SourceTree’s Bookmarks to get a real-time, aggregated view of all your projects and repositories. Jump directly to the changeset graph to visualize changesets across multiple branches and forks.

Powerful enough for Git veterans

SourceTree makes Git simple for everyone, but also makes Git experts faster and more productive. Review your outgoing and incoming changesets, cherry-pick between branches, create and apply patches, rebase, shelve changesets and more with lightning speed.

Git one-stop shop

Atlassian offers a full complement of tools that will help you and your dev team make the most of Git. Whether you’re working on Mac or Windows, behind the firewall or in the cloud, Atlassian’s family of Git tools will bring you the power of Git while making adoption a breeze.

Connect to the cloud or behind the firewall

Thanks to hosting services like Bitbucket, many small teams working with Git repositories begin coding in the cloud. Connect SourceTree to Bitbucket’s free unlimited private repositories to easily manage your Git repositories from the SourceTree interface.

Stash, Atlassian’s Git repository manager for Enterprises, makes it simple to manage your Git Server – behind the firewall. With powerful two-way integration, Stash and SourceTree make it easy for your team to develop with Git. SourceTree can discover and fetch your Stash repositories. And one-click clone operations get you the source you need fast.

If you don’t have Stash or Bitbucket yet, not a problem, SourceTree for WIndows works with any Git repository, including GitHub, Microsoft Team Foundation Server or your own Git server.

What’s coming next?

We received great feedback from the SourceTree for Windows private beta users (a huge thank you). We will continue to push frequent updates and features to SourceTree for Windows users. We plan to bring all the great features that are part of SourceTree for Mac to Windows as well. What can you expect in the near future:

• Mercurial support
• Git-flow support
• Custom actions
• JIRA integration
• and heaps more

Get SourceTree for Free!

If you’re new to Git, or just want a handy tool to make you even faster, download SourceTree – it’s free at our brand spankin’ new website.

In this three part blog series we focus on migrating the JIRA code base from Subversion to Git. We wanted to share our migrating experience to those of you who are contemplating moving a large project to Git – without sacrificing active development. In our first post we discuss why we decided to make the switch to Git. In our second post we dive in the technical details of switching from Subversion to Git. In our third, and final post we will discuss how we managed the “human” angle to migrating.

Migration – The Human Side

So you might know that you can run a pretty slick migration from the technical side, minimize commit downtime and ensure high availability of your supporting infrastructure. But are your developers ready for the change?

The opinions of JIRA developers on the migrations varied from, “Git is the most wonderful thing to ever happen to JIRA,” to, “I know Git’s better than SVN but I need training,” to, “Just show me how to do what I currently do in SVN in Git”. It’s critical to address the needs of developers across this spectrum.

I’m a developer. The VCS you use (along with some other core things like programming language, IDE, frameworks and libraries) is one of your core tools and one of the key areas where you develop skills. Your VCS is the vehicle for technical communication and collaboration. You need to ensure that all developers are fully on board to maximize their own potential. If a developer has any uncertainty or hangups about the tools they use – particularly their VCS - their work can be severely impeded. Atlassian prides itself on openness – people are encouraged to speak up and risk falling flat on their face rather than not speak up at all – but I’ve worked at companies where I can envisage people hiding, not speaking up about issues if they’re not comfortable.

Also, developers worth their salt feel a connection to the code they write and their infrastructure. The most productive developers feel an ownership of their environment. If you are going to change that environment, like their VCS tool, it needs to be a change that they own and embrace.

1. Your team will need training

Assuming that everyone in your organisation can learn Git on-the-fly after the migration is finished is a recipe for failure. Git is fundamentally different to SVN. Being aware of this, making your developers aware of this, and preparing them for Git is critical in making the migration a success.

The first thing we did to get our developers ready was to run a couple of Git training sessions. For example, we started out with, “How to do what you do in SVN, in Git.” This included Git commands for things like committing and demonstrating what tools are available (developers at Atlassian use their IDE, SourceTree, gitg, and the command line to work with Git). More importantly, it focused on explaining the key differences between SVN and Git. What does it mean to have a local repository that’s a clone of the remote repository? What is a working copy? What is the staging area? Finally, a step-by-step guide to cloning the Git repository and getting started fast was introduced and published on our extranet.

Further, Charles Miller (our Confluence Architect) ran a seminar that was a real deep dive into how Git works internally – what data structures it uses internally, and how actual operations like committing work get done. This was optional for all developers, but some people learn by deep investigation which helps onboarding. Also, the more you delve, the more you discover that Git is a wonderfully elegant architecture internally which is valuable for any computer scientist to learn.

We developed these training sessions internally, however there are a number of external companies that run Git training if that is your preference.

2. Your team wants to know how the migration is proceeding

While we were running the migration, we kept the team up-to-date on the migration status via email and HipChat, our real-time group chat offering. Every time we reached a milestone, we let the team know. Every time we changed infrastructure, we let the team know – partly as a warning in case things break, but also to keep them updated on how things were progressing. It’s a satisfying feeling when you say to a team member, “Hey, you know that code review you just created, you actually created it off the Git repository,” especially if you can pull it off without anything failing during the change. This regular communication, from within the team, was huge in making each developer feel like they were up to date and owning the change. The worst outcome is if the team feels like this change is forced from outside, or if the tools they use every day are changing under their feet without them knowing.

3. Your team will need “Git champions”

Let me say this once again: Git is different to SVN and it can take a while for people to adapt. No matter how much you prepare, how much you educate – developers will run into issues when they start actually using it. Left unattended, these issues will reduce productivity and can spiral into hostility to change.

We marked a couple of developers who had Git experience as ‘Git champions’ after the move. Any time people had issues, or didn’t understand things, or just wanted to know, “What did I just do?” or “How did it work?”, they could pull in a Git champion to help them. This was critical to making the change as seamless as possible.

In practice, we found the major difficulty people encountered was not the differences between commands, but the differences in the conceptual model of working copy, local repository and remote repository. Developers had internalized the SVN model. I would say it took 2-6 weeks for each developer to reach the same familiarity with Git.

4. Don’t change your workflows too much too quickly

There are a number of really advanced Git workflows out there that allow you to put the “D” in DVCS. Branches, feature branches, forks and pull requests are just the start. If you switch to these advanced workflows at the same time as you migrate, you are either Albert Einstein leading a team of Nobel laureates, or you are setting yourself up for a fall. We took the principle of “success through stability” into our workflows as well. We started off with exactly the same workflow we used in SVN:

• one or two stable branches for bug fixes; and
• a master branch for new development work

As I mentioned above, our SVN workflow for getting bug fixes from stable to trunk was to manually patch each commit. We kept this workflow when first migrating to Git – each bugfix commit is manually cherry-picked into master. Why would we do this? Git is designed for merging – wasn’t it part of the reason we migrated? To maintain stability, we felt that the change to Git itself was big enough for developers to take on and that changing workflow would only complicate things.

5. Make small, iterative workflow changes

We made our first workflow change about two months after the migration – no more cherry picking. Stable branch merged to master with each commit.

Again, we invested in communicating this change to the team – the motivation why, and a series of steps for how to do it. We re-awoke the Git champions to assist people anytime they had a difficulty. It proved to be a smooth, easy transition. Making small, understandable, iterative changes is what made each change a success.

The Current State of Play – Distributed VCS, Decentralized Development

Once we had settled into a merging workflow, we started embracing the distributed workflows that Git enables.

I mentioned at the start of the article that one of our major products, JIRA, now releases to our hosted platform every two weeks. We tend to run with separate teams in separate branches; this enables frequent releases by decoupling separate teams’ work from each other:

• On the day-to-day level, one team’s changes do not affect other teams. Did Team A break the build? That’s not a problem.  Their changes are isolated to their own team – they only broke their own build and no other team’s development speed is affected.
• On the two-weekly release level, one team not making the cut does not affect the release. If Team B did not get all their stories over the line, they do not merge back at the end of their iteration. The release can go ahead with everyone except Team B’s stories.

This does introduce challenges of its own. Merging multiple sets of changes at the end of an iteration runs the risk of integration conflicts that can cause bugs. In practice, this is mitigated by the fact that individual teams tend to be working on separate areas of the code base. However, if a team or teams are working on areas that are likely to conflict with other teams, they tend to work directly on the master branch. The teams that are running on individual branches pull regularly from master to get these changes regularly and catch the conflicts before they become critical. Thus far, keeping the lines of communication open has prevented these sorts of conflicts from becoming problematic.

Another complicating factor is geography. JIRA’s main development is done in Sydney and Gdansk; but on any one day we might get commits from Atlassian teams in San Francisco, Boulder, or Amsterdam. Teams in different cities tend to run on different branches allowing us to get over the communication gap. To facilitate communicating the kind of potential conflicts I mentioned above, we use HipChat (our group chat product) for 1-1 and group announcements and communication; this works extremely well with our distributed team members. The real-time chat rooms kept conversations persistent so when someone logged on from a different time zone, they could check the status of the conversation and get quickly up to speed. Developers were pinged when they were mentioned in a room so they could respond to someone’s query without having to read through the whole conversation.

A quick note on branch strategies: some people advocate a ‘branch-per-feature’ workflow, where each individual story is developed on a feature branch. This is a great workflow if it fits your project. Some products at Atlassian use this. In JIRA, our CI overhead is very high. Running what we would consider ‘adequate’ CI on every story that gets developed is not within the bounds of reality for us. Branch per team, however, is working out well.

Success

The migration turned out to be a great success. No developers’ time was lost in limbo where they could not commit. CI ran continually, and we maintained the ability to do a 5.0 release throughout the entire migration. Post migration, we hit each change successfully and today, developers are embracing the power that DVCS gives them. The proof of this is in the complete change in our release cadence. There is no way we could have shifted from a 90-day to 14-day release cycle without DVCS.

This is probably the fifth time I have mentioned this but I cannot stress enough the importance of communication to the rest of your development team. During the migration, do not be afraid of giving it a higher importance than the actual technical migration tasks. It gets the developers to own the change. For those reticent to change, communication decreases worry and helps developers love Git. If you do it right, you will get comments from fellow developers like:

“I was a bit scared because Git’s a bit cranky sometimes but it was SMOOTH.”

And isn’t that what we want all along?

Make the Switch

Thinking of making the switch to Git? Check out our Git resources to learn more about how to make the switch.

So, what is this JIRA DVCS Connector?

For those new to this useful plugin, the JIRA DVCS Connector lets you

• Track commits, monitor source code edits, and drill through to source files all from JIRA
• Push commits to JIRA simply by referencing issue keys in commit messages
• Map unlimited public and private Bitbucket and GitHub repositories to JIRA projects.
• View Bitbucket and GitHub activity in the JIRA Activity stream

Watch the video for a quick demo!

Cool! What’s new in version 1.0?

Bitbucket Teams Support

In the old days, only a sysadmin had access to create repositories and edit permissions. Whenever someone needed to configure their repositories, having to go through a central administrator created a bottleneck in the development process.

But now we have entered a new age of convenience! If you are working with a small team, Bitbucket lets you consolidate your group’s repositories with Bitbucket Teams. Configure and access your repositories without having to switch between your company’s account and your own. Link the JIRA DVCS Connector to your team account and pull in all of your team’s repositories into JIRA.

Streamlined Administration

Your team is always innovating, and new repositories frequently get created. The old JIRA DVCS Connector would require you to manually configure JIRA to recognize these new repos. With the new auto-syncing ability, never worry about updating the Connector with new repositories again. The Connector will poll your Bitbucket account and sync your repositories to your JIRA instance automatically. Simply enter your Bitbucket credentials and you’re all set to work with your code in JIRA.

There may be times when you do not want a specific repository linked to a JIRA project. Simply check the boxes next to the repositories, and pick and choose those repos you wish to link to JIRA.

Easily Jump between Bitbucket and JIRA

Issue keys included in commit messages now allow you to link directly to your JIRA issues. Learn more about the commits that affect your JIRA issues with one click of your mouse.

• Link commits to JIRA simply by referencing issue keys in commit messages
• Use issue keys in pull requests or changeset comments to grant readers context to your Bitbucket changesets or JIRA issues.

Get the DVCS Connector Today!

The JIRA DVCS Connector is available both for Download or OnDemand. If you’re an Atlassian OnDemand customer, we’ve upgraded your instances with the new JIRA DVCS Connector. Contact your administrator to make sure that the Connector is turned on.

The collection of features now available in Bamboo OnDemand is large enough to fill a book (regular readers know I’m not one for brevity!).  My strategy here today is to call out the biggest n’ bestest of ‘em, and point you to resources that’ll take you deeper in. So bookmark this page.  Reference it.  Love it. Repeat.

Better AMI Support

You’ll need to update custom any custom AMIs used by your build agents to make them compatible with today’s upgrade, but going forward this won’t be necessary.  In addition, BoD now offers a stock image for building on Windows as well as support for EC2 spot instances.

Read more about AMI & Agent Support here: Atlassian OnDemand Release Notes – July 2012

DVCS & External Repo Support

The people have clamoured for it, and so the people shall have it!  BoD can pull code from external Git and Mercurial repos hosted on Bitbucket, GitHub or on your own network.  That goes for SVN repos on your own network, too.  Using Git submodules?  No problem. Want to pull code from a hosted SVN repo and a Bitbucket Mercurial repo into the same build? Done.

Tasks

Manual Stages

Many users’ workflows require a set of requests and approvals for deploying code to an environment.  And many many users would like to compile, test and deploy to a QA env with each commit –but deploy to production much less frequently.  Manual stages let you construct a single pipeline, and add “gates” or “valves” to satisfy those use cases.  You’re welcome. 

Plan Branches

Automatic Merging

Because automatic branch discovery wasn’t enough.  We wanted more!  With each commit to a branch, BoD can now grab code from a second branch, merge the two, run your Plan against the merged code, and if successful, push the merged code to either branch.  Great for ensuring longer-lived branches don’t drift to far from the main line, or for two developers collaborating on a feature using their own feature branches.

Read more about Automatic Merging here: Using Automatic Merges

Test Quarantine

When I was a test engineer, I would’ve killed for this.  But you don’t have to!  No more commenting out tests or dorking around with your suite.xml file.  Just click a button to neutralize a busted test.  It’ll still get run so you can see when it’s fixed, and you’ll see your count of quarantined tests on each build result summary so you don’t loose track of them.

Read more about test quarantine here: Putting Tests in Quarantine with Bamboo 4 (Yes, the zombie apocalypse has indeed arrived.)

JIRA Issues

BoD has issues.  And how!  Forget all that inefficient context switching, and create JIRA issues from any build results page in Bamboo.

Read more about JIRA Issues here: Top 5 Reasons Creating JIRA Issues from Bamboo Makes Your Team Awesome-r

Broken Build Tracking

Team leads and scrum masters have better things to do than hound people to fix the build.  With broken build tracking you can assign one person to be the default owner of broken builds for each Plan, or have responsibility assigned to users who made changes since the last passing build.  Bamboo will nag them on your behalf until the build is green again.

Read more about Broken Build Tracking here: Bamboo 4.1 Announcement Blog

Failed Stage Do-Overs

Everyone needs a do-over sometimes.  Maybe a build config needed tweaking.  Maybe your QA environment down just as you were deploying to it.  Re-running only the Stage that failed can save you a whole lot of time.  And time is money, so… yeah.

Read more about Failed Stage Do-Overs here: Bamboo 3.2 Release Notes

Onward!

Bamboo OnDemand is now resting on a more stable platform than before, so expect fewer stability hiccups going forward.  We’ve also made custom AMIs for your build agents easier (even updated the templates, so you might not need to customize at all!), and made Windows images available by default.  Très facile (redux).

But it’s also the end of an era.  This is the last announcement I intend to write about BoD upgrades.  Why?  Because they simply won’t be a big deal anymore.  We’ve retro-fitted our upgrade process such that BoD will be upgraded with new versions of Bamboo at the same time, possibly even before, those versions are available for installation behind your firewall.  This is one “good bye” I think we’re all happy about!

Those familiar with source control management tools like Subversion, Perforce, ClearCase and Accurev, can learn to use DVCS tools fairly quickly.  Atlassian provide tools to get started both behind the firewall or in the cloud. Atlassian’s Stash helps with your Git repository management needs behind the firewall or Atlassian’s bitbucket helps you host your Git and Hg code in the cloud.

However using DVCS tools to their full benefit has a considerable learning curve.  Whist you still add and commit your files in the conventional way, DVCS has many other features that need mastering before you get the full benefits.  For example, learning how to use local and shared repositories for different stages of the build pipeline as well as using pull requests across teams can have a dramatic effect on the amount of software delivered.  I recommend reading our diffs and patches post, that explains the benefits of DVCS further.

Migrating legacy projects from SVN is yet another challenge, especially for the enterprise, but again leads to opportunities to enhance the development experience with your existing code base.  It presents an opportunity to refactor your repositories, understand your core domain and start to isolate technical debt with greater effect.  When a large code base is broken down into valuable components, the architecture tends to be more adaptable to change. Those interested can read more on switching from SVN in our centralised vs distributed blog post.

Clearvision are a long standing Atlassian Platinum Expert and have a great deal of experience moving enterprises away from large and cumbersome source control management systems.  They believe that source control tools should be easy enough to use and manage by developers.  So if you have one or more dedicated resources managing your source control tooling, then it becomes very expensive and a very slow process to delivering software.  With the benefit of experience from Clearvision and Atlassian products, developers can quickly incorporate DVCS tooling into their software development life-cycle.

Clearvision recognised that we all have a large amount of legacy code running the business, and have poured their collective experience into their AgileSCM offering, to ensure your chosen DVCS tooling is used efficiently to develop and release products in a controlled, repeatable and secure manner.

With guidance from our experts in the field, the path to getting the most value from DVCS adoption is made much smoother. You can discover just how Clearvision and Atlassian help enterprises move to DVCS by attending the webcast Migrating To Git: An Effective Approach on Thursday June 21st, 2012 (15.00 – 16.00 BST – London time).

Yes, that’s right, Codegeist, your favorite development competition is back. Some of you who came to Summit will know that this year’s Codegeist started June 1st and goes until July 16th. For you noobs, Codegeist is Atlassian’s annual add-on development competition. This year we’re giving away $45,000 USD in cash prizes. There are four prize categories you can participate in and win:

1. Best Overall Add-on ($15,000) — This award will go to the best overall  add-on as judged by our panel of judges
2. Best Community Rated Add-on ($15,000) — This award will go to the highest rated add-on (as rated by the community on Marketplace)
3. Best Marketplace-enabled Plugin ($7,500) — The plugin judged to be the best overall Marketplace plugin (i.e., a plugin which implements the Atlassian Marketplace APIs for licensing and selling their plugin on Marketplace) will receive this prize.
4. Best Atlassian Stash Add-on ($7,500) – This award will go to the best add-on developed for Atlassian’s newest product, Stash.

You may have noticed that we’ve been referring to “Add-ons” a lot lately. Think of Add-ons as a superset of integrations, extensions, and other customizations that developers build on top of Atlassian products. Atlassian Plugins are Add-ons, but so are non-plugins. Add-ons are any extensions to Atlassian’s products (JIRA, Confluence, Stash, Bitbucket, HipChat, Bamboo, Fisheye, Crucible, Crowd, etc.). Add-ons can be plugins, Remote Apps, web apps, mobile apps, browser extensions, libraries, clients, command line tools, etc. If it uses an Atlassian product API, it’s an add-on.

To enter an Add-on into Codegeist all you have to do is:

1. Build something awesome that uses an Atlassian product
2. Share it on Marketplace
3. Ask your friends and customers to try it, rate it, and review it on Marketplace. Ratings and reviews will be used by our judges to determine the best Add-ons.

To share it on Marketplace, all you have to do is list your entry and make sure you select the “Codegeist 2012″ checkbox.

In recognition of the constant innovation that’s helping small businesses perform at their best, we have compiled a selection of some of the best free and paid-for cloud-based applications available.

We’re in good company with the likes of  New Relic, the Atlas Sponsor for Summit 2012, and many others. Obviously, Confluence and Bitbucket were inexplicably left out… which applications make your business grow?

Infographic by Premierline Direct

Six awesome marquee speakers

Jeff Atwood (codinghorror.com), Michael Lopp (randsinrepose.com), Pamela Fox (indie dev), Eric Ries (Startup Lessons Learned), Dave Thomas (Bedarra Research) and Jeff Ma (MIT Blackjack Team and entrepreneur) will be sharing their secrets to software development on high producing teams.

In addition, the New York Stock Exchange’s Chief Digital Officer, Bob Kremer, will be joining Atlassian Co-Founders, Mike and Scott, on stage to talk about innovation at NYSE using Atlassian products.

AtlasBar and Guru Room

Meet our developers, support engineers, and product managers at Summit. The AtlasBar is our homage to Apple’s Genius bar – get your technical support, configuration, feature, and integration questions answered. Want to give us even more feedback or learn about upcoming products and features? Drop by the Guru Room to meet with our, well, gurus.

Industry Mixer

We’ve asked dozens of customers over the last few months what they want more of at Summit, and the answer we kept hearing was, “We want to meet more customers like ourselves.” If you’re in town on Wednesday, you can join the Industry Mixer at 5pm. You can keep networking at the big Summit welcome reception starting at 6pm and throughout the rest of the time at the conference.

Training galore

Training is huge at Summit, and this year even more so. We have three training partners teaching courses ranging from Confluence Fundamentals to Scrum and Kanban with GreenHopper.

Getting virtual

Attendees will be receiving an email soon with details on how to access virtual rooms and an online agenda at Summit. Stay tuned!

A special shout out to New Relic, the 2012 Atlas Sponsor, for their support of Atlassian Summit!

Sponsors

How can you extend Atlassian products for new use cases? How do other companies customize our products for their teams? How can you integrate Atlassian products into your unique enterprise technology stack? Those questions can best be answered by our 35 stellar sponsors who will be demoing all their newest integrations and add-ons.

 Marketplace Workshop

Want to get a head start on selling your plugin on the Atlassian Marketplace? Register for our free workshop to find out how!

There’s WAY more happening at Summit… Atlassian User Group meetups, sponsor birds-of-a-feather, a speaker Decompression Room, the Chillout Lounge, Bitbucket and HipChat booths… and if you can’t tell, we’re really excited about all of it. It’s gonna be a fun, educational, informal, and information-packed couple of days. See you at Summit!

One of my favorite features of HipChat is the ability to bring in relevant notifications into your team’s room. Here’s an example of a notification coming from JIRA:

JIRA’s workflow engine is highly flexible and can be tuned to whatever process you want to support regardless if you’re managing issues, requests, or tasks. We built a JIRA plugin for HipChat that binds to JIRA’s workflow engine (using Post Functions) to allow JIRA project admins to subscribe to any workflow transitions they please. For example, you may not want to notify your team of every issue transition, but maybe just the ones marked with a high or blocker status.

In our Developer Relations room, we find that notifications from Twitter and Zendesk are highly useful for responding to questions or comments by developers in our ecosystem. This is possible through a SAAS based integration service by Zapier.

In other rooms, some teams like to see commit notifications from Bitbucket and Fisheye as well as build notifications from Bamboo… we have plugins for those too:

I’ve seen other teams use HipChat notifications to alert them of new product orders/subscriptions that come in. This is all possible through HipChat’s simple REST API. Although, before you attempt to integrate something with HipChat, check to see if that integration already exists on HipChat’s catalog of existing integrations — all 38 of them! If the integration you’re looking for doesn’t exist, the REST API is as simple as…

These are just a few great productivity boosters you can use for your teams on HipChat. Of course, there’s also a fun aspect to HipChat including HipChat’s unconventional emoticons.

What do you think? Could your team benefit from these type of features? If you use HipChat, care to share with us what you like to do with it, other than chat?