devopsy.kinsta.cloud

Tag: Atlassian

Atlassian Aims to Improve Collaboration With DevOps Teams

At an Atlassian Presents: WorkLife event today, Atlassian furthered its efforts to integrate the tools technology and business professionals use to manage processes.

Erika Trautman, general manager and vice president of product for Work Management for All at Atlassian, said that as organizations increasingly rely on digital processes to engage customers, partners and employees, the need to facilitate collaboration across a diverse set of knowledge workers is becoming more pressing.

As part of that effort, Atlassian is now making generally available a Smart Links capability within the Atlassian platform. Smart Links can be used to integrate both Atlassian applications such as Trello and Jira as well as third-party applications. That capability is now critical because there has been a Cambrian explosion of adoption of software-as-a-service (SaaS) applications that all need to be integrated into a common set of workflows, noted Trautman. Otherwise, each SaaS application environment becomes yet another walled garden that prevents any meaningful collaboration, she added.

In addition, the company announced that Atlas, a directory that tracks projects and simplifies communications across teams using disparate applications, will become generally available next month. DevOps teams, for example, will be able to synchronize Jira events with projects being tracked via the Atlas platform.

Atlassian has also streamlined the tools it provides to reduce the number of steps required to administer its applications and onboard new users.

Finally, the company also has launched Atlassian Together, a single subscription offering through which organizations can license its Trello, Confluence, Atlas and Jira Work Management applications delivered via the cloud. An enterprise organization with more than 5,000 users can now, for example, license those applications for $11 per user.

Atlassian is making a concerted effort to enable organizations to more easily collaborate at a time when they have become more dependent on software than ever, noted Trautman. In many cases, businesses are now trying to adjust to the rapid rate at which software is being delivered thanks to the adoption of DevOps best practices, she noted.

As such, there is a greater need for integration between tools such as Jira that development teams use to manage projects and a wide range of tools used by knowledge workers residing in various departments, said Trautman. In effect, Atlassian is trying to enable organizations to reduce the “collaboration tax” they incur as workflows span multiple silos, she added.

In fact, in many cases, organizations are struggling to keep pace with how agile software development teams have become. The irony is that not too long ago business executives routinely complained about how long it took IT organizations to adjust as business conditions changed. Now, many businesses are rolling out additional digital capabilities via software updates that can be made multiple times a month.

The rate at which organizations will collaborate across departments will naturally vary, but the days when each department was a fiefdom unto itself are coming to an end. The challenge and opportunity may now be determining how modern organizations should be structured once it becomes easier to collaborate.

September 29, 2022
Why You Should Rip Up Your Org Chart and Reorganize Around Value Streams
To compete in the digital economy, teams must optimize both efficiency and effectiveness–it’s a tough ask. The traditional dominator hierarchy is a problem because organizations that use command and control create silos and handoffs that stifle innovation at the team level. Coordinated autonomy releases the creative spirit of individuals–but how can leaders assure alignment with their vision?

One way to eliminate the delays and waste associated with silos and foster autonomy is to arrange around value streams. A value stream is anything that has a customer or anything that delivers a product or a service. All value streams begin with ideas and end when a change is delivered. Or, even better, when our cherished customers realize the intended value outcome. The original intent of Agile was to provide “value” to our customers faster … but we hardly ever talk about what this value is or measure its existence.

Traditional organizational charts arrange resources according to expertise. This means that work is handed off to different teams as it progresses through the value stream. Value streams exist whether or not people call them that and whether or not they actively manage them. Every time a hand-off occurs, it creates an opportunity for delays or errors. It also means it’s hard for people to understand the end-to-end system. Instead, they do as they are told to optimize their piece of the puzzle without really understanding how their actions impact work that’s upstream or downstream.

More progressive ways of working, like Agile and DevOps, do promote cross-functional, autonomous teams, but they typically leave a big gap between planning and delivery and are not always smart at connecting feedback from customer experience back into planning. Value stream orientation promotes team diversity by recognizing the individual background (cross-functionally) into the value delivered to the customer.

