Posted by Vincent Partington mid-morning: October 20th, 2011
Over the past five to ten years, continuous integration has become a no-brainer for every medium to large scale software development project. It’s hard to imagine going back to not having every commit (or push) automatically trigger a build of the code and, most importantly, a test run of of the code. That test run will surely include unit tests, but setting it up to also run integration tests used to be harder. You’ll need to automatically deploy the application to the target middleware environment and then run the integration tests against that environment.
The Deployit plugin for the new 3.3 release of Atlassian Bamboo adds the enterprise-scale deployment capabilities of XebiaLabs Deployit to Bamboo. This allows you to speed up your development process by adding automated deployment to your continuous integration setup and make the the first step towards continuous deployment and continuous delivery. Instead of deployment being a bottleneck to your development process, it will be be an integrated part of it. You can test your application on the target platform as soon as possible, find any platform incompatibility and deployment issues early on, and, when it’s time to deploy to the production environment, your deployment will be quick and reliable.
Posted by Andrew Phillips around lunchtime: July 20th, 2011
Recently, I was preparing a connection checker for Deployit’s powerful remote execution framework Overthere. To make the checker, as compact as possible, I put together a jar-with-deps1 for distribution.
Tests and trial runs from the IDE worked, so I was expected the dry-run of the distribution to be a quick formality. Instead: boom!
Turns out that one of the libraries used by Overthere, TrueZIP – or indeed any code that utilizes Java’s SPI mechanism2 – doesn’t play well with the jar-with-deps idea. (more…)
Posted by Barend Garvelink mid-afternoon: February 25th, 2011
Update, 26-02: Brian Demers from Sonatype pointed out in the comments that Maven 2.0.10 and later are forwards-compatible with changes in the metadata format. If your Maven 2 version is one of the recommended versions on the download page, you will not have this problem.
Two days, in fact. Yesterday evening, after my colleagues went home, I brought down our Nexus 1.8.0.1 instance to upgrade it to 1.9 without interrupting their work. The download page for Nexus 1.9 contains the following instruction:
Sonatype has changed how the lucene indexes are stored on disk, it is required that users reindex all repositories in their nexus server to start benefitting from the changes (and for search to work properly).
Inconspicuous enough. Furthermore, clicking through from the change overview to the full change log reveals:
[NEXUS-3849] – Add full support for the new maven 3 snapshot metadata
What it doesn’t reveal is that the rebuild metadata command in the repository administration screen, which would appear to be proper housekeeping at a time when you’re reindexing the repositories, now generates Maven 3 style metadata and inadvertently breaks compatibility with Maven 2 (update: older versions). This is where the fun begins.