Like all software, Deployit plugins should be build automatically, deployed and tested whenever possible. Below I will explain how to setup continuous integration and testing for Deployit plugins. The general idea is that if you’re creating a larger set of plugins for Deployit, it makes sense to try to build and deploy them as often as possible so you can catch errors early. We found that it is really easy to create plugins that work fine in isolation but fail when they are deployed together. Luckily it is also easy to catch these kinds of errors as I will show below.
Read more
Continuous Delivery
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
Xebia’s expertise with middleware and application deployment automation led to the wish to explore new tools handling these area’s.
Along came VMware’s Application Director 1.0 beta and later GA, and together with VMware Netherlands we built a demo environment at Xebia.
The setup did not go real smooth, mainly because we had some infra setup troubles and the interfacing between software components did not work directly.
After all was working, I compared the vApp director 1.0 with Xebialabs’ DeployIt deployment tool.
Conclusion: vApp director 1.0 is nice, but more operations/infra oriented than developer oriented. With DeployIt, when parts of the deployment (say, only a war & datasource) is changed between deployments, only those steps are done in correct order. With vApp dir, you have to script this out, or deploy everything from scratch, which takes a long time. On the other hand, DeployIt cannot create VM’s by itself.
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
At XebiaLabs, many of the questions we get about our enterprise deployment automation solution Deployit are from users looking for automated deployment as a prerequisite for Continuous Delivery. Often, this the result of initiatives to extend existing Continuous Integration tooling to support application deployments.
Increasing the frequency of whole-application testing, decreasing time-to-production and delivering greater business value faster and more regularly are goals we definitely share, and in this post we’d like to pass on some key experiences and lessons from working together with our users to help them realize Continuous Delivery.
Read more
Putting software in production can be a challenge, often the frequency of going to production is low and the amount of changes/features involved is high. This usually results in a long and painfull deployment process. The release probably contains as many changes as possible because if you do not get your change/feature in this release the next release may very well be in 6 – 12 months.
To create the illusion of being able to prevent this and have more control the deployment department is often confronted with huge, 100+ pages, deployment guides decribing the deployment process in numerous, usual manual, steps. Incidents occur in the newly deployed software. Since there were so many changes in the new release, how are we going to find out which part of the newly deployed software is causing the problem.
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?
For a deployment, Deployit calculates the step list based on your model. But what if you want to add an extra step? There are several ways to do this. This cookbook entry will explain a simple case: executing a remote shell command on a server.