Organizing around value streams is the foundation for nurturing the value stream-centric ways of thinking and working that drive both efficiency and effectiveness. Then, customer experience is improved and higher levels of organizational performance are achieved. This is because:
- Putting customer experience front and center brings higher retention and referral rates
- Elevating the concept of flow (see below) gives teams permission to prioritize removing waste
- Balancing innovation with improvements reduces technical debt, toil and unplanned work so employee experience is better, too
- Connecting planning to delivery to feedback in a continuous loop aligns teams and helps with decision-making
Flow is about how fast ideas can move through a value stream and be made available to the people they’re designed for. It’s about outputs and efficiency. Customer experience tells teams about the outcomes of their work and their effectiveness. Used together, these measures ensure the teams are doing the right things right and moving in the right direction.

In this model, leaders share their authority and empower their teams. They support teams’ self-discovery of improvements and make sure those local learnings go global. They help their teams understand how much time they spend innovating compared to reacting or improving. Then the leaders can help their teams reduce distracting and stressful unplanned work and instead invest in increasing capacity for innovation in the future.

Follow these steps to become a value stream-centric organization:
1. Identify your value streams
2. Identify who is involved in each step of your value stream
3. Make your value stream visible by visually collaborating with your value stream team
4. Use tooling to gather value stream data and generate insights for your team
5. Meet regularly to inspect and adapt your value stream
All organizations are composed of value streams, regardless of whether they have been made visible, and most large organizations have complex networks of interconnecting value streams. These dependencies are not easily decoupled. They’re not easily visible, either. But once you’ve mapped them, you can start seeing where they connect and manage the dependencies. Ultimately the goal is to break these dependencies since they cause delays and risk, but it’s hard to do that when they can’t be seen.

Connecting the organizational vision with the value streams becomes much easier with this model. Organizational structures are flattened. Leaders understand which value streams they are accountable for and how they work. The time between having an idea and getting feedback on how it’s received is shorter and amplified. They can see the work being done, measure what impact it’s having and make better decisions about what to innovate or invest in next.
August 11, 2022
Atlassian Bitbucket CI/CD Cloud Service Aims for the Enterprise

Atlassian today outlined its strategy to increase the appeal of the Bitbucket continuous integration/continuous delivery (CI/CD) cloud service among enterprise IT organizations. Atlassian said it plans to focus on four core pillars: Performance, management, extensibility and security and compliance, starting with an update scheduled for the third quarter.

Dan Tao, head of engineering for Bitbucket Cloud and Compass at Atlassian, said the overall goal is to make it simpler to use the Bitbucket Cloud service running on the Amazon Web Services (AWS) cloud at scale as organizations increase the rate at which they build and deploy software.

Atlassian is still supporting the Bitbucket Server and Data Center editions of the platform, but it’s apparent more organizations are shifting software development to the cloud, he noted. Atlassian is now moving to not only simplify migrations to the cloud by, for example, providing a Bitbucket Cloud Migration Assistant tool, but it is also moving to ensure applications can be developed at scale.

Achieving that goal includes making use of a more advanced diff algorithm that is four times faster in larger DevOps environments, he added.

Other planned enhancements include the ability to execute CI/CD workflows via Bitbucket pipelines, the ability to reuse multi-step pipelines across repositories, tighter administration integration with other Atlassian applications, the ability to encrypt data at rest and integration with the Snyk tool for discovering vulnerabilities in software to improve security.

Finally, the Bitbucket Cloud service will also soon support Bitbucket Mesh, a distributed storage capability that is already employed in Bitbucket Data Center.

Overall, Atlassian sees the migration to the cloud as a means to not only make DevOps workflows more accessible to a wider range of organizations, but also give organizations that have already invested in DevOps the opportunity to streamline those processes, said Tao.

