Repository : Standards for multiple project with access control

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Repository : Standards for multiple project with access control

hanasaki
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Repository : Standards for multiple project with access control

Jason Dillon-3
On January 10, 2014 at 10:07:43 AM, hanasaki ([hidden email]) wrote:
Looking for input on repository setup. 

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).

—jason