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 →
Let’s imagine the following situation. You’re working on an application for a customer. Despite a firm deadline and a roadmap given to your customer, he’d like to check the progress regularly, let’s say weekly or even daily, and actually give you feedback.
So to make everybody happy, you start releasing the application weekly. However, releasing is generally a hard-core process, even for the most automated processes, and requires human actions. As the release date approaches, stress increases. The tension reaches its climax one hour before the deadline when the release process fails, or worse, when the deployment fails. We’ve all been in situations like that, right?
This all-too-common nightmare can be largely avoided. This blog post presents a way to deal with the above situation using Jenkins, Nexus and SSH. The application is deployed continuously and without human intervention on a test environment, which can be checked and tested by the customer. Jenkins, a continuous integration server, is used as the orchestrator of the whole continuous delivery process.
Continue reading →
Our last blog post introduced how Puppet can be used to achieve Infrastructure-As-Code, and how to deploy Play applications following this practice. However, we didn’t address how the applications are actually copied to the host.
Apache Maven is a widely used build tool adopted by more and more companies to support their build process from compilation to deployment. Deploying, in the Maven world, means uploading the artifact to a Maven repository. Such Maven repositories are managed using Sonatype Nexus or JFrog Artifactory. However, this sort of deployment does not address the real provisioning of the application, i.e the deployment on the production servers.
This blog post presents a Puppet module to download Maven artifacts from a Nexus repository. This module closes the gap between the development team deploying their artifacts to a Maven repository, and the administration team responsible for installing and configuring the application.
Continue reading →
You must be logged in to post a comment.