Taking this in account and thinking about all the new developers adopting our tools everyday I decided to write something that would help all new users of FishEye and Crucible to get more out of their instance and, if you have been with us for a long time, just take it as a fresh reminder of something you can use everyday to understand what’s going on with your code.

In this post I’ll cover the following topics:

• Interacting with the Commit Graph
• Highlighting all the parents of a particular commit
• Tracking all commits related to a particular JIRA issue
• Quickly checking which changesets are not reviewed yet
• Creating reviews straight from the Commit Graph

Interacting with the Commit Graph

This will be rather quick as there are mainly 3 components that you will need to know to use the Commit Graph:

• Highlight selector
  This dropdown lets you select which highlighter you want to use on the graph.
• Branch selector
  With the branch selector you can decide which branches will be included in the graph.
• Interactive commits
  Ok, it’s a bit of a made-up name but the dots that you see on the graph are interactive and they will help triggering some of the highlighting features that you will discover below.

Now you should be ready to dig into the different usages of the graph!

Highlight the parents of a commit with the Lineage highlight

The most basic feature of the Commit Graph is to offer a simple way to track the ancestry of your commits. This is possible with the Lineage highlighter which allows you to mask all the commits that are not related to the one you have selected. Using it is straightforward:

1. Make sure the Lineage highlighter is selected
2. Click on a commit in the graph

At this point all the commits that are not part of the ancestry of the selected one should be masked, giving you a clean view on the history of a particular change.

Track all commits that do  JIRA issue

A lot of our customers are combining FishEye, Crucible and JIRA together to ensure the quality of their development. If you have JIRA hooked up to your FishEye instance you can simply put issue keys in your commit messages to link your source back to JIRA. As soon as this is done you can use the JIRA issues highlighter of the Commit Graph to see all the changesets that have an issue linked to them.

You can go one step further with the JIRA issues highlighter and click on a particular commit to see all the other changes in the source that are related to the same issue.

Check the review status of your commits at a glance

The Reviewed changesets highlighter will help you to have a quick overview of the state of your reviews by using color codes to show you commits that are reviewed (green), under review (yellow) or that do not have any review attached to them (red). Once again the usage is straightforward: Select the Reviewed changesets highlighter to get the colors applied to your commits.

And just like the JIRA issues highlighter you can click on a particular commit having a review to see all the other commits that are included in the same review.

Creating reviews from the Commit Graph

It wouldn’t be convenient if you had to get out of the Commit Graph to create a review for a particular commit. This is why you can quickly create reviews for any commit that you can see in the graph via its contextual menu.

Give us your feedback!

And voilà! I hope that this will help you to get more everyday out of your FishEye and Crucible instance. I would love to hear back from you guys and get your suggestions to improve this feature. Getting your feedback makes a real difference!

FishEye and Crucible were created to help development teams function as smoothly as possible using a common interface to browse source repositories, investigate the code history and easily review the modifications in various SCMs. We required a great integration with JIRA to track the changes in the source related to the development tasks. JIRA is now used by more than 20,000 organizations worldwide and it’s partly thanks to these two products. Let me tell you here in which ways you can link your issues and your source together to ensure your releases are of top quality.

A simple and straigthforward integration

First comes the integration between FishEye, Crucible and JIRA. We recently re-architected the way the applications talk to each other to achieve simplicity. Only a single link between your JIRA server and your FishEye and Crucible instance will be needed to get all the power of the integration.

• Always see in JIRA the list of source changes related to an issue.
• Create reviews directly from JIRA and automatically have them linked back to your issues.
• View details of your issues in FishEye and Crucible in your source, commits or reviews
• Create issues from Crucible during your reviews without the need to change applications.
• Use JIRA for user management reducing the overhead of managing multiple sets of users.

The new improvements introduced in the latest releases can connect all JIRA projects, FishEye repositories and Crucible projects together without requiring any extra configuration because we do not want you to spend your time in the configuration pages of the administration interface.

Track outstanding work in JIRA while doing code reviews

With Crucible 2.10 we have improved JIRA issue creation from reviews with what we call the Inline Issue Creation. Reviewers can now create issues and subtasks in JIRA without having to leave Crucible.

