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.
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.
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).
Developing sophisticated Android applications is challenging. Despite tools provided with the SDK and the recommended ADT Eclipse Plugin, maintaining and developing an Android application is time-consuming.
This blog post introduces a series on the rationalization of Android application development. It aims to explain how the akquinet mobile team have changed the way to create Android applications to improve the efficiency and quality of the developed applications. This series covers several topics, from the utilization of Apache Maven, the integration with a continuous integration server to the customization of the logging framework.
akquinet has participated in the improvement of all the tools used and presented in this series and has also released several internally developed components as open-source projects.