We've got a system called Foo hosted as a repository in Github.

The system depends on a couple more microservices, called Bar and Baz. Each of these microservices is hosted as a separate repository.

We are getting lost when doing Issue Tracking since there is no single repository where the Issues live. A single Feature request might create Issues across multiple repositories, which might or might not affect the code in the main Foo project.

How can we do effective Project Management with Github's tools in these cases?

  • help.github.com/articles/… – Ewan Sep 7 '18 at 9:28
  • @Ewan Sorry for not clarifying, we don't use Projects (nor do we want to). I'm talking about Issues/Milestones/Releases. Edited the question just now. – nicholaswmin Sep 7 '18 at 9:31
  • 2
    hmm bit confused MUST use GitHub tools, but not the one specifically designed for this use case? – Ewan Sep 7 '18 at 9:37

If the different services are developed together, this can be an indication that they should really be maintained in a common repository (monorepo). Splitting your code across multiple repositories sounds clean and elegant, but in reality it often makes it hard to keep them in sync.

But let's say you don't have that option.

Then, use a separate issue tracker for cross-cutting concerns. This could be an external tool like Jira, or this could be an empty GitHub repository that you just use for the issue tracker. For the individual service repositories, you might want to keep the issue trackers for service-specific issues, or disable them entirely (you can still use pull requests).

Github's built-in issue tracker is better than nothing, but it is woefully inadequate for complex use cases. There's nothing wrong with using a different tool that fits your use case better, or using ways to extend the GH issue tracker with additional features.

| improve this answer | |
  • 1
    @Ewan Not insane, just pragmatic. Tools serve a purpose. If a single team develops a single project, it doesn't make sense to split out individual components as separate repositories. That just makes it hard to keep them in sync. It is not viable to develop a microservice as a separate project before it gets a stable, versioned API so that it can be evolved independently from its API consumers. I do not mean “monorepo” as in a Google style “all projects share one repository, even if unrelated” setup. – amon Sep 7 '18 at 11:20
  • @Ewan: please expand. I wouldn't dismiss that solution at first, and certainly not the way you did. – user44761 Sep 7 '18 at 11:20
  • 2
    @Tibo If you are a multiple-repo adherent then changing to monorepo because your project management tool has problems is the sort of thing that will make you pull your hair out. It's like.. I don't know writing down your password because security makes you change it every month. However, some people say that monorepo IS a good strategy, not just a pragmatic one for small projects. – Ewan Sep 7 '18 at 11:30
  • 1
    I definitely think monorepo is a good idea here. Coordinating merge requests across many repos is a real pain, migrating to a monorepo eliminates this issue. – Eamonn McEvoy Sep 7 '18 at 12:59
  • 1
    @anon I didn't go the monorepo route, I've created another repo exclusively for PM of the whole system. The system services are split in different GH repos. – nicholaswmin May 20 at 10:36

I have a similar situation. For issue tracking it may be best to use an external tool like Jira or trello.

Eventually I decided to merge all our projects into a single code repo, (since they all belonged to the same application). This way a merge request spanning multiple microservices can be reviewed at the same time, and you don't need to juggle many branches for one update.

| improve this answer | |

I do not think that you can somehow influence this through the Github, but if you use any sort of compilers like Composer or NPM, then they have dependencies & finds out which versions of which packages can and need to be installed.


But even here I think this is not very helpful, and it's best to look in the direction of the UnitTest, Smoke Testing, Regression Testing, Build Verification Test, Sanity Testing..

If all your code is described in the tests, then if you behave incorrectly or change the settings - you will immediately see where the problem is.

| improve this answer | |
  • 3
    Sorry, but this answer has nothing to do with what I ask. – nicholaswmin Sep 7 '18 at 11:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.