Many DevOps teams today maintain complex platforms with custom integrations that they need to maintain and support. Atlassian provides DevOps teams the option to either employ an integrated platform or use connectors it has created as part of the Atlassian Open DevOps framework to make it simpler for teams to use whatever mix of tools they prefer, he added. In either case, the total cost of maintaining a DevOps environment can be significantly reduced, said Tao.

It’s not clear to what degree organizations that have already invested in DevOps are considering replacing their existing CI/CD platforms. However, as the pressure to accelerate the rate at which software is built and deployed steadily increases, the pressure to further automate DevOps workflows also builds. At the same time, DevOps teams are now being asked to integrate security gateways that require additional custom integrations within legacy platforms that they would need to support alongside existing integrations.

At the very least, more organizations than ever are weighing their DevOps options. The issue, of course, is that the total cost of switching out DevOps platforms is not inconsequential given the current dependency on existing workflows.

July 19, 2022
What SREs Can Learn From the Atlassian Outage of 2022
What happens when the tools and services you depend on to drive site reliability engineering turns out to be susceptible to reliability failures of their own? That’s the question teams at about 400 businesses presumably asked themselves in the wake of a major outage in Atlassian Cloud. The incident offers a number of insights for SREs about reliability risks within reliability management software itself—as well as how to work through complex outages efficiently and transparently.

What Caused the Atlassian Cloud Outage?

The outage, which began on April 4 and finally resolved April 18, affected about 400 Atlassian Cloud customer accounts. Atlassian Cloud is a hosted suite of popular Atlassian products including Jira and OpsGenie. The outage meant that affected customers could no longer access these tools or the data they managed in them.

According to Atlassian, the problem was triggered by a faulty application migration process. Engineers wrote a script to deactivate an obsolete version of an application. However, due to what Atlassian called a “communication gap” between teams, the script was written in such a way that it deactivated all Atlassian Cloud products, not just the obsolete application.

To make matters worse, the script was apparently configured to delete data permanently, rather than mark it for deletion, which was the intention. As a result, data in affected accounts was removed permanently from production environments.

The Good, the Bad and the Ugly

The Atlassian Cloud outage may not be the very worst type of incident imaginable—failures like Facebook’s 2021 outage were arguably worse because they affected more people and because service restoration was complicated by physical access issues—but it was still pretty bad. Production data was permanently deleted and hundreds of enterprise customers experienced total service disruptions that have lasted several days and counting.

Given the seriousness of the incident, it’s tempting to point fingers at Atlassian engineers for letting an incident like this happen in the first place. They seem to have written a script with some serious issues, then presumably deployed it without testing it first—which is exactly the opposite of what you might call an SRE best practice.

On the other hand, Atlassian deserves credit for responding to the incident efficiently and transparently. Although the company was silent at first, it ultimately shared details about what happened and why even though those details were a bit embarrassing to its engineers.
Crucially, Atlassian also had backups and failover environments in place, which it used to speed the recovery process. The major reason why the outage lasted so long, the company said, is that restoring data from backups to production requires integrating backup data for individual customers into storage that is shared by multiple customers, a tedious process that Atlassian apparently can’t perform automatically (or doesn’t want to, presumably because it would be too risky to automate).

Unfortunately for impacted customers, it does not appear that any fallback tools or services were made available while they waited for Atlassian to restore operations. We imagine this poses more than minor issues for teams that rely on tools like Jira to manage projects and OpsGenie to handle incidents. Perhaps those teams stood up alternative tools in the meantime – or perhaps they crossed their fingers, hoping their project and reliability management tools would come back online ASAP.

Takeaways for SREs From the Atlassian Outage

For SREs, then, the key takeaways from this incident would seem to be:

Always perform dry runs of migration processes in testing environments before putting them into production. Presumably, if Atlassian engineers had tested their application migration script first, they would have noticed its flaws before it took out live customer environments.

Back up, back up, back up—and make sure you have failover environments where you can rebuild failed services based on backups. While this outage is bad, it would be 100 times worse if Atlassian couldn’t restore service based on backups and data had been lost permanently.

