We have been using successfully Jenkins for a long time, but our Jenkins environment was very outdated. The master and its slaves were still running on JDK1.6 with Jenkins version 1.456. So it was “very” old. Even the installation of new plugins was impossible because these were usually based on Java7. Overall we have 20 Jenkins slaves for 27 projects and 200 jobs. The projects are in several states: just started, ongoing, release or maintanence. The normal project work should not be disturbed by this upgrade.
Therefore we decided not to update the existing installation but to use a completely new Jenkins and update the JDK too.
The number of release process executions is steadily increasing. Concepts like Continuous Delivery and Deployment emphasize releasing as often and as automated as possible. While developers and customers enjoy the bright side of the improving software development processes, operations has to deal with the flip side. More releases mean more storage usage. Increasing process quality requirements like archiving every delivered release (or at least, every release which is deployed on a production system) in a structured, easily accessible manner somewhere means more storage. But resources like storage are limited. So you have to collect the garbage sooner or later – and if you have a lot of releases, you desperately want to automate this cleanup process.
So, if you use Sonatype Nexus as intensively as we do and you sooner or later face storage limitations: this blog post might be a solution for you. Continue reading