A PR should be for one project only
Updates to a package should be separate to updates to the consumer of the package.
If there is a bug in DAL, then it should be fixed in DAL, a PR triggers the build and its version bump, and a new package appears.
Now the consuming application can pull the package, and perform any associated updates. This is passed off in a PR which bumps its version and any subsequent packaging.
The reason is that the consuming application might not be able to transition to the new package just yet. This could be due to regulatory reasons, or to additional code changes in the consumer.
Separate Project <-> Separate Repositories
Decide whether or not the DAL is a separate project or not.
If its not, ditch the package and consume the library as built by the current check-in. Otherwise your application will be chasing its historical tail and depend on the product of an earlier commit.
If it is, re-home it in a new repository, and actually give it the independence implied by having its own package.
Quality Gates and Red Flags
Another issue is your quality gates. The quality gate for your DAL package appears to be works in the consuming app. As far as quality gates go, undoubtedly that is the end goal, but it does get you into a situation where the work done to accommodate testing, is almost the same work to incorporate the new package.
This raises a few red flags in my mind:
- The Unit/Module/Semantic Testing for DAL is not self-contained alongside the code for DAL, but spread across repositories.
- Any change to a consuming application other than bumping the version number implies:
- Functionality has been deleted, when it is still in use.
- Functionality has meaningfully changed, which is identical to having deleted the functionality and created something new with similar signatures. A source of insidious bugs.
- The consuming application was always incorrect, and as the consuming application is being used as a test, then the test was always wrong and should be fixed first (ergo the consuming application should be fixed first, by effectively making it not work with the previous package version).
- Any change to the consuming application will potentially invalidate a previously built and ratified DAL package.
Clarifying Quality Gates and Automation Goals
I would clearly define the quality gates, and potentially automate updating the dependent package.
To start with find all locations in the consuming applications that interact with the DAL, and distil those interactions into Module/Unit Tests. Make this the quality gate for building a DAL package (alongside the human quality measures such as reviews).
Once the DAL package is created, the second quality gate is to checkout the consuming application code. Update the dependency, test, and automatically generate a pull request. If your architecture permits it this could also be checked after each accepted PR to the consuming application so that if the consuming application is "fixed" it will automatically get the superior package suggested.
Devs will need to perform a PR once for non-breaking changes which should include (most) bug fixes, and extended behaviour. These correspond to patch and minor semver bumps. Simply updating the DAL will propose the update to the downstream consumers.
Breaking changes will be necessarily more involved largely because the semantics are still being defined/redefined. This however should be the exception, not the rule. These changes should be occurring under a major version bump so that the package isn't automatically applied to consuming applications.
To assist developers in updating the package, provide a means to build/test each downstream system from the main/their fork with a built version of the DAL from their fork. Extra points if it also provides build/test-results against the current published package too. This would allow the developer to know when a package is a breaking change, or not. It would also allow them to make decisions about whether or not their PRs are dependent on the new package, and thus when they can push the PR for that particular project.