Ideally, each customer’s data should be stored separately. As we noted above, the fact that Atlassian used shared storage seems to have been a factor in delaying recovery. That said, it’s hard to fault Atlassian too much on this point; it’s not always practical to isolate data for each user due to the cost and administrative complexity of doing so.

SRE teams would do well to think about how they’ll respond if their reliability management software itself goes offline. For example, it might be worth extracting and backing up data from your reliability management tools so you can still access it if your tool provider experiences an incident like this.

Over-communicate with your customers often and early. In this case, there was initial radio silence that left customers in the dark. Most of this chatter eventually took place in public forums.
Conclusion

The Atlassian Cloud outage is notable both for its length and for the fact that, ironically, it took out software that teams use to help prevent these types of issues from happening at their own businesses.

The good news is that Atlassian had the necessary resources in place to restore service as quickly as possible. A shared data storage architecture led to slow recovery, which is unfortunate; again, it’s hard to blame Atlassian too much for not setting up dedicated storage for each customer.
May 19, 2022
Atlassian Expands DevOps Tools Portfolio to Improve Collaboration

Atlassian has added an extensible catalog for tracking software components, dubbed Compass, to its portfolio of DevOps tools along with an Atlassian Data Lake and Atlassian Analytics cloud service that makes it simpler to aggregate and query data collected from the company’s portfolio of tools.

In addition, Atlassian is making its Atlas collaboration framework—formerly known as Team Central—formally available in beta. That framework, in effect, provides an overlay through which different collaboration tools adopted by various DevOps teams can be more easily integrated.

Compass provides DevOps teams with the ability to map all the components they use to assemble their software as well as the teams that own them. DevOps teams can access shared components and documentation along with scorecards to allow them to measure and evaluate their architecture based on the baselines, security or compliance requirements they might be required to meet. It can be extended to other applications via an integrated Apps engine using Forge, the existing Atlassian cloud development environment.

Tiffany To, head of product for Agile and DevOps at Atlassian, said Compass is designed for DevOps teams that are typically trying to manage 50 or more microservices. It is designed to be deployed alongside the Jira project management software that is widely used by software development teams to manage multiple projects.

Atlassian Analytics, meanwhile, is based on a visualization and analytics platform the company gained last year with the acquisition of Chartio. Initially, the Atlassian Data Lake will include data from Jira Software and Jira Service Management tools with support for additional Atlassian platforms planned.

Collectively, these tools are part of an ongoing Atlassian effort to make it simpler to integrate multiple DevOps teams, said To. Many of those teams prefer to maintain autonomy over the tools they select. The challenge that creates is organizations need some type of overlay through which they can collaborate and share best practices, she said.

A survey of 2,000 developers conducted by Atlassian found half of the respondents exercise strong autonomy over the tools they use, with more control over tool selection gained as developers become more experienced. The same survey also found that 65% of developers felt they should be responsible for more of the software product life cycle than they currently are.

It’s apparent that most organizations building software are trying to strike a balance between developer autonomy and centralized control. Developers are expensive to hire and retain, so there is a natural tendency to make available the tools they prefer. That, however, can lead to a level of tool sprawl that makes it difficult to determine the overall state of application development and deployment within an organization.

Regardless of the approach, the need to remove as much friction as possible from DevOps workflows is clear, especially as the number of simultaneous application development projects continues to multiply. The challenge and the opportunity, of course, is achieving that goal while keeping developers happy.

April 11, 2022
Atlassian Survey Shows Lack of Collaboration in Software Development

A survey of 750 IT and engineering leaders found that while a full 83% of respondents agree that interdepartmental communication is critical for successful software development, only 41% of respondents view cross-collaboration to be a priority.

The survey gathered responses from within organizations that generated more than $50 million in annual revenue and was conducted by Forrester Consulting on behalf of Atlassian.

Overall, more than two-thirds of respondents (68%) said more departments than ever are involved with software development. Overall, 80% said they need to improve collaboration with other departments, but 82% don’t feel particularly confident about their ability to accomplish that goal. Three quarters (75%) also noted the need to improve collaboration within their own department.

