That sounds very similar to the process I follow where I work. We face a few unique challenges in our particular market but we're slowly working past them and changing attitudes along the way.
We're mostly a monolithic application transitioning over to small Java libraries. Because of that, we have a lot of dependencies (aka libraries) to manage. In order to address this, we pull our dependencies in via Gradle. This makes it easy to promote code in separate repositories without worrying too much about parts of a story getting ahead of the rest of the story, though that possibility is still there.
Another very nuanced and complicated issue for our particular situation is that we don't continuously deploy (currently... working towards it). We do continuously integrate, but deploying happens only after release which happens a few times a year. This is a pretty complicated issue given the customers we target, but I do feel it's the right choice (for now) given the constraints we have. As such, we don't have to worry about one part of a story going straight to prod since releasing and deploying is such a huge process at the moment.
Maybe to help understand this I should briefly describe our general process. It's pretty similar to yours:
Make sure the story is ready to be worked on and pull it in
Identify what needs to be done (db, API, core code, front-end, etc) and what libraries/repos need to be touched. Clone/update those. Create branches.
Code and test while implementing the story in each library/repo
Publish SNAPSHOT builds that Gradle can pull in
Update the Gradle file in the branch on the core repository
Inform QA of where to test
If good to go, open PR's on all the repo's touched (all other repos besides the core one)
After the PR's are merged, publish a release build of the library
Update the Gradle file in the core repo with the release artifacts
Open a PR on the core repo
After opening the PR on the core repo, the rest is automated. It'll eventually get into a "pre-release" type branch where it waits until the company is ready to release. Keep in mind that this is happening for 9 teams of 8-12 people each. Sometimes that causes issues but most of the time it runs smoothly. This process is also constantly improving. It's gotten significantly better since I started and we have goals to improve it even more.
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.
That sounds very similar to the process I follow where I work. We face a few unique challenges in our particular market but we're slowly working past them and changing attitudes along the way.
We're mostly a monolithic application transitioning over to small Java libraries. Because of that, we have a lot of dependencies (aka libraries) to manage. In order to address this, we pull our dependencies in via Gradle. This makes it easy to promote code in separate repositories without worrying too much about parts of a story getting ahead of the rest of the story, though that possibility is still there.
Another very nuanced and complicated issue for our particular situation is that we don't continuously deploy (currently... working towards it). We do continuously integrate, but deploying happens only after release which happens a few times a year. This is a pretty complicated issue given the customers we target, but I do feel it's the right choice (for now) given the constraints we have. As such, we don't have to worry about one part of a story going straight to prod since releasing and deploying is such a huge process at the moment.
Maybe to help understand this I should briefly describe our general process. It's pretty similar to yours:
After opening the PR on the core repo, the rest is automated. It'll eventually get into a "pre-release" type branch where it waits until the company is ready to release. Keep in mind that this is happening for 9 teams of 8-12 people each. Sometimes that causes issues but most of the time it runs smoothly. This process is also constantly improving. It's gotten significantly better since I started and we have goals to improve it even more.