Deploying applications continuously with SCP

31. January 2012

The last blog post (Jumping into continuous delivery with Jenkins and SSH) demonstrated how to build and deploy an application continuously using Jenkins, SSH and Nexus. In that scenario, the application was packaged and deployed on Nexus by Jenkins, and then retrieved from Nexus by the host. However, what about doing it without Nexus? You might have no other need for Nexus or even Maven. Or perhaps you prefer to deploy your application only after you have tested it in several environments. So, how to deploy your application without Nexus?

This post explains how to use the Jenkins SCP plugin to copy the freshly built application to another machine using SCP. This is useful when you need to copy an application to a specific machine or another environment without exposing it publicly.

Although this post is focused on Jenkins, other continuous integration servers have equivalent capabilities.
Read the rest of this entry »


Jumping into continuous delivery with Jenkins and SSH

10. January 2012

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.

Read the rest of this entry »


The akquinet tech@spree Technology Radar is now available

6. January 2012

akquinet tech@spree has published a technology radar analyzing the trends of 2011–2012. It provides an overview of the evolution of practice in the Information Technology sector in 2011 as well as a forecast for 2012. It is the result of one year of analysis and synthesis performed by the Innovation department of akquinet tech@spree.

The technology radar captures the output from discussions, experiments, projects, and feedback from customers and developers. It synthesizes the results to inform global technology strategy decisions. It focuses on new technologies and methodologies with a high level of attraction. This document does not aim to provide an in-depth presentation of each technology, focusing instead on conciseness and highlighting the trends and state of the practice.

More information on http://radar.spree.de


Patching PicketLink to support multiple LDAP stores

26. December 2011

The PicketLink framework[1] provides identity management (IDM)[2] to applications based on different identity providers. PicketLink offers support for a number of different identity store back-ends like LDAP or RDBMSes.

We are successfully using PicketLink in several internal and external applications and it is also a foundation for many other frameworks like seam-security[3] or the GateIn[4] portal server.

Read the rest of this entry »


Managing an Apache server with Puppet

23. November 2011

Puppet is a configuration manager embracing the infrastructure-as-code movement. It allows you to describe the desired configuration of your system. One of the most common tasks for Puppet is to configure an Apache frontend.

This blog post explains how you can use Puppet to configure an Apache server as frontend using the mod_proxy, without having to write a single Apache directive.

Read the rest of this entry »


Connecting to Amazon VPC

11. November 2011

Overview

Amazons virtual privacy cloud service (VPC) offers great outsourcing possibilities for your less private (but still private) services.

Consider a Jenkins build server. You have got one on your local machine but sometimes it’s just too much load for your hardware. It would be nice in such a case to just push some load into the cloud. Clearly you can not just put a Jenkins server into the cloud because it will need access to various services like at least some repository (Git, SVN). To protect that cloud-internal traffic (you do not want other Amazon customers to see your source code) one should use VPC. And for a seamless integration into your existing infrastructure you will need a VPN tunnel from the Amazon VPC to your local network.

Amazon offers the possibility to create such a VPN connection to your VPC. You may set up your own VPN server in your VPC but in our opinion it is easier and cheaper to use Amazons solution. Because it seemed less pricy we first tried to just use open-source software for that VPN server.

Read the rest of this entry »


Building pipelines by linking Jenkins jobs

9. November 2011

Continuous integration servers have become a corner stone of any professional development environment. By letting a machine integrate and build software, developers can focus on their tasks: fixing bugs and developing new features. With the emergence of trends such as continuous deployment and delivery, the continuous integration server is not limited to integrating your products, but has become a central piece of infrastructure.

However, organizing jobs on the CI server is not always easy.

This blog post describes a couple of strategies for creating dependent tasks with Jenkins (or Hudson).

Read the rest of this entry »


Provisioning Maven artifacts with Puppet

1. November 2011

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.

Read the rest of this entry »


Deploying Play Framework applications with Puppet

25. October 2011

Puppet is a configuration management tool made to ease the management of your infrastructure by making it more traceable and easier to understand. It allows infrastructure-as-code, a major trend today to deal with the complexity of infrastructure management.

On the other side, Play framework is a promoting a new way to build web applications, making this sort of development more efficient and productive. By avoiding the turn over (compilation-packaging-deployment-navigation) after every change, it makes web development fun again.

This blog post explains how you can deploy your Play applications using Puppet. This allows you to develop web apps in a very productive way and deploy them reliably.
Read the rest of this entry »


Simplify OSGi application tests with the OSGi Helper library

9. October 2011

Testing OSGi applications and services has always been a difficult challenge. Despite the development of several frameworks such as OPS4J Pax Exam, or junit4osgi, writing tests requires a non-negligible amount of code to manage the OSGi aspect of the test. Indeed, waiting and getting the service under test or releasing the service requires dealing directly with the OSGi framework and so the OSGi API. The OSGi Helper library is a small collection of classes to let tests focus on the behavior to verify instead of drowning the code in the depths of the OSGi development model.

The OSGi Helper library was developed by the Innovation department of akquinet, and was contributed to the OW2 Chameleon project.

This post explains the benefits brought by the library in comparison to plain OSGi tests.
Read the rest of this entry »


Follow

Get every new post delivered to your Inbox.