I will show you how I setup the YAML build in Azure DevOps for our Mono repository that contains multiple (20-ish) Services that are part of one Pr...
For further actions, you may consider blocking this person and/or reporting abuse
This is gold mine of an article (i went through the process of password reset, just to leave this comment)
Thank you Praneeth :)
TBH, we are moving now in another direction. We will reduce the number of services and make them appropriate size. Plan is to have super-clean pipeline for each of them without too much "magic".
Maybe you should also take that into consideration.
Maybe you shouldn't try to resolve a problem that shouldn't be there in a first place.
Choose your "weapon of choice" wisely :)
I think this is a cool solution. But I have a question is how you deal with it now, do separate pipelines work better, how you set them up for monorepo?
This is a geeky solution :) Since I left the company, I can only tell you what I suggested to the Team - think very thoroughly what should be in one logical service and then put that in one repository.
Create CI/CD on top of it for each deployment unit (physical service), if you have more than one at all; make it simple, fast, have great unit tests.
If currently several services just handle some parts of the same domain, make 1 service out of them with modules (dev.to/nikolicbojan/your-clean-arc...)
In general - I went with monorepo due to the fact there was a small team handling a lot of services. Thing is that there was no need for so many services in the first place. I didn't tackle the entire problem, I swapped it for a smaller problem to enable Team to work faster, but that was not a complete solution.
TBH, I am thinking about deleting this article or at least putting a big warning sign on the start that this was an experiment that proved not to be a great solution :)
Hello and thanks for the share.
Can you elaborate a bit more about the fact that it's not a great solution.
Today, we have a micro service architecture tiddly bound and we are doing PR in 30 min (build / quality / iac / deployment). It's a way too long and building / testing only what has been touched in the context of the PR seems to be the only way to go...
Hi Cedric, sorry for late response - vacation :)
Building just the things that changed is the way to go, but I no longer think it is good to have one repository and one complex build script that is aware of too many things.
If you have properly separated services, put them in the separate repositories and create CI and CD for each. Treat them as truly separate.
In the meantime, I found a YT channel that has majority of answers I learnt the hard way explained in a small 10 minutes videos - youtube.com/channel/UC3RKA4vunFAfr...
Are you referring to a specific video in the channel ?
Thanks for your answer !!
Hi Cedric, I was not referring to a particular video as Derek talks a lot about interesting subjects like Architecture, Loosely coupled monolith, CQRS...
I do not know how many services do you have, how they are communicating, etc. and therefore I think these short lessons from Code Opinion could give you some interesting ideas.
Maybe you can reduce number of services (if you have too many and struggle) by making them more coarse grained? Maybe you have somewhere sync communication between them, that should be avoided, for sure. Maybe... to many unknowns :)
Hope you will find there some good explanations. BR!
Thanks for sharing!
How did you manage versioning for each service?
I'm currently using "version\version.txt" with in each service Subfolder.
That file is edited by the Product Owner who owns "major.minor."
The build adds the 3rd position "build" as a counter that resets to 0 (for any change to version.txt)
Thoughts?
Hi David,
We had
version.txtfor .NET Framework projects, but for Core we kept version incsprojfiles. I didn't like the option with the file, but it was "if it works...".Since you have a non-tech person deciding on the version, maybe it would be good to move those values in some variables in Azure DevOps, so that it more PO-friendly :)
Ideally, you would use some simple option for versioning like github.com/adamralph/minver that could help if you see versioning as a pain point that just drains your time.
Oh, just one more option for versioning, similar to MinVer - Nerdbank.GitVersioning and a nice article bu Damien damienbod.com/2020/04/20/add-git-t...
Great article! Just a question regarding the Model Nuget, you mentioned "I decided to move them to a Service's solution as they represent the interface for that Service", does that mean that the models are in its own solution? Thanks in advance.
Thank you Robert!
Model for a particular Service is located in a folder where that Service is. It is included in that Service solution, but can be also added as Existing project in other solutions.