No more jumping back and forth between applications; Crucible will offer you a direct interaction with JIRA to let you keep track of outstanding work that you identify while you’re reviewing the code of your peers.

We know that context matters when you look at issues. That’s why we added a mention of the original review to the issue page in JIRA. So that you can always know where tasks are coming from and get all the information necessary to understand what needs to be done.

Link all the source, no matter where it is

With FishEye’s new integration to JIRA you will never miss a changeset linked to your development tasks. It has been designed to find and reference every changeset back to the JIRA issue mentioned in a commit message of the repositories indexed by your instance.

Often times you need to touch multiple repositories to resolve an issue. And for some organisations those repositories may be managed with different SCMs. This is the case where FishEye and Crucible offer a unique way to cross-reference your source, reviews and issues no matter what type of SCM you are using and no matter where your repositories are located. And of course, we respect the sensitivity of your data and we allow access to be restricted.

Give it a try, let us know what you think

If you’re using JIRA with your development and already have FishEye and Crucible have a look at the new integrations and let us know what you think. If you haven’t tried FishEye and Crucible yet, check the link below and give us your feedback!

Whether you’re an agilist getting your team started with CI, or automated testing enthusiast looking to scale up and trick out your system, you’ll want to read this. Or you could just read it for the StarCraft references

Get the report

See, we’ve been made to understand that, more than anything, devs just want to get back to coding. We also understand how hard it can be to keep a growing dev team flowing smoothly as new members join and new features are coded. Teams need a common interface for browsing repositories, tracking changes and reviewing each other’s code. And that, my new alien overlord, is why we built FishEye & Crucible 2.10.

Take a Load Off

In the 2.8 and 2.9 releases, we removed architectural bottlenecks so FishEye and Crucible can keep up with the growing size of our customers’ repositories. Not only did we continue core performance improvements in 2.10, we added a new REST endpoint that gives your hard-working servers a little relief.

Instead of polling repositories once a minute, you can now trigger re-indexing only when something in your repo has actually changed. We even added support for triggering indexes from cloud-dwelling repositories on Bitbucket and Github. Optimizing FishEye and Crucible with post-commit hooks for indexing slashes server load and makes every operation faster, especially for Enterprise teams: page loads, reviews, reports, teleports… wait, strike that last one.

In the same spirit, we added a limit on the number of files that can be included in a Crucible review. But don’t worry: 800 files is far more than you’d want to review anyway (unless you are a Cylon…). By disallowing reviews against whole-repository commits like initial imports, branch creation or merges, your instance – and your productivity – is further protected against slowdowns.

Ludicrous Speed

But our quest for ultimate dev-speed doesn’t stop there. Developers all over the universe use of FishEye’s smart commits to create, update, and resolve issues and reviews programmatically. Now the same applies to review objectives Crucible. Use the smart commit syntax to add objectives to reviews as you’re creating them, or to existing reviews – without having to switch over to Crucible.

And speaking of context switches, we threw another one out the airlock: now you can create JIRA issues right from the Crucible review you’re working on. Eminently logical.

All Your Code Are Belong to JIRA

Like 20,000 other teams across the galaxy, we use JIRA every day. So we know how important it is for FishEye and Crucible to integrate with JIRA as much as possible. With 2.10, associating all your instances and projects is easier than ever.

Connect them using Application Links, and that’s it. No need to meticulously map individual projects. Or install plugins. Or subscribe to gadgets. (Save those braincells for coding – the mothership needs your synapses to be well-rested.) With just the application link, you’ll see commit and review info inside issues, jump from issue to commit to review with a single click, and enjoy all the other benefits of integrated development tools.

Thanks For All the Fish(Eye)

That’s a lot to grok, but we’re sure your enlarged alien brain can handle it. We hope you enjoy using FishEye and Crucible 2.10 as much as we’ve enjoyed building them! Upgrade today – you’ll be kicking out fixes and features faster than you can make the Kessel run.

Already using FishEye or Crucible? Check out our full FishEye and Crucible release notes to get started.

