How Should I Set up JIRA Agile for a Software Project Based on Microservices?

I'd like to start using JIRA at my company to introduce some agile practices, but our app's architecture doesn't seem to fit nicely into JIRA's project types. Are there resources to guide me through project and board setup?

Essentially I need to track issues and features in 20-30 small microservices. These services don't need their own projects, and they are all interconnected.

5 answers

2 votes

Standard answer for this one would be to use the "components" field for naming the microservices.  You can display it on cards and use it in filters to make it easier to see what is going on with them.

This is what I was going to suggest. Components are the right fit for this workflow.

How do you version them individually if the Version field is at Project level?

You don't - that's what the discussion was about really.  If you have the need to version all your components, then you probably want to convert each component into a separate project.

Hi, we are facing a similar issue and have tried components but tracking versions and triggering Bamboo builds seems to go out of the window. For example we have 20+ services that can be deployed individually so have their own versions. When we have a feature it can mean changes to multiple services so we break it down into tasks for each service. When the tasks are complete I'd like to be able to assign it to a version and trigger the build, but as far as I'm aware we can't. So, sorry to hijack this question but I think I'm after the same thing, has anyone else experienced this and managed to find a workaround? At the moment I'm looking at having a project per service so at least I can track versions and trigger builds.

0 votes

>For example we have 20+ services that can be deployed individually so have their own versions Then each one is probably best represented as a project, and you use Epics and/or issue links to go across projects.

Thanks Nic, That's exactly what we're proto-typing at the moment :) The Business requirements are raised in Business Requirements projects and tasks, improvements etc are created in Database/Service Projects and linked to the Business Requirements. We should have it setup (issue types, workflows etc) some time next week.

Hi Mj - I was wondering if you could provide an update as to how this worked for your organization?  Was the proto type successful and still in use?  Any pro's / con's or modifications you made.  We are debating giving this a shot, but concerned with the management overhead.

Alternative approach with projects:

  1. Pick a project that has a "solid" setup that your team has used/refined
  2. Copy all project configuration schemes (Workflow, Screen, etc.) and rename them to something useful ("Microservice Workflow Scheme", etc.)
  3. When creating new microservice projects, use the above scheme configurations.
  4. If you're using Scrum boards, create a board that displays tasks from all projects. Use epics to link related stories/tasks together.

We're doing something similar to this.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 13, 2019 in Jira

Make your Atlassian Cloud products more secure: our NEW admin security guide

Hey admins! I’m Dave, Principal Product Manager here at Atlassian working on our cloud platform and security products. Cloud security is a moving target. As you adopt more products, employees consta...

600 views 0 12
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you