DevOps Zone is brought to you in partnership with:

I'm an author and a developer focused on build tools. I'm currently focusing on Gradle, but I have an interest in all build tools and most development infrastructure. I focus on Enterprise Java, Ruby, and the interface between Systems Administration and Software Development. The focus of my work is to make it easier for individuals to adopt open source software. Tim is a DZone MVB and is not an employee of DZone and has posted 41 posts at DZone. You can read more from them at their website. View Full User Profile

Releases Are Forever?

  • submit to reddit

Releases are forever, right? Once you’ve pushed an artifact to a hosted release repository it is etched in stone, and changing it is a bad practice. That’s what we’ve been saying since we launched Nexus, but there are situations that call for old releases to be deleted. In fact, there are situations that require the deletion of old releases? Otherwise, you’d be paying for terabytes of useless data storage.

Sometimes Releases are Disposable

For example, consider a company that creates a large web-based system. They may deploy new versions of components to production multiple times a day. If this seems unrealistic, know that system administrators for popular services like Facebook,, and Flickr have talked openly about how frequently code is pushed to production systems. A few times a day isn’t odd in some of these environments, and with a large system, you’d consume terabytes of space to keep all of those old releases around.

Last time I worked at a large consumer-focused web site, pushing something to production once a day wasn’t uncommon, and even the idea of rolling back to anything other than yesterday’s build was laughably impractical. If you identified a bug in a CMS or a production database, you’d just craft the fix it and move on. This is especially true of larger, web-facing systems in which the only reality is the code that is running in production today. A site like Flickr gains nothing from being able to roll back to a release from last September.

The Other Side of the Coin: Releases are Forever

Compare this to the production release schedule of a critical, supported product and it’s like night and day. If you are coding some serious banking system you might be lucky to have a release once a month. In all likelihood you might be looking at a quarterly release. When you are working on critical applications, ship software, or have infrequent release cycles then the ability to roll back to previously released binaries is very important. When you work somewhere fast-paced with a very short release cycle, there’s not much value in retaining older releases.

For this reason, we’re clarifying this point: if it makes sense for you to delete release artifacts from a hosted repository, go for it. Just remember to re-index the server once you’ve manipulated the storage folder.

We put together the following video to share more of our thoughts on this topic.


Published at DZone with permission of Tim O'brien, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Claude Lalyre replied on Tue, 2012/01/31 - 5:13pm

With a versioning system (CVS, Subersion, Clearcase, Git) I keep all your releases, and you can re-generate them on demand  !


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.