Simplified Administration

There are loads of things that can get in the way of your team’s productivity – but configuring your development tools shouldn’t be one of them. Administrators are routinely looking for ways to save time, cut down on common requests and get their development teams up and running quickly. The FishEye and Crucible team has delivered a set of new features to make system administrators’ lives a whole lot easier by simplifying the integration between FishEye, Crucible and JIRA.

• Save time: teams with large repositories and projects no longer need to create and maintain multiple links between projects in JIRA and repositories in FishEye, this is now done automatically.
• Cut down on common requests: never get another request to connect a FishEye or Crucible project to a JIRA project. Your JIRA instance now gets data from all projects existing on your FishEye and Crucible server automatically – no mapping required.

Seamless integration with JIRA unites developers and non-technical project team members around the code and the activity they track together as a team. Simply linking your JIRA instance to FishEye and Crucible gets you code, review and issue traceability.

• Full development traceability: code, peer reviews and JIRA issues come together to provide a 360-degree view of your team’s work.
• Cross linking between JIRA, FishEye and Crucible: we put the information you need where you’re already working. While working in JIRA, one click on the Source Tab takes you directly into any changeset, diff, or review in FishEye and Crucible where you can also see detailed information on issues.

Improved Performance

Continuing our focus on performance, this release delivers improvements to strip off seconds for several common operations between JIRA, FishEye and Crucible – specifically the Source and Review Tabs. Large instances with multiple repositories, each with many changesets will get relevant information up to 10x faster when viewing the Source and Review tabs in JIRA. Check out the difference from data tested on a load testing instance of FishEye and Crucible with multiple repositories and changesets.

Faster Review Creation for Larger Teams

Building time for peer code reviews into a project schedule is hard enough, so the process has to be simple and easy. Our developers want efficient code reviews so they can get back to coding – we reckon yours do too. So we asked ourselves: How can we save developers time when creating reviews?

We realized that developers know instinctively what needs to be reviewed and what doesn’t. So we axed the “Suggested Reviews” step when creating reviews – a step that was taxing both for the review creator and the Crucible instance itself, especially for larger instances. By removing it, we streamlined performance for both human and machine.

Try FishEye and Crucible 2.9

New to FishEye or Crucible? Start a free trial today and get up and running in minutes.

Already using FishEye or Crucible? Your upgrade awaits you. Check out our full FishEye and Crucible release notes to get started.

Focus on Performance

In software development, every millisecond counts. Development teams are constantly trying to shave off seconds for each operation performed and the sum of each time savings drives whether projects hit their release date and whether products succeed or fail. The FishEye and Crucible team are constantly gnawing on this challenge of improving dev speed. Browsing source, searching for artifacts, creating reviews and speeding up collaboration cycles are a critical part of the development process, and they should be fast. We’ve structured our effort for both today’s releases and our upcoming releases on this theme.

Faster Page Loads, Smoother Browsing

Seeing the big picture is key for all developers, especially team leads and their managers. So, we started with the concept of improving page load times as the area where we can create the biggest customer benefits. While the improved page load times ripple out across the product, let’s take a sec to deep dive into the impact we find with Activity Streams. Streams provide a high level view into your projects, showing commit and code review activity in real-time. They are not just provided on the project level, you can view Activity Streams for repositories, directories, author, project and even individual files. Activity Stream page load times have improved by up to 50 times. Check out the difference from data tested on a load testing instance of FishEye and Crucible.

Along with making page loads faster, we also made sure that the user experience on the Activity Streams improved as well. If you love Facebook and Twitter’s “infinite scroll”, you’ll enjoy the same experience browsing your commits and reviews chronologically on Activity Streams pages. 

Did we stop at Activity Streams? Nope. The FishEye and Crucible Performance Team made improvements to load times of other key pages, including the Projects list (that one’s for you, Enterprise users!).

Getting Social

Another important area for boosting team speed is accelerating the collaboration cycle. FishEye and Crucible 2.8 introduce some key social features to help assure that the right person on your team gets the right info at the right time.

@mentions

