Seeking Feedback: How do you use the Components field?

[Katie Silver]

Hi Jira Software community,

Do you use the Components field in your projects? I want to hear from you!

I’m Katie from the Compass product management team. Compass is a new Atlassian developer experience platform. Compass helps you track your software components and integrate your existing toolchain to create a one-stop-shop view of your software architecture and how it’s performing.

On Compass, we use the word “Components” to describe a standalone piece of your software architecture: services, applications, libraries, APIs, data pipelines, anything your software relies on to operate.

We know many of you have been using the Components field in Jira for a variety of different use cases. Even within Atlassian, we use Components in many different ways - sometimes to categorize support tickets, sometimes to set up auto-assignment, sometimes to track projects… it’s a big, varied list.

So:

How do you and your team use Jira Components? Why did you choose Components for your scenario?

I’d love it if y’all left comments on this post, or if you’re up for a conversation, book some time on my calendar. Thanks in advance for your feedback!

Katie

Senior PM, Compass

Want to learn more about Compass? Check it out here. We’re currently in Beta with a commitment to go GA. Here's a recent announcement of all the features we launched at Team ‘23.

[David Harper]

Hey,

We use Jira Components as a way of defining sub-areas of a product, as a Jira Project represents a single product or library for us.

One Bitbucket Repository = One Compass Component = One Jira Project = Multiple Jira Components

[Mike Villis]

The component field was the original, customizable drop down field that could be updated by Project Admins without talking to a Jira Administrator! This has meant that there's many creative use cases for the field :-) 

In our company a Jira project is a team/squad which looks after one of many products/components. Components become a list of these components for the squad. This is mostly high level components. It's possible what we call a Component in Jira is slightly higher level (ie. One component may be one or many repos which would be multiple components in Compass).

[Craig Nodwell]

Hi @Katie Silver great topic.

Components... I've used them in different ways over the years. 
The last 7 or 8 with the same basic concept, sometimes with the assist of a plugin but not the now and not the always... depends on the client.
I've been doing this for a long time now, software development primarily focused on the builds and releases. NOTE: I'm not a developer I'm now called DevOps but I've had many titles through the past 30+ years.

The Concept:
Components are used as the output artifacts from the build system and input artifacts to the deployment system.  Re: What was completed during the sprints and ready for release promotions.

Current model.
Some 70 components are shared across 5 projects (updates/additions are controlled and managed via listeners for change in a core DevOps project that propagates new or updates to the other 4 projects)

Components and repository names in the version control system are directly aligned and naming conventions are important.
Development issue types (created in house for this change purpose) are restricted to a singular component based on a validator in the workflow.

Pre-Receive hooks in the version control system verify that pushes to the repository have a Jira ticket, it is a development ticket, it is in a valid status, and the component on the ticket and repository name match.

The build system reads the change log and applies a "Component Version" to the Jira ticket(s) when a packaged deployable and tagged build is completed.  Component Version and the version control tag are the same semantic version. We don't rebuild we deploy and test, then promote on success.  Those binary artifacts are retained in a repository manager for this purpose (needed step to pass Jira ID's as metadata to this binary package for retrieval during deployment process, currently an unnecessary promotional merge in the version control system is performed to handle this important part of the feedback loop.)

On promotion to Testing environments the Component and Component version are applied via the deployment job to any linked Testing tickets to verify and validate that the correct component and version are being tested.

Calendar Releases apply to 4 Sprint projects and are level set in the Release Hub in each.
A plugin for Release Management is used to align the 4 Sprint Projects into a singular release plan.
Components and Component versions are further used to gather and consolidate data based on Release that data is published to Confluence (automated on Story close to update after page create), where Tech Leads and QA leads can verify and validate changes for release promotion without bottleneck.
And then we have one more usage for this in our DORA reports for deployment frequency, as we've tied our deployment system into Jira and tied the change to the Component.

Production Support Releases are treated basically the same with the component usage, the project(s) for that work are Kanban due to the nature of their work activity, so their path comes without the complexity of multiple teams creating dependencies and different projects touching the code, since they follow a different path in the SDLC.  Not to say there is no complexity since the starting path and semantic versioning into and from the build system are different allowing us to then send that unique ID back to the Jira ticket's component so it is made obvious as per best practices.

This is the 3rd client I've implemented this model into.  With variations of course.  This current client is the first one with 4 teams using 4 projects and all touching the same code base at the same time with the potential to change what the others are expecting in their outputs.  More complexity is added trying to bring it all together with 4 different 3 week sprints and a two sprint cadence on calendar release, however things are improving release by release thanks to the component usage model that I've introduced, and the client has embraced.

I'm sure that's more than you were expecting.  
Hope my feedback helps.

[靳光光]

We have used the component just now.

Because there are some different jobs in the team, and we use it to distinguish our jobs.

But I have an request:

