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...
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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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!