Easily bring members of your team into a code discussion by @mentioning them in a review or changeset comment. Just type “@” + their name as part of your comment and they will receive a notification that they have been mentioned. From there, the conversation can take place in Crucible or changeset comments where it’s available to everyone, instead of being hidden in your email. Pull them into the conversation – your code will benefit from it!

Why @mention?

1. Casually bring in contributors and stakeholders for richer collaboration. Want input from a UX Designer or Product Manager who wouldn’t normally be included in a technical review? A simple @mention brings them into the conversation and gives them a chance to lend their expertise.
2. Draw in technical experts from inside or outside the immediate team. @mentions are a non-intrusive way to widen the discussion by inviting specific individuals for specific threads of conversation, without the burden of adding them to the review workflow every time.
3. Transparency is just plain helpful when it comes to coding. You know it, we know it.

Share Code and Reviews with your Team

Software development is not just about coding. It’s a network of developers collaborating on a common project. When collaborating, it is important to get information to members of your team (and outside your team) fast. Every aspect of FishEye and Crucible is easy to share between team mates because everything is just a URL away. All it takes to share any artifact with your team is switching over to your email or IM applications to share information.

But we weren’t satisfied with that. FishEye and Crucible 2.8 make the sharing of information super-quick. With the new Share Button you can instantly share repositories, reviews, commits, files and diffs with members of your team or users new to FishEye and Crucible. That means no switching between applications! Click Share, specify the users you’d like to notify by username or email address, provide a quick message for context and FishEye and Crucible will keep your team up-to-date.

Subversion 1.7 Support

Satisfying a highly voted feature request, we now fully support Subversion 1.7, making FishEye and Crucible more compatible with your Subversion environments.

Try FishEye and Crucible 2.8

New to FishEye or Crucible? Start a free trial today and get up and running in minutes.

Already using FishEye or Crucible? Your upgrade awaits you. Check out our full FishEye and Crucible release notes to get started.

The FishEye team was the first team at Atlassian to make the switch to DVCS, and while some Atlassians had previous DVCS experience, quite a few had not yet used it in the workplace with a medium-size team of developers before. We looked for help around the web, but there wasn’t a lot of people sharing their experiences at the time. We found many resources like “How do I push a branch in Git?” or “How do I pull from multiple remotes in Mercurial?”, but we found few resources that explained “What is the best way for a 15-developer team to move from SVN to DVCS?”

Rather than diving in and prematurely using every DVCS feature out there, the FishEye team decided to keep our old SVN workflows until we got the hang of DVCS. After all, we were still trying to ship new features to our customers as fast as possible, and we couldn’t risk slowing down our development learning completely new workflows.

So, we continued to develop new code on trunk up until a couple of weeks before a release. We would then create a release branch to manage last minute features and bug fixes. Once we created our release branch, we would begin new development of the next release back on trunk. When a new version was ready for release, some poor developer was then assigned the time-consuming and painful task of merging the release branch back to trunk using SVN. If we needed any immediate fixes, it was normal to cherry-pick them rather than to merge the whole branch.

In practice, our development team could have one or more release branches (e.g 2.5 and 2.6) that they were maintaining at the same time with occasional bug fixes or crucial security fixes. In SVN, the easiest way to manage small bug fixes was often to make the same changes 2 or three times over these release branches. Occasionally, these bug fixes either would not get merged into our latest version, get misapplied, or get merged in once the actual code had been refactored, making it extra difficult to figure out where the fixes should be applied.

Copying the SVN workflow with Mercurial, we pushed all of our development on default – Mercurial’s version of trunk. We also strongly advised our developers against using any history modifying commands like histedit or rebaseuntil we were extremely familiar with the tool and the concepts that Mercurial provided.

The immediate downside of this workflow for a team of 14 active developers was that by the time somebody pushed his/her commits to our Bitbucket hosted master repository, it was highly likely that someone else had already pushed his/her own changes. This meant you had to hg pull; hg merge; hg commit to integrate their changes, then hg push and hope someone else hadn’t done the same before you! Generally, following our old SVN habits, people started off trying to push after every commit, meaning we had a lot of merges! There were several people in the team agitated that Mercurial created more work!

