Why you should be using an Artifact Repository- Part 1

I’m continually amazed that many development teams and enterprises do not use an artifact repository as a tool in their software development process.

An artifact repository is akin to what Subversion is to source code, i.e. it is a way of versioning code binary artifacts. In the Java world these artifacts could be jars, wars, ears, fully fledged applications, libraries or a collections of libraries that are packaged.

One of the key areas that artifact repositories help is dependency management. In the real world of development, applications are not static binaries, but a collections of objects that have an interdependency on each other, for example a Web application (.war) will have dependencies on any kind of common functions, for example log4j, dom4j etc… and these dependencies have their own versioning.

In “legacy” development you would probably manage your dependencies as a static list, which scales to a certain point but as the development growths so does the inter-dependencies, this becomes a source of problems. Many people “check-in” their libraries and dependencies with their source I personally feel that this is a not a good practice. It does have a positive effect that your code will co-relate to a set of given dependencies and get all the goodness of version control, however…

Dependencies can in their own right become their own living, breathing entities and treating them statically downplays their prominence. Good build tools understand dependencies and hence why I’m a great fan of using Maven. These tools allows abstraction of dependencies from the build process and allows neats stuff like dependency management.

Maven was designed to manage dependencies. Why keep a binary for log4j 1.2 with your source code in Subversion, where the repository is typically private. Why not keep the common library on a central system whereby *all* development teams can use that exact shared library. Better still is that your build tool like Maven understand where that server is and how to download and use that library within the build. This is all done in one location in Maven, your POM.

Now lets view this from an Enterprise context.

Reuse: Imagine your team develops some common utilities or services.
How do other groups reuse your common libraries within their own builds?
I could describe a whole bunch of ways they could share your jars, most of them bad, no traceability, no versioning control and no direct way to incorporate with your build.

Solution: Publish your libraries to a artifact repository:
1) Your libraries will be versioned controlled
2) Other teams will simply need declare a dependency in their pom to use your library
3) Your common library is now shared

This brings in a whole new level of collaboration.

A downside to this is that you have to install an enterprise level (Maven) Artifact repository. Which actually is not a big deal, there are many that are freely available, Sonatype Nexus, Apache Archiva and Artifactory, just to name a few.

If you are really imaginative you could bring this picture one level forward. Governance.

Imagine you now have your own enterprise wide artifact repository and its the authoritative source of all dependencies, libraries, application releases etc… As teams build their software they “pull” dependencies that are versioned control and pristine and they “publish” to the artifact repository so that common components can be shared plus the repository can be the authoritative source for application deployment.

An enterprise could have there own governance process to ensure that all artifacts are vetted, checked, i.e. to a governed standard, for example licensing, security, intellectual property rights and obviously much more before they are placed for use in the artifact repository. However once they are in and are used as components to build software you now have have that level of security that collection of jars, wars and ears that are running on your production servers and handling multimillion dollar transactions are compliant.

As a final note I’ll leave you with a diagram

Artifact Repository Diagram

Artifact Repository Diagram

Tagged with: , , , , , ,
Posted in Agile, Subversion, TeamForge
0 comments on “Why you should be using an Artifact Repository- Part 1
1 Pings/Trackbacks for "Why you should be using an Artifact Repository- Part 1"
  1. […] some proper Gerrit tuning and restructuring your build scripts so that they fetch binaries from an artifact repository instead of having them part of the repo. With Git LFS, there is another approach available that […]

Leave a Reply

Your email address will not be published. Required fields are marked *

*