6

I'm looking into options for a new architecture solution for an API layer. We have decided to use dotnet core, and we'd like to have each part of our app's functionality broken into microservices. We use azure devops to handle the build/test/release CI/CD workflows.

Based on a broad analysis, I'd estimate our current back end solution could be broken out into 10-15 seperate microservices. Unfortunately, most of these would have a similar back-end dependency, but I'd still like to break them apart so we could isolate unit testing, have smaller CI/CD footprints, and have the project start with a solid separation of concerns.

However, at the same time, I'd like to avoid having 10-15 different git repos, solutions, and CI flows to facilitate this workflow. This would become a bit of a nightmare for ease of development, to have devs regularly needing to change workspaces (the 'Open Recent' list in any IDE would completely overflow!), maintaining and syncing 10-15 CI/CD.

The ideal result in my eyes would be a single solution, git repo, and build process with each microservice separated as a project within the solution. When code gets committed, I'd like to fire a process in Azure devops that would only build/test/deploy those services that were changed in the commit.

Is this possible or am I dreaming? I have not had much luck with Google but maybe I'm not entering just the right phrase for this...

Thanks in advance!

Will P.
  • 8,437
  • 3
  • 36
  • 45
  • I'm glad to see this question exists without being closed and flagged (which is what I've come to expect with architecture or 'off-topic', 'non-code' questions such as this.) Not to mention, there are (2) viable answers. – darlirium Sep 15 '20 at 13:23

2 Answers2

1

We are in roughly similar situation, and decided to host our microservices (with shared DB, unfortunately) in single git repo, but each one having it's own solution. Each API has it's own build definition and each build definition has it's own trigger with path filter. I would imagine that this approach works even if the API's are in the same solution: create separate builds with the path filter in the trigger targeting the folders where each API's source code is in the git repo. When several API's change, only the builds targeting those folders start. See Build Pipeline Triggers in Azure DevOps docs.

I'd advice putting some thought on how you want to track the releases, as you'll end up with 10-15 release definitions. Tracking them separately (to see which builds you have running in a certain test environment) is a bit of a pain, and I haven't yet figured out a good way of doing a dashboard that would show all the releases deployed to a certain environment/stage.

JukkaK
  • 1,105
  • 5
  • 15
0

We're using microservices approach with all the projects in one solution (there're shared projects and projects-services run as a separate service). To achieve the behavior that the only needed service is rebuilt, we've set it up in the YAML script, for example:

trigger:
  branches:
    include:
      - master
  paths:
    include:
    - MyService/*

....

steps:
- script: dotnet publish ././MyProject/MyProject.csproj --configuration $(buildConfiguration) --output $BUILD_ARTIFACTSTAGINGDIRECTORY
- task: PublishBuildArtifacts@1

Then after the build, the appropriate artifact is created which then can be referenced in a deployment script.

Max Zhylochkin
  • 79
  • 1
  • 5