Well under half of the respondents (42%) said their culture, processes and tools enable the real-time teamwork and free-flowing information that help leaders make sound decisions.

Among the subset of respondents that are highly collaborative, however, more than (53%) said they see greater customer satisfaction, with 59% reporting increased revenue because of that increased customer satisfaction.

Suzie Prince, head of product for DevOps at Atlassian, said the challenge organizations face is finding a way to successfully employ a mix of synchronous versus asynchronous communication mediums to better enable collaboration. In fact, collaboration as part of any DevOps culture needs to be a C-level discussion to consistently accelerate the rate at which software can be developed and deployed, she added. The core issue is that not every management team is equally comfortable with open communications between the various departments that make up an organization, said Prince.

It’s critical for C-level executives to set that tone and lead by example; DevOps best practices can’t only be adhered to by development teams. The entire business needs to embrace DevOps best practices as an operating model for the business to really attain the maximum benefit.

Unfortunately, DevOps practices within development teams have been unevenly adopted, so it’s often very difficult to get the rest of the business to embrace DevOps principles. Organizations that do embrace DevOps, however, tend to be much further down the path toward becoming a digital business and can more adroitly take advantage of business opportunities as they arise or shift strategy as changing business conditions may warrant. In fact, organizations that embraced DevOps best practices arguably fared better during the economic decline that followed the onset of the global COVID-19 pandemic that took every business and IT leader by surprise.

It’s not clear from the Atlassian survey results if a DevOps divide is starting to emerge that makes some organizations more competitive than their rivals. In theory, at least, if every organization is now a software company that happens to build something or deliver a service, then the faster they can reliably build and deliver applications the greater the competitive advantage they can attain and sustain.

There are, of course, a whole host of factors that determine how competitive any organization might be. However, in the age of digital business transformation, it’s clear that being able to build and deploy software at a fairly regular cadence is the new table stakes required for simple survival.

October 20, 2021
Atlassian Delivers on Forge App Dev Platform Promise

Atlassian this week made available a Forge platform for building applications that complements its existing portfolio.

Mike Tria, head of platform engineering for Atlassian, said Forge is intended to provide an application development environment to both IT organizations and third-party partners. It provides developers with access to an integrated Atlassian DevOps toolchain to accelerate testing, deployment, debugging and to capture log data, added Tria. Forge also presents developers with a command line interface through which they can be onboarded to the Atlassian cloud where Forge runs to access documentation and application samples. It uses OAuth 2.0 to ensure applications deployed on the Atlassian cloud only access data they have permission to access.

The overall goal is to provide developers with a more modern application development environment as an alternative to the application development platform the company previously made available.

Once an application is built, developers can then publish their applications on the Atlassian Marketplace as free or commercial offerings. There are already more than 3,500 Forge apps that were created during a beta process that began late last year. Forge will soon be extended to the rest of the Atlassian portfolio, noted Tria.

Forge is intended to complement an Open DevOps initiative launched earlier this month that tightens integration between the Jira project tracking and management tools provided by Atlassian and a wide range of other tools commonly employed by DevOps teams. The goal is to not only make it easier to correlate issues that are listed in Jira with artifacts found in various software platforms, but also to collect data from DevOps tools to automatically update Jira.

That data will then be employed to inform key performance indicators (KPIs), based on graphs that Atlassian provides within Jira, to keep track of value streams. Rather than having to acquire a separate value stream management (VSM) platform to track software development progress, the insights needed to understand the impact of, for example, a delay to one project becomes a dividend of using Jira.

Like most providers of software-as-a-service (SaaS) applications, Atlassian has been making available a platform for building applications on top of the same platform it employs to build its own applications. Atlassian claims there are more than 1,200 partners building applications in addition to internal IT that teams that have built custom extensions to its applications. Atlassian has already shown a proclivity for acquiring independent software vendors (ISVs) that build applications on its platform. As part of the overall Forge initiative, Tria said Atlassian will be working more closely to identify the white space that won’t be addressed by the Atlassian product roadmap at some future date.

