Although we are a Java camp using SVN for source control and Apache Ivy for dependency management, this question broadly applies to any platform/language, SCM and artifact repository tool.
My tech lead and I have spear-headed the company’s first strides into using a dependency manager like Ivy to manage all of our JARs. We’ve set up what we are calling our “Ivy Repo” which is where we are housing both our in-house (developed by us) JARs as well as commonly-reused dependencies (Apache JARs, Spring, etc.).
We’re beginning to run into issues where a developer will have to make changes to our in-house Commons JAR (Commons.jar) and then run an <ivy:publish> before the code changes have been code reviewed, committed to SVN and built from the CI server. This happens when the developer is working on a bug fix or new feature in one project, but needs to make modifications to a dependency such as Commons.jar in order to complete their task.
Thus we’re in a situation where the Ivy and SVN are out of synch with each other.
Obviously, we could instanitate a rule where no one is allowed to publish without first having code reviewed, committed and tested their code with the team. Alternatively, we could just disallow developers from publishing altogether.
Before going down either route (we’re leaning towards the latter), we were wondering if other teams have experienced the same problems and what solutions were implemented to prevent this.
Perhaps tools like Artifactory or SonaType are worth looking into, but neither of us have experience with them and it doesn’t look like they support these kinds of business rules.
In short: we’re looking for a way to prevent premature JAR publishing so that publishing is always the last phase in our standard code >> review >> commit >> CI >> deploy cycle.
Thanks in advance!
Artifactory provides fine-grained permission management which is useful for controlling who can deploy what and to where; for example, you can create a rule to deny the publication of a jar file based on its name\path (namely your Commons.jar) and apply it to all users except those in position to approve it.
If you require more flexibility, the pro version of Artifactory also has the User Plugins feature which basically lets you write groovy plugins for Artifactory and provides you with a rich context and hooks for different operations.
In addition, Artifactory’s properties metadata lets you annotate any artifact and folder with custom tags that can also be used for different conditionals.
Combine the two and let your imagination run wild.