It seems that we want to allow dependencies on SNAPSHOT artifacts. This seems slightly problematic to me, as by definition SNAPSHOT don't identify a clear state of the code base. I suspect that the idea is to speed up integration by not requiring a release before cross project integration. A bit more discussion of the needs / problem we are trying to solve, and the drawbacks of the different approaches would be welcomed!
Topic on Talk:Platform Engineering Team/Event Platform Value Stream/Use case: Event Platform SDLC practices
> I suspect that the idea is to speed up integration by not requiring a release before cross project integration.
To a degree. There are cases now when we have WIP code (e.g. a flink pipeline) depending on third party WIP (e.g. upstream changes in eventutils). The integration strategy (to the best of my knowledge) is to build and integrate manually (on local checkout/builds).
That gets a bit annoying when ultimately we need to test both changes in a remote environment (e.g. a YARN cluster). The need to track changes manually (checkout and build upstream, manually integrate & deploy) adds some overhead and lengthens the feedback loop.
IMHO there are instances where not having a clean state (SNAPSHOT) might be ok, *if* we start with the assumption that things are expected to break. E.g. working in a development environment.
I worked in teams where we would automatically publish ephemeral artifacts on branch, and allow cross project development deps. This assumed:
- a degree of env separation (no integration testing in prod).
- a Gitflow-ish set of guidelines to enforce conventions (not endorsing). Both don't apply to us though, and I can see things becoming messy (SNAPSHOT state spilling to prod).
Does the above make sense? How would you model this scenario?