In the meantime, independent software vendors and internal IT teams will need to determine to what degree they will prefer to stand up their own application development environment versus opting to be dependent on Atlassian. In theory at least, applications built on Forge should be more tightly integrated with the rest of the Atlassian portfolio. The only potential downside is, of course, any potential conflict that might emerge with a provider of an application development platform that also happens to sell application software.

May 27, 2021
Atlassian Extends Open DevOps Ambitions

At an online Atlassian Team 2021 event this week, Atlassian launched a two-pronged effort to provide organizations with more insights into software development workflows constructed using tools from multiple vendors.

Suzie Prince, head of product for Atlassian, said an Open DevOps initiative will tighten integration between the Jira project tracking and management tools provided with Atlassian and a wide range of tools commonly employed by DevOps teams. The goal is to not only make it easier to correlate issues that are listed in Jira with artifacts found in various software platforms, but also to collect data from DevOps tools to automatically update Jira.

That data will then be employed to inform the key performance indicators (KPIs), based on graphs that Atlassian provides within Jira, to keep track of value streams. Rather than having to acquire a separate value stream management (VSM) platform to track software development progress, the insights needed to understand the impact of, for example, a delay to one project becomes a dividend of using Jira.

At the same time, Atlassian is moving to making it easier for other stakeholders in an organization to track software development projects. A Jira Work Management application is specifically designed for business users that require a higher-level tool to track projects. At the same time, Atlassian revealed this week it has acquired ThinkTilt, a provider of low-code application development tools optimized for Jira.

Atlassian for the first time this week revealed that half of Jira users are not software developers. As organizations increasingly appreciate the degree to which they are now dependent on software to drive digital business transformation initiatives, Atlassian is adding a set of project tracking applications designed specifically for users that need to consume Jira data in a more intuitive fashion.

Prince said Atlassian is committed to making it simple to replace one DevOps tool integration for another with a single click. Rather than requiring organizations to standardize on a single DevOps platform, Prince added that developers will be able to continue to rip and replace tools and platforms as they see fit without compromising visibility into application development workflows.

In addition, the integrations being provided by Atlassian will reduce the time and effort required to configure all the tools that make up a DevOps workflow, from roughly 60 steps today to about six.

As DevOps workflows become more pervasive, the way organizations operate is fundamentally changing. Formal product launches are giving way to a steady stream of software updates that add new capabilities to any platform with little to no fanfare. End users ranging from sales teams to custom support personnel now need to track updates to platforms more closely as new capabilities are continuously added.

Of course, not every organization has the same level of maturity. However, as competitors start to add new features to rival offerings, it is now only a matter of time before most business processes – that increasingly revolve around software updates – begin to evolve and change. As the pace of software development continues to accelerate, the pressure on legacy business processes will only continue.

April 30, 2021
Atlassian’s Shift to the Cloud Gets Underway

Atlassian today announced the general availability of Cloud Enterprise, a cloud-based service through which organizations can mix and match the company’s various offerings under a single subscription.

The company has signaled its intention to shift toward cloud services for months; now, the initial Cloud Enterprise subscription will cover the company’s Jira Software, Confluence and Jira Service Management offerings.

Bala Venkatrao, head of product for Enterprise Cloud at Atlassian, said the goal is to make it more cost efficient for organizations to consume the company’s software versus merely acquiring a license to deploy software in an on-premises IT environment.

The company is also making controls available that enable governance of user and change management via a centralized admin hub. Administrators can assign users to instances, configure security policies and monitor usage trends through the hub. There are also built-in integrations with third-party identity-as-a-service providers, to enable administrators to automate provisioning and de-provisioning.

Administrators can also set up and customize multiple application instances; they can keep data pinned to different regions to customize those instances with specific marketplace applications or configurations for compliance purposes.

Finally, a marketplace will allow IT organizations to expand the number of applications they consume from Atlassian and its partners. A smart links and app switcher capability for Jira and Confluence Cloud enable easy collaboration across different instances of Atlassian applications.

