The following content was taken from Atlassian.com  

In this the first of a three part blog series which focuses on migrating the Jira code base from Subversion to Git. We wanted to share Atlassian’s 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.

Atlassian has been extremely excited about DVCS for a number of years and has invested heavily in DVCS. Atlassian has acquired Bitbucket – a cloud DVCS repository host, developed Stash – a behind the firewall Git repository manager and added DVCS support to FishEye, Atlassian’s code browsing and search tool. They have also added a myriad of DVCS connectors to Jira.

Along with Atlassian we believe DVCS is a great leap forward in software development. As part of this, Atlassian migrated the codebases for their own products and libraries from centralized version control systems (generally SVN) to DVCS. Some of these have been big migrations!

In this three part blog series we will  focus on the biggest migration Atlassian has done – migrating the 11-year-old Jira codebase from SVN to Git. What obstacles did they encounter? What lessons did they learn? And most importantly, how did they do it without sacrificing active development on Jira? We hope that sharing this experience helps anyone approaching a similar migration.

We’ll focus on Git, because Jira moved to Git, but everything in this series applies equally to Mercurial. At Atlassian, they use both.

Why DVCS?

Migrating a big code base is not without cost. The first thing you will need to answer – both for yourself, your bosses, and the people who work for you – is what will DVCS bring us, and why is it worth the cost of migrating?

We have used SVN successfully on many projects.  So has Atlassian.  And I am sure many people reading this article have also used SVN successfully. Since there is always a cost to migration, you may be inclined to ask, “If Subversion has met my version control needs for many years, why should I change?” To me, that is the wrong question. The real question is, “How can DVCS make what we do today even better?”

Git is known for several things.  For a developer working with code, it’s faster.   It allows for advanced workflows like feature branching, forks and pull requests – in theory, these workflows are all possible with SVN, however the difficulty of merging in SVN compared to Git makes them untenable.  But for anyone moving from SVN, the main benefit of Git is that because of its lightweight branching and easy merging, Git allows you to do your default SVN workflow better than SVN.

What do we mean by this? Let’s talk about how we actually develop and release software. Most of us work in a world where we have at least one released version of our software in the wild, which we call a “stable” branch. We maintain and contribute bug fixes to a stable branch while developing new features on a “development” branch (which is called trunk/master/default depending on which VCS you use).

When we commit bug fixes to stable, we need to get them into master too. SVN merge is known to be a pain and works solely on revision history – not actual content.  As a result, a lot of people avoid it, or they do it infrequently and not as part of their day-to-day workflow. How many projects have you worked on where stable and development branches have started to diverge, or diverged so significantly that the effort to bring them back together is a real project cost? Many have certainly been in projects where this has happened, and when we speak to other developers it’s a frequent occurrence with SVN. There are some strategies to deal with it.  For example, with Atlassian’s issues and tracking software, Jira, they ignored merging and required developers to make each commit individually to each stable and development branch, relying on QA to make sure that it happened correctly.

Git allows you to remove this pain. Git makes merging so easy that merging the entire stable branch into the development branch on each commit is a reality; it’s now Atlassian’s default workflow. So even if you don’t want to use feature branches or forks or pull requests immediately, Git provides advantages from day one.

And when Atlassian was ready, they were in a position to take advantage of the advanced workflows that Git allows. Before the switch to DVCS, Atlassian’s major products targeted 90-day release cycles. These 90-day releases went to two platforms: downloadable products for clients to install on their own servers; and a release to Atlassian’s  hosted cloud platform (Atlassian OnDemand) for which clients pay a monthly fee. Using branches as a core part of development workflow has allowed Atlassian to shorten this to the point where they now release major products to the cloud every 2 weeks.

The Switch

Jira is a decent size code base to move – 11 year’s worth of history, 47,228 commits across approximately 21,000 files. Atlassian averages about 30 different committers over a two-week period. More than that, the VCS is a real work-horse for a project like Jira. Builds, code reviews, scripts for releasing both product distributions and source… all these things have a rich tapestry of dependencies on the source code management system.

Their main goal in the migration was to minimize interruption to developers. This is about more than just the ability to commit code; it is about the infrastructure surrounding software development.

Atlassian has 3.5 years of history in Jira’s code review system.

