DevOps with Atlassian

Team up to tear down walls

What is DevOps?

“DevOps” is a trendy word, but what does it mean? Is it a job role? A team? A tool? You’re not the only one that’s a little lost.

We believe DevOps is none of those. It’s a philosophy that values cross-team collaboration over strict areas of control, and iteration over perfection. Let’s take away the buzz and get down to the basics to understand what DevOps is really all about.

DevOps @ Atlassian

Check out this webinar recording and see how Atlassian does DevOps: a little bit of tooling, a little bit of process, and a whole lot of culture.

Watch it now

Choosing the right tools

How to shop for tools that support a culture of transparency, innovation, and cross-team collaboration.

Learn more

Inside Atlassian

"Ohhhhh $#!τ. We broke Confluence." In one of our first Confluence Cloud releases in 2016, we broke our users' ability to edit pages.

As the head of Atlassian's site reliability engineering group, this kind of thing falls right into the wheelhouse of Nick Wright. Learn how Nick and his team responded to the situation to get Confluence working again. You'll get an insider's view of our incident management process, as well as how we've configured Atlassian tools to support this work.

Read more


There's no single point in time from which we can look back and say "That's when DevOps was born!" Rather, a movement started to coalesce somewhere around 2007 - 2008, when IT/ops and software development communities got vocal about what they felt was a fatal level of dysfunction in the industry. 

They railed against the traditional software development model, which called for those who write the code to be organizationally and functionally apart from those who deploy and support that code. Developers and IT/ops professionals had separate (and often competing) objectives, separate department leadership, separate key performance indicators by which they were judged, and often worked on separate floors or even separate buildings. The result was silo'd teams concerned only with their own fiefdoms, long hours, botched releases, and unhappy customers.

Surely there's a better way, they said. So the two communities got together and started talking – with people like Patrick Dubois, Gene Kim, and John Willis driving the conversation. 

What began in online forums and local meet-ups is now a major theme in the software zeitgeist. Which is probably what brought you here! You and your team are feeling the pain caused by silo'd teams and broken lines of communication within your company. You're using agile methodologies for planning and development, but still struggling to get that code out the door without a bunch of drama. You've heard a few things about DevOps and the seemingly magical effect it can have on teams and think "I want some of that magic."

The bad news is that DevOps isn't magic, and transformations don't happen overnight. The good news is that you don't have to wait for upper management to roll out a large-scale initiative. By understanding the pillars of DevOps and making small, incremental changes, your team can embark on the DevOps journey right away. Let's start with the CALMS framework.

First described by John Willis and Damon Edwards in 2010, CALMS stands for Culture, Automation, Lean, Measurement, and Sharing. Let's talk about each in turn.