Atlassian currently has more than 194,000 customers, so it may take some time to transition the existing installed base to this model. In the meantime, Atlassian is pushing as many new customers as possible toward a cloud platform that makes it easier for Atlassian to keep customers current on the latest release of its software. Atlassian plans to support up to 20,000 users per application instance by later this year.

Venkatrao said while the Atlassian portfolio is frequently consumed by individual end users, the Cloud Enterprise offering is designed to appeal to CIOs, and other senior level executives, that want to centralize billing for application services now accessed via the cloud. That approach will make it easier for large organizations to take advantage of discounts they may qualify for as overall usage increases, Venkatrao said.

While Atlassian may be a little late to the software-as-a-service (SaaS) application game, Venkatrao noted that the Cloud Enterprise platform will make it simpler for Atlassian to apply AI to the metadata it will collect. Atlassian has already leveraged AI to improve document search within Confluence and Jira, in addition to employing predictive analytics to surface recommendations for including personnel on a project.

It may be a slow transition to the cloud for Atlassian, but that transition is clearly underway.

February 2, 2021
Atlassian Unfurls Bevy of DevOps Updates

Atlassian today made a dozen updates to its DevOps portfolio as part of an effort to better unify workflows spanning disparate tools.

Suzie Prince, head of product for Bitbucket at Atlassian, said the latest updates are intended to enable DevOps teams to streamline workflows without requiring everyone in the organization to standardize on the same set of tools.

Updates to the Atlassian DevOps portfolio include DevOps Automation Triggers, which makes it possible to create automation to keep development activities synchronized, such as reassigning issues surfaced in the Jira project management application from Atlassian to code review or sending a message to a Slack channel.

The Bitbucket repository from Atlassian has also been updated to make it easier and faster to review code changes after a pull request. New features such as a consolidated list of tasks, integrated Jira issue creation and activity feed filters make it possible for developers to complete their code reviews faster and juggle multiple pull requests at once, said Prince. A Your Work dashboard in Bitbucket Cloud has also been expanded to include assigned Jira issues.

The Atlassian VS Code integration is also being made available to make it easier for developers who use the Microsoft integrated development environment to more easily track and visualize Bitbucket Pipelines.

A Code Insights in Bitbucket Cloud has also been added to bring scanning, testing and analysis tools into the code review process, including Mabl for test automation and Sentry for automated monitoring. Bitbucket is also now providing integration with Snyk scanning tools to make it easier to discover vulnerabilities.

Available in a preview mode is an automated change management capability across Jira Service Desk Cloud and Bitbucket Pipelines that can be used to pause CI/CD processes, create a change request in Jira Service Desk and trigger deployment once it is approved.

A Risk Assessment Engine in Jira Service Desk Cloud also allows IT teams to score the risk of a change and automatically approve and deploy low-risk changes. A Change Management View has also been added to Jira Service Desk Cloud to streamline approvals for high-risk changes by pulling all of the relevant information together in traceable change requests.

Atlassian has also tightened integration between its Opsgenie incident management software and Bitbucket Cloud to centralize alerts and filters. Via an Incident Investigation Dashboard, members of a DevOps team can look at the deployment that happened right before the incident, add it as a potential cause, and contact the developer who made the change if it needs to be rolled back.

The company has also extended integrations with Slack and Statuspage to facilitate both members of DevOps teams and external stakeholders.

Finally, Atlassian is making available a resources hub to make it easier to share DevOps best practices, templates and guides.

Prince said it’s not ever going to be feasible for most organizations to standardize on one set of DevOps tools. The goal should be to enable organizations to construct DevOps processes in ways that allow developers to employ whatever tool is their favorite at the moment. Only then will organizations get developers to buy into a DevOps process that doesn’t necessarily change the way they are most comfortable working, she noted.

The challenge, of course, is often getting IT leaders to be as equally comfortable with what, from their perspective, might be an experiment in controlled chaos.

June 2, 2020