Jira has a lot of CI. Atlassian runs approximately 60 build plans over different configurations and branches.

They have some other dependencies too – Jira has a somewhat complex release process that involves pulling together code from multiple sources. Atlassian also releases their source code to customers, which involves a different set of build scripts.

There is a tradeoff here between how fast you can migrate and how stably you can do it – Atlassian’s guiding principle was to optimize for stability over speed. If you set a deadline for your migration and it slips, what’s the worst that happens? Developers have to commit code to SVN for another week or so. Not the end of the world. It’s far worse if the migration interrupts developers’ ability to work and meet their own deadlines.

In the end, the migration took 14 days in total, with only a total of two hours where developers were unable to commit code. Atlassian were nearing the end of the development cycle for their latest release, Jira 5, and at no point were they unable to cut a release candidate.

Preparation

When preparing the migration, there are a couple of things to be aware of.

First, it will take time. The actual git-svn clone, which takes all of the commits in the SVN repository and replicates them in Git, took three days for Atlassian.

Second, you should prepare and think of all the dependencies your infrastructure has on your VCS. And know that if your infrastructure is sufficiently complex (like Atlassian’s), there will be things you never dreamed of and only discover when they break. So don’t beat yourself up when you encounter a dragon. Just slay it, and continue on your quest.

A migration like this is not something you can do overnight, or even over a weekend. It needs to be managed for a sustained period of time.

Migration – The Technical Side

Stably migrating is daunting but it is not brain surgery; there is a process Atlassian has employed to make it manageable. In part 2 of Atlassian’s Switch to Git series we walk through, step-by-step, the technical details on migrating from Subversion to Git.

Our monthly webinars are designed to help you become proficient with the entire Atlassian product suite. Wether you want to convince your team to adopt Jira or are in search of some handy tips and tricks for End Users and Administrators, our webinars are designed for any skill level.

Praecipio Webinars

• Blog:
  Unflipping the Table with Portfolio for Jira
• Blog:
  DevOps: an interpersonal approach
• Blog:
  Automation with Jira Service Desk
• Blog:
  The Intranet is Dead
• Blog:
  The Ultimate Incident Management Solution: Jira Service Desk
• Blog:
  Your Greatest Asset During a Major IT Outage
• Blog:
  Reduce IT Alert Noise and Streamline Your Service Desk Solution
• Blog:
  Build A Better Service Desk and IT Alerting Solution
• Blog:
  New Year, New You with Jira Service Desk
• Blog:
  Portfolio for Jira: Best Practices
• Blog:
  Turbo Kit for Jira Webinar
• Blog:
  2017 Atlassian Summit Wrap Up
• Blog:
  Project Management with Atlassian & Tempo
• Blog:
  Achieving World-Class CI/CD
• Blog:
  DevOps with Atlassian

The following content was taken from Atlassian.com:

One of the turning points for communication in the workplace was the invention of email. Historically it’s been the easiest way to make contact in any business relationship – short, pointed conversations with the teammates you work closest with, or quick messages to people you’re communicating with for the very first time. You could say it changed the way we all work. Since its inception, however, the notion that email is also a good channel for team collaboration is what’s holding us all back.

Email is great for communication, but not collaboration…

Email is an effective means for communication, but when it comes to collaborating with your team on projects and getting work done, it’s a major hindrance to your team’s productivity.

• Group conversations grow unwieldy too quickly
• Keeping track of the most current version of an attached document is the modern-era’s needle in a haystack
• It’s nearly impossible to maintain clarity about what needs to get done, and by whom

At the end of the day, when it comes to collaborating with your team, email wastes A LOT of your time.

Don’t get us wrong, email is not all bad. It’s really effective at quickly and effortlessly communicating with others, but it just doesn’t scale. When it comes to productively working together with your team, it fails to help you get the job done. Here are three reasons why we feel email is killing your productivity.

1. Your email inbox is a lot like quicksand