Feature Branches versus Continuous Integration

Luckily, branching and merging are much faster in DVCS than in SVN. We had already experienced this difference in the merges we were doing on default, and once we became more confident in our own DVCS abilities, we started doing more work on feature branches to solve our workflow problems. For those unfamiliar with feature branches, feature branches allow developer(s) to code features unhindered from the other changes going on around them. They allowed a R&D platform for our developers, so that they could create features without worrying about breaking code for their other teammates. They also meant less merging and fewer distractions every time another developer executed an svn update.  The branch would stay active as the feature went through development, testing, code review, etc.

Feature branches provided an elegant solution for our development, but we ran into a big problem with our Bamboo builds. The builds for our default branch were no longer building against these feature branches; the devs had to run the full test suite manually or wait until they merged the feature branches back to default. Either workaround meant that the devs weren’t coding while they were waiting to reconcile the builds!

Before the advent of Bamboo Branch Builds, we actually cloned the default build for longer running feature branches, but Bamboo 4 has made this super-easy. We could now use a branch build for each feature branch that we have.

If you are not using a CI server with this capability, the approach we took before Bamboo 4 was released can help. We configured a clone of our main build to only run manually and took a build parameter for the branch field in the source repository configuration. This meant that without configuring a separate plan in Bamboo, we could build any branch we wanted to on demand (Note: in Mercurial, a commit hash also works, so it doesn’t even need to be the head of a branch). We actually still use this approach for smaller branches that need a one-off build. We can then link the build result onto the Crucible review so that reviewers can see that the code in question actually has a successful build before they approve the changes.

Lastly, we were not integrating our code until features were complete. However, Mercurial’s easy merging made this problem manageable. Each team would merge from default as often as they wanted to make sure they were integrating with the latest stable code on default.

Hardening Time

The weeks leading up to a release were a great time to let my inner dictator come out and play. We combined the above techniques to make sure we had a green build on our release branch as much of the time as possible. As the release manager, I would not let anyone else commit on or merge to the release branch. All work had to be done on feature branches, and I would only merge branches which had been reviewed in Crucible, had closed JIRA issues, and passed all their builds. To track whether a branch met each of these criteria, we wrote the FishEye Release Report, which could not only report the state of all the code between two releases, but could also show the status and linked JIRA issues of all the commits that would be merged from the feature branch.

To further ensure the success of a merge to the release branch, I mandated that all merges have no (even automatic) conflicts. If an hg merge feature-branch and hg resolve -l (which lists all the merged files, not just conflicting ones) reported any file level merge conflicts, the branch would go back to the developer, who would have to merge from the release branch himself and resubmit to Bamboo for a green build before I’d consider it again.

While it sounds time consuming for the developer, this process meant that every other developer who was working on a bug-fix could have absolute confidence on the integrity of the build system. Any build breakage on their feature branch could be attributed to their own code changes, as the release branch was always green when they started work. This actually saved a lot of time for the team as a whole, as it took a lot of the investigating out of the development workflow.

Since that release, we have evolved to a somewhat less dictatorial style where we try to mix a little more flexibility while maintaining the wins we gained from keeping a green build on the release branch. The FishEye Release Report and the review builds are crucial to this.

Bug Fix Merging Made Easy

Another problem we found easier to deal with in DVCS was the problem of bug fixing older releases and making sure those fixes got into every subsequent release. In our worst case scenario, we had two release branches and a development branch that we were maintaining (e.g. 2.6, 2.7 and default). Every fix for 2.6 had to get into the 2.7 branch as well as the default branch.

The easiest way to do this in DVCS is to not backport fixes to older releases (which often happened in SVN days), but to fix the bug in the oldest branch which needed the fix. Anyone who commits a bug fix feature branch to a release branch is then responsible for making sure that that release branch is merged into the development branch and every future release branch. This step is especially important for merging bug fixes between versions that were released three or four months apart, as the fix in question may differ quite considerably due to refactored code. And who better to determine how it should be merged than the developer who coded it. This process works much better than the SVN model, where we would either cherry-pick or leave it to the unlucky developer to fix every now and then!

