Probably will end up with a couple hundred projects in CI spread across at least 50 main applications, mostly self contained however some share a few libs across multiple projects.
Looking at a couple options. 1. Just one pair of repos (snapshot and release) everyone has read and publish to both
This is probably best, and is what we recommend to most folks IIUC.
2. One repository for each project (or maybe for each department - there is some overlap of developers across projects and departments). Everyone has read through a nexus group listing the projects snapshot and another group for release. CI tool id has permissions to publish to release and to snapshot.
Do NOT recommend this, lots of overhead to manage/maintain w/o any real value.
3. In general, should developers be allowed to push a snapshot build to nexus from their desktop or only from the ci tool?
That is up to your internal policies. I would recommend however that CI publish snapshots, but there could be a few rare edge cases where deploying a snapshot from a developer system is warranted, but only as an edge-case I’d imagine.
In general, do folks most often publish to nexus with the id of the ci build tool or under a specific user's ID (ex: the release manager person that clicks "build" on the CI job). I would imagine that the snapshot builds must use the CI tool id or be allowed for anyone since they kick off automatically based on polling the scm.
I’d recommend setting up a specific user for CI build to deploy with.
The idea is to be sure only those on a project can release and keep the overhead of configuration and admin low. The other key point is that there needs to be some ability to know who initiated the activity that resulted in a new nexus artifact.
This may depend largely on how you plan to make releases. If you have a shared machine used for this purpose and manually run the release process, you can limit access by who can login to that system. If you use build automation (bamboo, hudson, etc) then its probably a factor of who can access the projects where the release automation is performed.
If you wanted to gate releases at the nexus level, then you can use repository targets to managed privileges for who can deploy to the release. This is how we recommend folks to implement this sort of policy IIUC. We also recommend using the staging feature of Nexus PRO in release workflows as well to help better control/manage the process.
I recommend using build-automation in combination with staging (and repository targets) to manage release workflows… and avoid manual process (short of clicking a button in your automation tooling, etc).