You receive a ton of email each day (yeah, like you didn’t already know that!) – some of it’s important, some actionable, some is SPAM, and some is unavoidably pointless. As a result your mornings go wasted in your attempt to reach inbox-zero. It’s a losing battle. Each time you take a step forward, you take two back. You’ve likely tried all the organizational features your email client has to offer to control your inbox – labels, filters, multiple inboxes, smart inboxes – but at the end of the day, your morning consists of at least an hour of unavoidable email ground-and-pound. You also probably manage emails when you get home at night and even first thing in the morning when you wake up just to keep your head above water. I’m preaching to the choir here, right? The fact is that this is the norm these days and hardly leaves you anytime to get real work done.

Pro-Tip: Use the ‘Four D’s of Decision-Making’ model

According to a article published by Microsoft, of the email you receive:

• 50% can be deleted or filed
• 30% can be delegated of completed in less than two minutes
• 20% can be deferred to your Task List or Calendar to complete later

With this in mind it’s good practice to decide what to do with each and every email you receive – you have 4 choices:

• Delete it
• Do it
• Delegate it
• Defer it

2. Your email inbox silos your team’s tacit knowledge

Email is regularly used to share and discuss work, but that doesn’t mean its supposed to. Attaching files and documents or linking to them via shared network drives makes for a complete mess. Countless versions of shared files and relevant follow-up conversations are trapped in email inboxes everywhere. Your inbox is a graveyard for valuable tacit knowledge, knowledge that gets buried deeper and deeper every minute of every day. It’s truly criminal.

So, what’s the real problem? Email is a tool that best serves simple communication, not discussion, and certainly not collaboration either. When you send an email asking someone to review your work, the most valuable piece of information being transferred is not the file itself, but the ensuing conversation. Regardless of the fact that it’s incredibly difficult to find this email in your own inbox later, no one else outside of the email thread has the opportunity to benefit from this transfer of knowledge, keeping stakeholders in the dark.

3. Switching context between work and email wastes a lot of time

The rate at which most people check their email is astonishing – it’s practically become a nervous twitch. Just like Pavlov’s dog, your email has you trained incredibly well.

The problem with checking your email so much is that you rarely have a solid block of time to get any real work done. Take into consideration that if you’re actually checking your email 36 times an hour, and it takes 16 minutes to refocus after handling an incoming email, your workday is basically non-existent.

Switching contexts is distracting, if not annoying, and your email is the number one culprit – destroying the focus you need to get your job done well.

Pro-Tip: Practice Timeboxing to increase personal productivity

Thanks to email, staying on track at work is nearly impossible. Timeboxing is a time management technique that limits the time during which a task is accomplished. Start with 25 minute intervals. Work on a task for 25 minutes, take a 5 minute break, then commit to email for 25 minutes, and finally take another 5 minute break. Repeat. Focus. Flourish.

If 25 minutes sounds like a lot of email time, it sure beats checking your email 36 times in a single hour. At least with Timeboxing you can put all of your energy both into your work and email respectively.

Is there a solution?

We’ve outlined the major problems with using email to collaborate with your team, and even provided a few tips to help avoid the daily snags of collaborative emailing, but these are just simple workarounds. They don’t necessarily get at the core of your problems, which is that email is not the best solution for team collaboration.

OK, we are Atlassian Experts so we’re obviously biased, but we encourage ut clients to use Confluence and HipChat, Atlassian’s team collaboration and group chat tools, as means to reach decisions faster with less email and fewer meetings.

Dot ‘.’ and Comma ‘,’ shortcuts

Take your fingers off that mouse! These keyboard shortcuts will help you become a Jira speedster, and get your co-workers to ask “Whoa, how’d you do that?”

Dot Dialog

When your on the Issue Navigation screen or viewing an issue, pressing ‘.’Will bring up an operations dialog menu.

From here, start typing the first few characters of the operation you wish to use.  For example, if you are viewing an issue and want to close it, simply type ‘.’ then ‘close’.

Here is a list of operations you can access using the dot dialog:

• Start Progress — Set the issue’s Status to In Progress.
• Resolve issue — Set the issue’s Status to Resolved and select the appropriate Resolution.
• Close issue — Set the issue’s Status to Closed and if the issue has not already been Resolved, select the appropriate Resolution.
• Reopen issue — Set a Resolved or Closed issue’s Status to Reopened.
• Edit — Edit the issue’s details (Summary, Description, etc).
• Assign — Select an asignee for the issue.
• Assign To Me — Assign the issue to yourself.
• Comment — Add a comment to the issue.
• Log Work — Record the work done and time spent on the issue. This option is only available if Time Tracking has been activated on your Jira site.
• Attach Files — Select a file, upload it and attach it to the issue.
• Attach Screenshot — Select a file, upload it and attach it to the issue.
• Voters — Opens the Voters list of the issue, where you can manage your vote and see others who have voted on the issue too.
• Add Vote — Adds your vote to the issue. (This option is only available if you did not create the issue.)
• Watch Issue — Become a watcher of the issue.
• Stop Watching — Stop watching the issue. (This option is only available on issues you are currently watching.)
• Watchers — Opens the Watchers List, where you can manage watchers of the issue.
• Create Sub-Task — Create a new issue which is a sub-task of the issue.
• Convert to Issue — If the issue is a sub-task, convert it to a standalone issue.
• Convert to Sub-Task — If the issue is a standalone issue, convert it to a sub-task.
• Move — Move the issue to a different project.
• Link — Create a link between the issue and another issue. This option is only available if Issue Linking has been enabled on your Jira site.
• Clone — Create a new issue which is an identical copy of the issue.
• Labels — Edit the issue’s labels.
• Delete — Permanently remove the issue.

(Note that some options in the menu will only be available if the operation is relevant to the issue, if you have the necessary permissions, and if certain features have been enabled by your Jira administrator.)

Comma Dialog

Similarly, if you are viewing an issue, pressing ‘,’ (available in Jira 5.1 or greater) will bring up the Go To Field popup.

Use the popup to edit issue fields in-line, without leaving the page. The following fields are available for editing:

• Assignee
• Summary
• Issue Type
• Priority
• Component/s
• Affects Version/s
• Fix Version/s
• Reporter
• Description
• Labels

Tune in next month

We’ll be delivering you tips and tricks every month, so make sure to keep you eyes peeled next month for another handy Jira tip. If you found this helpful, please visit Atlassian University - interactive tutorials and videos with tons of tips just like this one.

Jira’s an issue tracking application, but its core flexibility and strengths mean it can become much more than a tool limited to a development group. Jira’s incredibly adept at helping teams track and accomplish tasks. Jira also has a masterful ability to manage life cycles - and it’s found great success in numerous use cases.

Use Cases

The following use case guides are meant to explain a bit of the details related to using Jira for a specific use case. The info you’ll find in here highlights much of what we’ve learned from working with clients in a variety of different industries, as well as our internal expertise and use of Jira.

For each of these use cases, we’ll attempt to highlight:

• Particular Jira functionality specific to the use
• Related plugins we’re aware of
• Customization and tweaks
• …and sometimes a sample file to help get you started

Agile Software Development

• Agile Development Solution Tour
• Using Jira for Agile Development

Project Management

• Using Jira for Project Management
• Jira for Project Management sample file

HelpDesk / Support / Trouble Ticketing

• How to setup Jira for support
• Use case and sample file: Jira for Helpdesk/Support Sample File

Test Case Management

This can be done by using either of the following approaches:

• Use case and sample file: Integrate Jira With A Test Case Management Tool

Requirements Management

• Use case: Using Jira for Requirements Management

Change Management

• Use case: Using Jira for Change Management

by Ashley Furness

CRM Market Analyst, Software Advice
June 27, 2012

During our last Atlassian User Group meeting a few attendees asked us for pointers on how to convince their managers to implement or expand upon the Atlassian product suite as a Business Process Management Tool. To us the task seemed easy, especially since Process Optimization and Management are some of our founding principles.

After doing a bit of research we were a bit surprised by what we found. According to a study conducted by the Journal of Information & Management, 71% of executives had negative feelings concerning IT as a source of competitive advantage.

This is especially shocking since exploiting current capabilities while simultaneously developing new ones is a common theme among organizations. This idea serves as a baseline for strategic management and is crucial for adapting to changing environments. It’s through this delicate balance of business activities that the notion of Business Process Management (BPM) was born.

As BPM continues to be considered an important way for organizations to achieve a competitive advantage, senior management should be aware of IT’s ability to facilitate these processes. However, as the study pointed out, this isn’t always the case. In many organizations senior management’s reluctant to promote the strategic role of IT and instead, consider it just an automating tool.