But what about changes in a release branch that you don’t want in later releases? Won’t they get merged and cause problems? Our solution to this was the same as above — anyone who made a change to a release branch (like bumping a version number in a pom.xml file) was responsible for merging that change all the way down the chain to the developer branch. When developers merged, it was their responsibility to make sure they reverted the actual changes in the files in question, and then commit. This measure ensured that no one could ever merge these changes downstream accidentally, for according to the DVCS commit graph, they had already been merged!

Typically, this policy is an easy one to follow. In Mercurial, when merging what should just be one’s own work to a downstream release branch, one can check before executing the actual merge using the -P option to merge. Mercurial will list the actual commits a developer is about to merge and let him validate that he’s not merging anyone else’s code. If this is the case, he can go and grab the other person and get him to merge his commits first.

If you don’t use this model of managing release branches, DVCS has another solution for you. For a bug fix or other change that needs to go to two or more disparate branches, create a feature branch from the oldest common ancestor (Git and Mercurial both have one line commands in order to determine the oldest common ancestor). That way you can safely merge the bug fix to any or all of the target branches without merging any other commits.

DVCS FTW!

DVCS has definitely made us more productive – apart from giving us more flexibility in how we develop, we have evolved workflows that let us keep a higher quality in our release branches. DVCS also prevents our developers from getting distracted at crucial times by other work that is happening around them, while allowing them to control when they integrate their code and ensure that these integrations work. Lastly, merging across release branches ensures that each and every bug fix gets integrated into all subsequent releases.

Takeaways

• Use feature branches!
• Merge from your stable branch to your feature branches as often as you want to make sure you’re integrating with the latest stable code!
• Use Your CI server to make sure your feature branches are good before you merge to your stable branch
• Have a clear model of which active branches are “downstream” and always fix common bugs on the most upstream branch.

For more resources on DVCS, check out these links below:

• http://blogs.atlassian.com/2011/02/moving_to_mercurial___why_we_did_it/
• http://blogs.atlassian.com/2011/03/goodbye_subversion_hello_mercurial/
• http://blogs.atlassian.com/2012/02/fisheye-git-svn-hg-release-report/
• http://blogs.atlassian.com/2012/03/fisheye-release-report-merge-branch/

Ultimately, the fact that JIRA allows SAF to work smarter means more Montana foster care youths get laptops and the supplies they need to pursue their dreams of higher education.

About SAFMT

Based in Helena, Montana, Student Assistance Foundation is a nonprofit organization providing students with the knowledge and tools to pursue and fund their postsecondary education. SAF uses proceeds from its student loan servicing business to offer a range of programs that include grants, community outreach, counseling and training on education finance planning.

Development Process

I recently spoke with David Thompson from SAF’s development team. David gave some background about what they’re working on and how Atlassian tools have become central to their processes.

We have 65 different development projects that we handle through JIRA and FishEye, and then use Confluence as our wiki for all those products. We do everything from automated file transfer systems to developing our web-based student portal where students can make their student loan payments online. We manage all the code base for those products and track our development with JIRA.

JIRA has spread to the rest of the IT department for tracking issues, major system changes, and planning out releases. Outside of the IT department, we do have several groups within the company that are using Confluence.

The Switch to JIRA

David started at SAF five years ago, and the company immediately started using Mantis because they weren’t using a bug tracker before. “After about two-and-a-half years, it became apparent that Mantis couldn’t handle what we were trying to do with it, so, we started looking for a better option.”

David first learned about Atlassian from a book about rapid application development that he was reading. “When we found out you give your products to nonprofits for free, the deal was sealed!”

How did the Atlassian ecosystem and development community factor into your decision?

From past experience using JIRA, we knew the product could handle 80 to 90 percent of what we needed it to do. Then, through searching documentation online, we found almost every answer we needed relatively quickly. The documentation and searchability related to this product is phenomenal. I don’t think I’ve ever submitted a request for help to install, or do anything from Atlassian because I can usually find the answer I need online.

Growing Together