If we could sum up DevOps culture in one word, it'd be "collaboration" – and if we were allowed two words, they'd be "cross-functional collaboration." (Ok, that's more like three words.) 

All the tooling and automation in the world are useless if they aren't accompanied by a genuine desire on the part of developers and IT/ops professionals to work together. Because DevOps doesn't solve tooling problems. It solves human problems. It's unlikely you'll poke your head out of the cubicle one day, look around, and discover that teams at your company embody DevOps culture. But there are simple things you can do to nurture it.

Think of DevOps much like agile, but with the operations included. Forming project- or product-oriented teams to replace function-based teams is a step in the right direction. Include development, QA, product management, design, operations, and any other skill set the project requires. At Atlassian, we even embed marketing with our product teams. Few things foster collaboration like sharing a common goal and having a plan to reach it together. 

At some companies, switching suddenly to project-based teams is too much, too soon. So take smaller steps. Development teams can – and should – invite appropriate members of the operations team to join sprint planning sessions, daily stand-ups, and sprint demos. Operations team can invite key developers. It's an organic way keep on the pulse of each other's projects, ideas, and struggles. The time spent listening and cross-pollinating subject-area knowledge pays for itself by making releases and emergency troubleshooting far more efficient. 

And speaking of emergencies, they're an effective test of DevOps culture. Do developers, operators, and customer support swarm on the problem and resolve it as a team? Does everyone start with the assumption that their teammates made the best decisions possible with the information and resources they had at the time? Is the incident post-mortem about fixing processes instead of pointing fingers? If the answer is "yes," that's a good indication that your team functions with DevOps culture at its core. 

Note that the most successful companies are on board with DevOps culture across every department, and at all levels of the org chart. They have open channels of communication, and talk regularly. They make sure everyone's goals are aligned, and adjust as needed. They assume that keeping customers happy is just as much product management's responsibility as it is the development team's responsibility. 

They understand that DevOps isn't one team's job. It's everyone's job.


Investing in automation eliminates repetitive manual work, yields repeatable processes, and creates reliable systems.

Build, test, deploy, and provisioning automation are typical starting points for teams who don't have them in place already. And hey: what better reason for developers, testers, and operators to work together than building systems to benefit everyone?

Teams new to automation usually start with continuous delivery: the practice of running each code change through a gauntlet of automated tests, then packaging up successful builds and promoting them up toward production using automated deploys. As you might guess, this is not a quick and easy thing to set up, but the return on investment is well worth it.

Why? Computers execute tests more rigorously and faithfully than humans. These tests catch bugs sooner, allowing developers to fix them more easily. And the automated deploys alert IT/ops to server "drift" between environments, which reduces or eliminates surprises when it's time to release. 

Another of DevOps' major contributions is the idea of configuration as code. Developers strive to create modular, composable applications because they are more reliable and maintainable. That same thinking can be extended to the infrastructure that hosts them.

True, systems are always changing. But we can create a facade of immutability by using code for provisioning so that re-provisioning a compromised server becomes faster than repairing it – not to mention more reliable. It reduces risk, too. Both developers and IT/ops professionals can incorporate new languages or technologies via the provisioning code, and share the updates with each other. Compatibility issues become immediately apparent, instead of manifesting in the middle of a release. 

Configuration as code and continuous delivery aren't the only types of automation seen in the DevOps world. But they're worth special mention because they help break down the wall between developers and IT/ops professionals. When they use automated deploys to send thoroughly tested code to identically provisioned environments, "Works on my machine!" becomes irrelevant.


When we hear "lean" in the context of software, we usually think about eliminating low-value activities and moving quickly – being scrappy. Even more relevant for DevOps are the concepts of continuous improvement and embracing failure.

A DevOps mindset sees opportunities for continuous improvement everywhere. Some are obvious, like holding regular retrospectives so your team's processes can improve. Others are subtle, like A/B testing different on-boarding approaches for new users of your product.

We have agile development to thank for making continuous improvement a mainstream idea. The success of early adopters proved that a simple product in the hands of customers today is more valuable than a perfect product in the hands of customers six months from now. If the product is improved continuously, customers will stick around.

And guess what: failure is inevitable. So you might as well set up your team to absorb it, recover, and learn from it (some call this "being anti-fragile"). At Atlassian, we believe that if you're not failing once in a while, you're not trying hard enough. We challenge our teams with big, hairy, audacious goals and make sure they have the autonomy and the resources to meet them. We hire smart, ambitious people and expect them to fail sometimes.

In the context of DevOps, failure is not a punishable offense. Teams assume that things are bound to go pear-shaped at some point, so they build for fast detection and rapid recovery. (Read up on Nexflix's Chaos Monkey for an excellent example.) Post-mortems focus on where processes fell down and how to strengthen them – not on which team member f'ed up. Why? Because continuous improvement and failure go hand in hand.


It's hard to prove your continuous improvement efforts are actually improving anything without data. Fortunately, there are loads of tools and technologies for measuring performance like how much time users spend in your product, whether that blog post generated any sales, or how often critical alerts pop up in your logs.

Although you can measure just about anything, that doesn't mean you have to (or should) measure everything. Start with the basics:

  • How many story points did your team complete this sprint?
  • How often do recurring bugs or failures happen?
  • How long does it take to recover after a system failure?
  • How many people are using your product right now?
  • How many users did you gain / lose this week?

With a solid foundation in place, it's easier to capture more sophisticated metrics around feature usage, customer journeys, and service level agreements. The information you get comes in handy when it's time for road mapping and spec'ing out your next big move. A word of warning, however: data is highly addictive (wink).

All this juicy data will help your team make decisions, but it's even more powerful when shared with other teams – especially teams in other departments. For example, your marketing team wants shiny new features they can sell. But meanwhile, you're seeing high customer churn because the product is awash in technical debt. Providing data that supports your roadmap - even if it's light on features and heavy on fixes - makes it easier to get buy in from stakeholders.


The long-standing friction between developers and IT/ops professionals is largely due to a lack of common ground. We believe that sharing responsibility and success will go a long way toward bridging that divide.

Developers can win instant goodwill by helping to carry one of IT/ops' biggest burdens: the pager. DevOps is big on the idea that the same people who build an application should be involved in shipping and running it. This doesn't mean that you hire developers and simply expect them to be excellent operators as well. It means that developers and operators pair with each other in each phase of the application's lifecycle.

Teams that embrace DevOps often have a rotating role whereby developers address issues caught by end users while, at the same, troubleshooting production problems. This person responds to urgent customer-reported issues, creating patches when necessary, and works through the backlog of customer-reported defects. The "developer on support" learns a lot about how the application is used in the wild. And by being highly available to the IT/ops team, they build trust and mutual respect.

Slogging through the rough patches together makes celebrating successes all the more sweet. You'll know DevOps culture has taken hold at your company when you see a developer bring in bagels for the operations team on release day.

Positive feedback from peers motivates us as much as our paychecks and career ambitions. Publicly recognizing a teammate who detected a nasty bug before it went live means a lot. If your department has discretionary budget for employee kudos, don't let it go unused!

The future of DevOps

The gains teams have made in quality, time to market, and employee happiness mean DevOps is here to stay. We believe companies that value transparency and collaboration will continue to produce the best products and lead their industries.

Given the pace at which technology is changing, it's nearly impossible to predict what the state of automation or monitoring might be ten years from now. But one thing is certain: technical problems will always be human problems at their core. DevOps' focus on people and process means it will remain relevant for the current generation of software makers, and the generations that follow.

Staff picks


Is your team ready for DevOps?

We keep hearing the success stories from Flickr, Netflix, and Etsy. But we don't hear about how the transformation happened. If you're on a DevOps journey of your own, here are three things you need to know about the road ahead.

Read more


How to enhance IT support with DevOps

Adopting DevOps improves service quality, team morale, problem-solving and business productivity. In this ebook, IT service expert John Custy shows you how to apply DevOps principles to your IT support team.

Read more


Love DevOps? Wait 'til you meet SRE.

A growing movement called Site Reliability Engineering (SRE) effectively ends the age-old battles between Development and Operations. SRE encourages product reliability and innovation.

Read more