Posted by Andrew Phillips in the wee hours: February 1st, 2012
As the interface between Development and Operations, Application Release Management1 handles information that is highly relevant to your Release and Operations teams. Selecting an Application Release Automation solution that provides insight and analytics from both perspectives is thus a key component of an effective DevOps strategy.
Here, we explain how Deployit‘s Infrastructure and new Release Overview features help you achieve this goal.
(more…)
Posted by Adé Mochtar mid-afternoon: December 29th, 2011
2011 has been an interesting year for cloud computing. Traditionally, cloud computing can be divided into three categories:
- Software-as-a-Service (SaaS)
- Platform-as-a-Service (PaaS)
- Infrastructure-as-a-Service (IaaS)
While SaaS has been around for some time (Salesforce.com started in 1999!), we are seeing an increase in adoption of IaaS and some heavy development in the PaaS world.
Now that 2011 is coming to an end, this is also the time for lists. So here are my 3 top 3’s of cloud computing.
Posted by Maarten Kennis terribly early in the morning: December 19th, 2011
Introduction
One of the most common challenges of managing the configuration of servers in your typical DTAP environment is, in my opinion, keeping all the involved hosts at the same level of configuration in terms of installed operating system packages and their configuration files. It really can be a pain to keep all the systems at the same configuration level. Faillure to do so can lead to interesting situations where software produced by the project team does not run or perform on the acceptance and/or production environment while it was running perfectly on the development and/or test servers.
(more…)
Posted by Mark van Holsteijn in the early afternoon: December 14th, 2011
How do you setup a environment that support the continuous deliver of enterprise Java applications? How do you manage the large number of machines that are involved? How do you enable self-service, continuous delivery of applications onto the platform?
In this blog post we will give a description of an open source Java Application Platform as a Service that we created for our customer, using VMware, Redhat Enterprise Linux, Apache WebServer, JBoss Enterprise Application Platform, JBoss Operations Network, Puppet, Deployit, F5 Load Balancer and a Layer7 SecureSpan gateway.
Posted by Andrew Phillips at around evening time: November 29th, 2011
Whether the driver is Agile, Cloud or DevOps1, or a “plain old” efficiency drive or process improvement initiative, forward-thinking organisations are currently looking for ways to improve their application release processes through automation. In an area where manual activities are still all too common, it’s unsurprising that the initial focus has been on automating the deployment execution – moving all the bits to the right places.
What early adopters have learnt is that, at the enterprise scale, automating release execution quickly introduces a new bottleneck in today’s dynamic IT environments: continuous management of the deployment plan definition. A new generation of application release automation (ARA) tooling avoids this pitfall by leveraging intelligence to automate deployment planning as well as execution.
(more…)
Posted by Arno den Hond at around evening time: November 14th, 2011
Unlike announced in my previous post this one is neither soon nor on a surprise topic. It is about a general aspect of Android that is, to my opinion, very powerful but often under utilized.
Android apps are not monolithic but rather a collection of components of different kinds. I suspect android took inspiration from the concept of midlet suites in j2me and believe it expanded on that quite well.
These components (except for provider) can be exposed through intent filters in the package’s manifest and can be used by other components in different packages. This allows apps to accomplish tasks together which a single app could never do.
(more…)
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 Vincent Partington in the early morning: August 15th, 2011
A few months ago I blogged about the integration between Deployit and IBM WebSphere CloudBurst (since renamed to IBM Workload Deployer). While that article gave an overview of the integration and included some nice screenshots, it did not really go into the details. Now is the time to explore the implementation of this integration..
Workload Deployer V3 and Deployit from XebiaLabs both “deploy” things, but they deploy different things. Deployit deploys application artifacts and resources, such as EAR files and data sources, to middleware systems like IBM WebSphere Application Server (but also HTML to web servers, IBM WebSphere MQ configurations to queue managers, and so on). IBM Workload Deployer, on the other hand, deploys patterns (or topologies) of virtual images to hypervisors — but not just any kind of virtual images. IBM Workload Deployer is especially geared toward deploying middleware topologies.
IBM Workload Deployer V3 is an updated and enhanced version of the WebSphere CloudBurst Appliance, renamed to reflect the expanded scope of workloads it can deploy, which are no longer limited to only WebSphere workloads. The content for this article (including screen captures) was created using a WebSphere CloudBurst Appliance, but everything noted here is equally applicable to IBM Workload Deployer V3. However, for the sake of consistency with the images presented, “WebSphere CloudBurst” is used throughout this article to refer to both products.
In other words, IBM Workload Deployer deploys the middleware systems and Deployit deploys applications to those middleware systems — complementary functionalities that form a perfect fit.
At XebiaLabs, we have been working on two exciting new integrations for Deployit. We created a Deployit plugin that enables you to deploy EAR files directly to virtual systems created by IBM Workload Deployer V3 or its predecessor, IBM WebSphere CloudBurst Appliance V2. We also created a WebSphere CloudBurst script package to deploy application artifacts and resources on newly created virtual systems.
This article explores two integrations between WebSphere CloudBurst and Deployit as a way of showing how you can leverage the WebSphere CloudBurst command line interface and script packages to integrate cloud deployment with your application deployment automation solution.
Posted by Andrew Phillips in the early morning: August 3rd, 2011
Across all industries, the services delivered by business applications have become an essential part of an enterprise’s customer offering. Bringing new features to market quickly is thus a critical factor in determining a company’s success.
In this post (an extended version of which is available as a whitepaper), we will outline today’s Release Management challenges and discuss the need for Release Automation.
We’ll identify key considerations for successful solutions and highlight why “Zero-Maintenance” is a critical requirement for Release Automation that provides the scalability required in an agile landscape and enables the delivery of continuous business value.
Posted by Andrew Phillips in the early morning: August 3rd, 2011
As part of the preparations for the recent 1.0.0 release of jclouds, I was tidying up the existing Tweetstore demo application as well as porting it to CloudBees’ Tomcat-based RUN@cloud platform.
A key part of the test harness for the original versions of Tweetstore that run on the Google App Engine is the neat GoogleDevServer class. Basically, it’s a clever wrapper around the KickStart class used under the covers by the GAE SDK tools that allows you to specify the SDK location, address, port and WAR file (or expanded WAR directory) to run.
Better still, it can programmatically be shut down cleanly, making it ideal for integration test runs1.
For CloudBees, I was thus looking to put together a similar RunAtCloudServer. It proved more challenging than expected…2
(more…)