This notion’s not only outdated but it also negates the entire philosophy of BPM, and the idea of developing new organizational capabilities.

So how can you overcome these seemingly insurmountable sentiments, standing in the way of cost-cutting, Business Process Optimization? According to the study, executives were most likely to be convinced of the almighty powers of IT when provided with substantial evidence of the following outcomes:

• Assurance in the success of process re-engineering
• Greater simplification in business process
• Increased efficiency by at least 50%

So whether you are attempting to convince a coworker, boss, or yourself, being well armed with relevant examples of the above will come in handy.

Looking for relevant examples? Try the following case studies:

• Why did SAFMT go Jira?

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.

Read more about DVCS & multiple repo support here: What’s New in Bamboo 3.3

Tasks

All your builders and post actions are belong to us Tasks.  Tasks are the granular steps that make up your Plan: checkout source code, call MSBuild, execute a script… etc.  Your existing builders were converted to Tasks as part of the BoD upgrade, and we think you’ll find it to be a great usability improvement.

Read more about Tasks here: Configuring 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. 

Read more about Manual Stages (and other cool features) here: Bamboo 3.2 Release Notes

Plan Branches

For a couple of years, the developer community has been complaining that using short-lived branches to build new features simply doesn’t play nicely with continuous integration.  We’ve taken a big step toward proving them wrong.  As soon as Bamboo knows there’s a new branch in your repo, it will clone any associated Plans and point them at the new branch.  Branches are automatically discovered in Git & Mercurial repos, with auto-discovery for SVN coming soon. Très facile!

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!

About Dashboards and Gadgets

The Jira Dashboards is the first screen you see when you log in to Jira. It can be configured to display many different types of information, depending on your areas of interest.

If you are anywhere else in Jira, you can access your Jira Dashboards view by clicking the ‘Dashboards‘ link in the top left corner of the Jira interface.

The information boxes on the dashboard are called Gadgets: 

If your user account has only one dashboard, the tabs on the left of the browser window will not be available and the dashboard will occupy the full window width.

 

You can easily customise your dashboard by choosing a different layout, adding more gadgets, dragging the gadgets into different positions, and changing the look of individual gadgets.

You can also create more pages for your dashboard, share your pages with other people and choose your favorites pages, as described in Managing Multiple Dashboard Pages. Each page can be configured independently, as per the instructions below.

 See the big list of all Atlassian gadgets for more ideas.

* This gadget will only be available if it has been installed by your Jira administrator.

 

The Firebug add-on for Firefox can significantly degrade the performance of web pages. If Jira is running too slowly (the Jira dashboard, in particular) then we recommend that you disable Firebug. Read this FAQ for instructions.

 

Creating a Dashboard

The dashboard that you see when you first start using Jira is a “default” dashboard that has been configured by your Jira administrator. You cannot edit the default dashboard; but you can easily create your own dashboard, which you can then customize as you wish.

To create your own dashboard:

1. At the top right of the Dashboard, click the ‘Tools‘ menu.
2. Select either ‘Create Dashboard‘ to create a blank dashboard, or ‘Copy Dashboard‘ to create a copy of the dashboard you are currently viewing.

You can now customize your dashboard as follows:

 

If you are using multiple dashboard pages, you can only configure dashboard pages that you own.

 

Choosing a Dashboard Layout

To choose a different layout for your dashboard page (e.g. three columns instead of two):

1. At the top right of the Dashboard, click the ‘Edit Layout‘ link. A selection of layouts will be displayed:
   
2. Click your preferred layout.

Adding a Gadget

1. At the top right of the Dashboard, click the ‘Add Gadget‘ link.
2. A selection of gadgets will be displayed:
   
    Select a category on the left to restrict the list of gadgets on the right to that category.
3. Click the ‘Add it now‘ button beneath your chosen gadget.
4. Click the ‘Finished‘ button to return to your Dashboard.
5. If the gadget you have selected requires configuration, you will be presented with the gadget’s configuration page. Configure appropriately and click ‘Save‘.

Moving a Gadget

To move a gadget to a different position on your dashboard:

• Click the gadget and drag it into its new position.

Removing a Gadget

To remove a gadget from your dashboard:

1. Hold your mouse over the top right corner of the gadget, until a down-arrow appears.
2. Click the down-arrow to display the following menu:       
   
3. Click ‘Delete‘.

We’re excited to announce the availability of Jira 5.1!

Jira 5.1 introduces a number of new capabilities for new and existing customers:

Inline Edit for Jira Issues

In Jira 5.0 Atlassian took the first step in making Jira easier and easier for end users – with new, fast Create and Edit dialogs.  In Jira 5.1, field edits, transitions, comments, and all your Jira actions can happen faster than ever.  With inline edit, any Jira field can be edited from the View Issue Page. The speed at which users work in Jira is dramatically changing on a daily basis.

Performance enhancements for large Jira instances

We know this is a big one for many of our largest clients. In Jira 5.1 two teams have been dedicated to performance: a Jira performance improvements team and a company wide Atlassian Performance Engineering team, specifically focused on Jira performance for large instances above 200,000 issues. Atlassian’s repealed the 200,000 issue limit as a result of the improvements, including a 40% improvement in throughput.

Issue Collector

The Jira Issue Collector lets you embed pre-configured or custom feedback forms into any web application or web site, so you can collect feedback, and use Jira to assign feedback items, or put them through workflow.  If you’re looking for a great demo for Jira, the Issue Collector is a great one: how to expose the power of Jira in a simple manner to people both inside and outside of an organization.

Lots More

And 5.1 comes with a whole lot of other enhancements: Disabling users, automatic time zone detection, improved search for Jira to Jira Remote Issue Links, and more than 42 new feature requests implemented and over 840 votes fulfilled.

When it comes to IT, why do most organizations focus more on the T in technology than the I in information? The purpose of a good IT infrastructure’s to prevent information asymmetry and the implications that come with it. By properly managing your company’s information network you can create value through better decision-making.

Information asymmetry occurs when one party has more or less information than another. This can result in bad decision-making, and at times, unethical decisions. Regardless of the industry you operate in, treating information as an economic resource allows your business to yield higher than expected payoffs, resulting in a competitive edge.

The need for better collaboration both within and across business processes is a problem our clients come across often. Luckily the solution’s one we pride ourselves on offering.

Atlassian’s Confluence serves as an organizational wiki, connecting employees to information and each other. Confluence allows users to create, share, discuss, and discover documents, ideas, Jira issues, specs, mockups, projects – anything. By connecting your entire business in one place, Confluence allows for better integration. We love it and so do our clients!

Seven weeks ago the world met Stash – a centralized solution to manage Git repositories behind the firewall. Stash 1.0 was a huge launch! Atlassian’s been deluged with great feedback and already have small agile teams and large enterprises adopting Stash for their Git development.

Atlassian’s just getting started, and today Stash’s future begins! Stash 1.1 is here with more features focused on making your behind the firewall Git development simple, secure and fast.

SSH Support

Developed from the ground up with enterprise level security as a #1 priority, Stash now supports SSH in addition to HTTPS. Use standard HTTPS authentication or set up your public keys and connect to Stash via SSH, it’s your choice. This resolves Stash’s #1 feature request focused on adding security options to support SSH.

For those of you who chose to go the SSH route there can be some benefits for your team (depending on your setup):

• Increased security
• Ease of configuring automated systems, such as build and deployment servers (e.g. Bamboo)
• Restricted access to pushing and pulling from Stash without compromising passwords

Developers are able to manage their own SSH keys. For those using multiple machines to work with their Git repositories or several automated systems pushing and pulling from Stash they can add as many keys as they see fit. And, have no fear Stash admins, you still have full control over SSH keys with the ability to grant or revoke the SSH keys of any user.

Do you understand your Git error messages? No matter what flavor of authentication you choose, Stash makes sure you know what’s going on when things go wrong. Unlike standard Git error messages, which can be confusing and contribute to the steep learning curve, Stash will provide you with user-friendly messages.

Lean thinking allows organizations to determine value, and organize their value creation processes in a specific sequence. This fundamental understanding of the value stream allows organizations to dived their work processes into:

• Value-adding activities
• Required non-value-adding activities
• Non-value-adding activities

It’s important to note that while organizations can specify an associated value with a process; value’s inherently determined by the consumer – your organization had better have a clear understanding of what that is.

