#release-engineering (2023-04)
All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.
CI/CD Discussions
Archive: https://archive.sweetops.com/release-engineering/
2023-04-24
Hi all, had an interview today and got an interesting question that i would like to hear what are you think about it … theres a 100 repositories, 99 of them are microservices , 1 one of them is a nuget package repository (all of the services are dependent on this package) if someone changes the first repo, how would you deploy all of the rest of the microservices? For me it was unreasonable question since i thought to myself .. each developer should update the depndency version of his microservice… just want to hear your opinion on this
If I was answering what I wonder the interviewer wanted I’d use a CI tool (in my case Github actions) to trigger a PR creation against all the dependant repos but yeah I do agree, I maintain a couple of internal packages and unless it’s a security fix all I do is announce a new version and let dependant teams pick up the new release as and when they need to. Sec fixes I’ll work more closely with but that happens very rarely
@Jacob Amar You can achieve this using Terrafile. First, update the first repo then deploy with versioning, then create a terrafile inside each project/micro service with the source and version of the first repo. Each time deploy a micro service from the 99, the micro service will pull the latest version of the first repo.
@Jacob Amar I think your perspective is correct. The shared library owner/changer should notify consumers of the package but the consumers should opt in either optionally or with notice. Forcing services to opt in could lead to breaking changes for “major version” releases. I do think this question was misinterpreted or there is some mismanagement on the their end.
Thanks everyone