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

[Peter Novotnak]

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.

[Nic Brough -Adaptavist-]

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.

[Robert Massaioli (Atlassian)]

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

[Rodney Joyce]

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

[Nic Brough -Adaptavist-]

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.

[Adam Kaplan]

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.

[Travis B]

We're doing something similar to this.

[Eric_Jacobson]

I've been doing this for a year or so.  It takes about 10 seconds to build a new component (e.g. microservice) jira project and update the board filter.  You can track the individual component release versions in the Fixed/Version field.  A big advantage to using jira projects mapped to components is the ability to transfer the component ownership to another dev team...which happens every now and then based on capacity.

Problem I'm colliding with now is our Product team hired some consultants to hook up Jira Align.  The consultant would rather each dev team has only one jira project on their board, and it's named after their team.

We have a ghetto workaround I'm still waiting to try.  I think Jira and Align are still catching up to microservice architecture.  People still think you do a Release at the end of a quarter.  But my engineers do it daily.

[Deleted user]

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.

[Victoria Gustafson]

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.

[Nic Brough -Adaptavist-]

>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.

[Deleted user]

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.