As a non-profit, SAF aims to funnel as much money as possible into helping students. David shared how metrics and reporting from JIRA has empowered the development team to improve their own processes and reduce operating costs.

Two of my installations are on 5.0.5 as of last weekend. The Share button in JIRA 5.0 has saved us time notifying one another of relevant issues.

I have two production JIRAs — one test and one development. One of the things I did was work with the JIRA REST API with 5.0, and modified all the code to be able to submit issues via the REST API, to submit that code back to Atlassian. We’ve done some really exciting things with some of our automation of issues.

Throughout all of our development, we decided to use JIRA not only as a means of bug tracking the applications, but to track any issues that may occur.  So, all of our automated processes have methods to report their errors back into JIRA. We have at least five different systems putting 10,000 issues into JIRA per year.

What we really like about this process is that we can now track those issues, see who’s working them, know when they get completed, and make sure that the problem was addressed. We used to track these issues by emailing two or three operations people. Often, nobody knew who was working on what issues. Now, with JIRA, it’s easy. We have one operations employee that watches that project, and he assigns issues to the appropriate person each day.

How has that changed operations within the company?

In October, we finally set up all systems to automatically create JIRA issues. Using JIRA’s built-in reporting, we found that we were getting anywhere from 100 to 1,000 issues a day that were being ignored. By looking at the volume of similar issues, we were able to identify warnings that come up repeatedly. This allowed us to accurately report to management where our time was being spent. Just by showing management the graph, we were able to put a pause on new development to flatten the curve and minimize the amount of maintenance work required.

Rather than fixing each warning error, developers started fixing the code instead. Prior to using JIRA, we didn’t realize we were doing more maintenance work than development. Within four months, we knocked error messages down from 100-1,000 per day to just 10-20 per day. What we learned is that fixing the core of the problem, rather than just the error messages, allowed us more time to dedicate to development.

Changing Lives

One of our internal goals is to work smarter, not harder. JIRA has made a huge impact in working smarter because we fixed numerous issues that we didn’t realize existed. When it comes to the amount of savings that can be passed on, Student Assistance Foundation’s primary goal, as a nonprofit, is to take any money that the company makes to give back to the students. As a result, we take income generated through servicing loans to provide grants and other services to students, and borrower benefits like interest rate reductions.

Part of what JIRA has done is allow us to work with a smaller staff. On a larger scale, these savings provide SAF with the opportunity to dedicate more funds to its public benefit programs. For example, SAF organizes a free, four-day camp each summer for Montana foster care youths who are heading to college. We give these students laptops, give them training in scholarship searches and career exploration, and help them get ready for postsecondary education. Ultimately, the fact that JIRA allows SAF to work smarter means more Montana foster care youths get laptops and the supplies they need to pursue their dreams of higher education.

Get a Free Community License

Are you with a non-profit organization? Atlassian software is free for use by official not for profit organizations and charities. It’s our way of giving back to the community (and to hopefully improve the productivity of charitable organizations too). Get one here!

Why did you #Go_JIRA?

If you switched from an old bug tracker to JIRA, we’d love for you to tell us why. Let us know by tweeting the #1 reason you decided to #GO_JIRA:

[THIS IS] why I ditched [MY OLD BUG TRACKER] to #GO_JIRA http://atlss.in/GoJIRA

Did you Go GreenHopper too?

Tell us why you decided to #GoGreenHopper:

[THIS IS] why I decided to #GoGreenHopper http://atlss.in/GoGreenHopper

SGD: First, tell me briefly what it means to be the product manager for Atlassian OnDemand.  What are some of the projects you work on?

Thanks Douglas!  One last thing to point out is that having FishEye OnDemand will no longer be a prerequisite for using Bamboo OnDemand.   JIRA OnDemand will still be required, however.  For more information about what’s coming up in the OnDemand world, see the Atlassian OnDemand release summary.  To get a preview of what’s in store for Bamboo OnDemand, check out the “What’s New” pages from version 3.1 and forward.

If this news comes to you as a surprise, it’s not too late. Codegeist is our annual Add-on development contest. If you have an idea, some code skills, and a desire to win you’ve still got 13 days to submit your add-on.

