I wanted to get started with Javascript and AngularJS, a framework for creating frontend for apps – e.g. human user interfaces. Reason:  software is eating the world, but Javascript is eating all software.

I don’t like the messy javascript approach of downloading js files storing them manually in your project-dir, or worse, copy&pasting snippets. I’m used to programming Java, with using Maven to manage my Java-dependencies, and using brew (Mac) or apt-get (Ubuntu) to manage platform-specific dependencies. In this posting all write down my experiences on starting with Javascript-development, with practical use of package managers.

 Read more

We’re conducting a survey to take the pulse of the Application Release market. We will reveal the top challenges and key initiatives effecting you, your business and the Application Release market in a report to be published in early 2013. The report will offer a comprehensive view of what challenges your peers are facing, the latest trends in application development and key initiatives currently being planned.

This survey will take just five minutes of your time. All personal details will be kept anonymous. Participant will receive a copy of the finding and be entered to win 1 of 3 gift certificates valued at $100, $250 and $500! Take the survey now >

In an ideal continuous integration pipeline different levels of testing are involved. Individual software modules are typically validated through unit tests, whereas aggregates of software modules are validated through integration tests. When a continuous integration build tool like Jenkins is used it is natural to define different build steps, each step returning feedback and generating test reports and trend charts for a specific level of testing.

FitNesse is a lightweight testing framework that is meant to implement integration testing in a highly collaborative way, which makes it very suitable to be used within agile software projects. With Jenkins and Maven it is quite easy to trigger the execution of FitNesse integration tests automatically. When properly configured and bootstrapped, Jenkins can treat the FitNesse test results in a very similar way as it treats regular JUnit test results. Read more

Conceptually Maven distinguishes between snapshot versions and release versions. For top-level Maven projects that are continuously integrated it is unnatural to make this distinction. Especially when having some kind of continuous deployment implemented, it doesn’t make much sense to create and deploy artifacts with a snapshot version at all. Snapshot versions cannot be linked to a unique revision in a version control system and can have ambiguous snapshot dependencies. That is why such artifacts shouldn’t get deployed to a live environment.

Although it is possible to embed version control revision information as metadata into artifacts, for instance via the Manifest file, it is recommended to avoid snapshot versions at all. Only unique release versions should be continuously created and deployed instead. In fact, every single revision can be considered to be a release as will be shown below.

In order to implement this concept of continuous releasing the revision number needs to be made part of the artifact version. Read more

The essence of creating a pipeline is breaking up a single build process in smaller steps, each having its own responsibility. In this way faster and more specific feedback can be returned. Lets define a true pipeline as being a pipeline that is strictly associated with a single revision within a version control system. This makes sense as ideally we want the build server to return full and accurate feedback for each single revision.

As new revisions can be committed any time it is natural that multiple pipelines actually get executed next to each other. If needed it is even possible to allow concurrent executions of the same build step for different pipelines. However some measurements need to be taken in order to guarantee that all steps executed within one pipeline are actually based on the same revision.

Within a Jenkins build server instance it is possible to create a true pipeline for a Maven based project quite easily and in an efficient way. But in order to establish one we need some extra Jenkins plugins to be provisioned and configured properly as we will see below. Read more

Lately I am doing a lot of coding with Play! 2.0 in my spare time and I must say it is a really nice framework that makes web application development easier. I am also trying to figure out if I can do all the stuff with a Play! 2.0 project like I can do with a Java EE project. An important aspect for me is adding the project in Jenkins. Since there is not a Jenkins plugin (yet) that supports Play! 2.0 does not mean that it is not possible!

 Read more

Our approach to software development has changed in the last few years. IT professionals and software developers are working more closely together than ever before. The DevOps trend also extends to an acknowledgement that automation is a key factor in reducing costs and increasing release speeds.

Striving to be cost effective is a constant for any business but the increased focus on speed of deployment is a product of the growth of the Cloud and Agile development methodology. The bottom line is – the faster new features, fixes and improvements reach the customer, the greater their satisfaction. The same principle applies in an enterprise environment – the faster the latest version of an application reaches users, the more productive they can be.

Both environments require scalability. As your product offerings grow and branch out, the delivery method must be capable of handling the changes. In the enterprise environment a large portfolio of software applications is the norm and any deployment solution must be able to scale.

Automated app deployment can reduce costs, increase speed and scale as needed, but before we take a look at the solution let’s discuss the problem.

App Deployment Nightmares

There are a lot of potential problems in deploying applications manually. Not least of which is the time it can consume for developers and IT support. Configuration is the first challenge. Where is the application stored? Which version should be installed? Where should it be installed? Where is the configuration file and how is it applied?

Read More

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.

read more

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-deps¹ 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 mechanism² – doesn’t play well with the jar-with-deps idea. Read more

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.

 Read more