The word "component" is not appropriate for our scene, Is it possible that we can change the name?

[Krishnakumar Kesavan]

We use component field of JIRA to represent the different layer of software product which helps us to segregate  Let say we created the FrontEnd,,BackEnd as components and used it

[David Harper]

Hey @Katie Silver ,

For us, a Compass component represents a piece of software, be that a service that we run (web application or API usually), a library, a bit of code we plugin to something else or cloud resources. These all typically have their own repositories and build processes in Bitbucket.

A Jira Project maps to one of these components and within that a Jira Component, will break it down into domain-language sections of the application, such as "Authentication" or "Clients" section or "Feature Flags" or "Search".

[Katie Silver]

Thanks @Mike Villis

You're right, the components field has a long and storied history 😅. Appreciate you taking the time to respond. 

[Dan Breyen]

We use components in Jira for Core and Service Managment every day to assign tickets based on expertise.  It's a time saver getting issues into proper hands without having to do a lot of initial issue triage.

[Namrata Patel]

Hi @Katie Silver we use component field in Jira (for issue,bug and test cases) to defined that respective issue/bug/test case is associated with the defined component. e.g Backlogs or Active Sprints or Releases can be component for Jira.

All these components are predefined by Admin so while creating issue/bug/test case we can search and we select based on associated component.

It can be one or many components for a issue/bug/test case. 

[Katie Silver]

Definitely makes sense @Nick Jones . I think you'll like what we have in store with the expansion of the Compass + JSW integration in the near future! 

[Nick Jones]

We've used components to establish shared libraries, APIs, systems, and other types of entity at a wide range of levels / scales, across projects. We've longed for Components to be first class entities, so that we could add descriptions and versions and a range of other things related to a Component, and then select which version of a Component we were working with within one issue or another.. the idea being to track Components and their versioning across projects. In a sense, Components = Products. I guess in some sense a Component could also have its own Jira project to manage it. Yet, we'd still want to reuse that Project's definition of the Product, its Versions or Releases, and perhaps other useful information mapped as a Component... hope that makes sense @Katie Silver :) 

[Katja Kraus]

In our case, using the component field differs from project to project. However, recently we set up components in a way, to represent sub-projects of a larger initiative. There was no need to create separate projects for each, but the component field helps us easily filter and auto-assign issues to suitable leads. 

All in all, there is not a single project in which I didn't find a good use case for components.

[Katie Silver]

Hey @Stefannie Tan , thanks for your comment. That's why I'm here! I'm getting the sense that people use the Components field in a lot of unique ways. 

Our hope with our upcoming Compass integration is that we can be a bit more opinionated and helpful about how the Components field should be used. Watch this space! 

[靳光光]

Yes.

But the name "component" is not very appropriate, hah~

If the name can be changed, it will be great

[Katie Silver]

@Craig Nodwell ! Legend! Thank you so much for this detailed feedback. 

What you're describing sounds a lot like what we're building into Compass. The Release work in particular is new to me though, I'll spend some time thinking about it. 

If you do have a chance to try out Compass, I'd love to know what you think compared to your processes above. Obviously yours are more mature since Compass is still in Beta, but I think we're very aligned on the use cases. 

Thanks again! 

[Katie Silver]

Got it, that makes sense! So perhaps a Jira Component in your current setup could theoretically align to something like a Capability component type in Compass. We typically use Capabilities to describe user-facing functionality (so like a shopping cart, for example, with order management service, subscription service, invoice service, etc rolling up to it.) 

This is very helpful :) Thanks again!

[Katie Silver]

Interesting, thanks @David Harper ! Would you mind giving me an example, maybe outlining the difference you currently have between Compass and Jira components? 

[Denise Ellis]

Hi,

My feedback is this same feedback applies to Compass Components: https://jira.atlassian.com/browse/JRACLOUD-846

[Marivi Almazan]

For me the definition of components could vary depending on how you would use it because not everyone is using this for software development items alone. It's how you would like to classify and group your work. e.g. in software development = you can have UI, Database, Reports etc...  

Later on this components can be retrieved easily and can be used in filtering and queries.

[Caravan Cristian]

For me Component = Team which makes it easier to filter, and assign with the auto assign feature. You know this is Code but dont know who exactly, auto assign ssends it to the lead of the team.

[Katie Silver]

Thanks @Katja Schmitz !! Appreciate the summary! 

[Stefannie Tan]

I don't really understand the Component field and wish that I could know some best practices for its use.

[said kouzibry]

On server/Data Center, it can be changed by modifying the language pack.

[said kouzibry]

Yes that is one common way to use components, they facilitate spreading work between different teams with different skill sets.

[said kouzibry]

it can be used determine which team should the issue be assigned to, but also to help split the project into skills. for example if the feature I have to develop requires and api end point to be created, then I will create another task with the endpoint description and set it's component to "API", that way I know the correct team will be notified.