Lean thinking also affects the flow of your production processes by emphasizing a continuous product flow, pulled through by customer demand – ensuring that nothing’s built until it’s needed, and what’s built is in fact needed by its end-user. As Lean thinking’s applied to your specific business model you’ll  inherently perfect your product through the constant process of identifying and removing waste.

Lean + Agile = Better Business Practices

We prefer to look at Agile as more than just a methodology, but also as a way businesses can reduce process – generated waste and non-value-adding activities.

Think of a value system instead of a process. Software development’s too difficult to waste time pouring over things that don’t matter, and it’s extremely inefficient for the organization at hand. From this viewpoint we can apply lean thinking to Agile development.

To effectively understand the meaningful roles these approaches can have, we must first examine their application. From this point of view, Lean represents a set of principles that help guide our ideas and insights about Agile. Lean thinking should be viewed as a set of value-maximizing principles that don’t change over time, and Agile development as an application of principles to a particular situation. Agile principles are specific to each environment and should change to fit the task at hand. Here it’s easy to see how Lean thinking concepts expand upon and improve the framework of Agile methodology.

The Agile school of software development’s currently one of the most accepted methodologies for improving productivity. Targeted mainly towards IT managers and CIOs, Agile methods promote an interactive approach which have the ability to help flatten your organization’s cost of change curve.

The Manifesto for Agile Software Development was first introduced in 2001, and outlines the foundation of Agile in twelve principles:

1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Working software is the principal measure of progress
5. Sustainable development, able to maintain a constant pace
6. Close, daily co-operation between business people and developers
7. Face-to-face conversation is the best form of communication (co-location)
8. Projects are built around motivated individuals, who should be trusted
9. Continuous attention to technical excellence and good design
10. Simplicity- the art of maximizing the amount of work not done- is essential
11. Self-organizing teams
12. Regular adaptation to changing circumstances

Cost of Change Curve

First introduced by Barry Bohem in 1981, the cost of change curve represents the exponential increase in cost as it relates to making a change during the normal development phase of a product. This means that as your product moves farther down the developmental pipeline it becomes more costly to make changes and remedy errors.

That’s a good argument for Agile since it ensures you leave the current production phase with a product that’s as close to perfect as you can make it – particularly because Agile methodology calls for testing and up-front integration which translates to rapid production and minimal initial design. Since the test code’s written before functional code and automated test suites are built around the evolving code, developers are allowed to make rapid and aggressive changes.

The ability to make these changes is one of Agile’s key features and the result is a reduction in the amount of product errors late in the development phase, reducing the cost of change. Even if your organization enjoys a rather flat cost of change curve, Agile ideals can be applied to reduce the cost of change throughout the software life cycle.

Scrum

Scrum’s another widely accepted approach to implementing the Agile philosophy, which includes both managerial and development processes. This approach relies on a self-organizing, cross-functional team supported by a scrummaster and a product owner. Scrum makes your organization Agile by ensuring quick progress, continuously creating value, and by keeping projects on track. The most important concepts of Scrum are:

• Product backlog - A complete list of requirements that are not currently in the product release. Typical backlog items include bugs and usability/performance improvements.
• CI - Also known as continuous integration; allows for scrum teams to continuously integrate their work. This will often happen on a daily basis.
• User story – Describes problems that should be solved by the system being built.
• Scrummaster - The manager of the Scrum project.
• Burndown chart - The amount of work remaining within a sprint, i’s updated daily, and also tracks progress.
• Sprint backlog - A list of backlog items assigned to a sprint, but not yet completed

Kanban

Kanban means visual board – and that’s just what it is, a development process that revolves around a board to manage works in progress (WIP). A Kanban board includes “lanes,” each denoting different phases a project might take. It moves WIPs across the board and deploys them into production when they reach the done column. Since Kanban development practice revolves around WIP management each state of progress is limited to a set number of projects. Organizations able to leverage this high frequency of delivery typically enjoy a large financial benefit.  The most important concepts of Kanban are:

• Swim lanes - The horizontal lanes of a Kanban board represent the different states in which a WIP or task can exist.
• Backlog - A list of backlog items awaiting deployment, but not yet completed.
• Stories – A particular user need assigned to a development team.