Here are some noteworthy entries so far:

• 

  Ad hoc Canvas

  by Comalatech

  Ad hoc Canvas lets you visualize and organize your Confluence content. Get an overview of pages, and organize content by dragging on boards or checking-off lists.

  Products: Confluence   Categories: Custom Fields, Document Management, Image, Visualization & Reporting   Free or Paid: Paid via Atlassian
• 

  Atla-Search Plugin

  by J-Tricks

  Atla-Search plugin facilitates the searching of various Atlassian applications right from your JIRA instance!

  All you need is an Application Link between the host JIRA, where the plugin is installed, and other supported applications.

  Products: JIRA, Confluence, FishEye, Crucible   Categories: Collaboration, Integration   Free or Paid: Paid via Vendor
• 

  Buccaneer

  by Julien Hoarau

  Lets you navigate your source code on Stash as a pirate on the high seas.

  Products: Stash   Categories: Source Code & Version Control   Free or Paid: Free
• 

  Compass – The UI Extension

  by aevolu – Andreas Spall

  Feel free to try my plugin if you want one of the following functionalities. See directly which field has the focus. Get context sensitive field description / help. Use a wizard to create issues.

  Products: JIRA   Categories: Custom Fields, Service & Help Desk, Themes & Styles   Free or Paid: Free
• 

  DocMiner 2

  by DocMiner

  DocMiner is an amazing bridge between enterprise documents and IT processes.

  Products: JIRA   Categories: Collaboration, Document Management, Image, Visualization & Reporting, Integration, Project Management, Requirements   Free or Paid: Paid via Atlassian
• 

  HTTP Request Workflow Function

  by hasCode.com

  This plugin adds a configurable postprocessing workflow function to a Jira instance that is able to pass workflow specific parameters in a HTTP request to a specified target host.

  Products: JIRA   Categories: Workflow   Free or Paid: Free
• 

  JEditor

  by PluginFactory software

  JEditor is an add-on for JIRA that renders Rich Text Editor for text area fields like Description or Comment. JEditor is a painless way to create and edit your JIRA issues.

  Products: JIRA   Categories: Admin Tools, Collaboration, Custom Fields, Document Management, Integration   Free or Paid: Paid via Atlassian
• 

  KCF-Additional custom fields

  by Kepler-Rominfo

  Kepler Custom Fields is a suite of free custom fields that we found very useful when working with JIRA.

  Products: JIRA   Categories: Custom Fields   Free or Paid: Free
• 

  Profields

  by DEISER

  Profields is the way created by deiser to solve JRA-1991. Many companies need to have project-level information according their policies, standards or procedures. If you are using JIRA as your Project Management Tool, or as part of your CMMi supporting tools or many other scenarios, you will probably have to store information about the whole project; in fact about each of all your projects. With Profields you will get it.

  Products: JIRA   Categories: Admin Tools, Custom Fields, Gadgets, Project Management, Testing & QA   Free or Paid: Paid via Atlassian
• 

  Scroll Versions

  by K15t Software GmbH

  Deliver great documentation for your products! With Scroll Version you can manage and author multiple versions of the documentation in one Confluence space, improve content re-use, and use permalinks and duplicate page titles (!).

  Products: Confluence   Categories: Build, Release & Deploy, Collaboration, Document Management, Project Management, Requirements, Source Code & Version Control, Testing & QA, Themes & Styles, Workflow   Free or Paid: Paid via Atlassian
• 

  Table Grid Editor

  by iDalko

  The table grid plugin is a JIRA custom field plugin allowing you to view and edit database data in a tabular fashion. It allows you to store detailed information in an external database while keeping process related information within JIRA.

  Products: JIRA   Categories: Custom Fields   Free or Paid: Paid via Atlassian
• 

  Timesheet for JIRA

  by i4ware Software

  A Timesheet for JIRA Plugin.

  Products: JIRA   Categories: Project Management, Worklog & Time-tracking   Free or Paid: Paid via Atlassian

Check out more Codegeist add-ons at http://codegeist.com. Help out your favorite developers by rating and reviewing their add-ons.