This is part 3 of a three part article on Continuous Integration Strategies: Simplifying application development on Red Hat® Enterprise Linux®
The testing environment requirements are simplified somewhat if your software is built against a Red Hat Software Collection (RHSCL).
Red Hat Software Collections provide three primary features: the ability to have multiple versions of software on one OS, certainty that the software is the same across versions of the OS, and the option to refresh components more frequently than the underlying OS.
As a result, testing need only be performed against the software collection for which the application has been built—so an application developed to run on the software collection for Python 2.7 should be testable on that software collection running on any version of Red Hat Enterprise Linux. The test results should then be valid for all versions of Red Hat Enterprise Linux that run that software collection.
REQUIREMENTS FOR TESTS
Test coverage within the CI environment should be considered no differently than any other integration and testing regime. Your tests should provide an appropriate breadth of coverage and depth in test scenarios to ensure the necessary level of quality in the delivered software.
Continue reading “Continuous Integration Strategies (Part 3 of 3)”
Investigating performance in a complex system is a fascinating undertaking. When that system spans multiple, closely-cooperating machines and has open-ended input sources (shared storage, or faces the Internet, etc) then the degree of difficulty of such investigations ratchets up quickly. There are often many confounding factors, with many things going on all at the same time.
The observable behaviour of the system as a whole can be frequently changing even while at a micro level things may appear the same. Or vice-versa – the system may appear healthy, average and 95th percentile response times are in excellent shape, yet a small subset of tasks are taking an unusually large amount of time to complete, just today perhaps. Fascinating stuff!
Let’s first consider endearing characteristics of the performance tools we’d want to have at our disposal for exploring performance in this environment.
Continue reading “Exploratory Performance Analysis with Performance Co-Pilot “
A few short months ago, I was managing an operations team at another firm. There had been a sea change in executive leadership over the summer, and the DevOps transformation that I’d helped to kick off was quickly being unraveled by the sorts of executive shenanigans that can ensue when a C level departs and leaves an opening. I was open minded to a change in scenery and got the call of a lifetime from a Red Hat recruiter.
You see, I’ve been involved in the Linux community since around 1998. I helped grow the Triangle Linux Users Group in its early years, and served a term on the steering committee as Vice Chair. When the community was looking for an enterprise class Linux distribution without the cost of a subscription model, I joined the cAosity project (now gone) and helped deliver CentOS to the Linux community. Open Source was in my DNA, and living in the Raleigh area the success of Red Hat was always right there for me to admire. “Someday I’d like to work there,” I often thought to myself.
This DevOps thing has gotten a lot of traction with me. I’ve been a volunteer co-organizer at Triangle DevOps, and have even given a few public talks on the subject, too.
Continue reading “Incepting DevOps at Red Hat”
This is part 2 of a three part article on Continuous Integration Strategies: Simplifying application development on Red Hat® Enterprise Linux®
Within a Continuous Integration environment there are some key features that are required to encourage an effective process.
SOURCE CODE REPOSITORY—JUST THE ONE
For the effective operation of CI, it’s essential that all project source code and build components are maintained in a single repository. The repository must contain not just the source code, but all the assets needed to build, deploy, and test the software; this may include test scripts, property/configu- ration files, database schema, install scripts, and third-party libraries.
AN AUTOMATED BUILD
A key feature of CI is that software should be built regularly—possibly as regularly as each check-in of amended source code, but no less frequently than daily. It’s therefore essential that the build be automatic, complete, and quick.
Continue reading “Continuous Integration Strategies (Part 2 of 3)”
At JUDCon 2013 in Boston, Scott Cranton and I presented a talk entitled Resilient Enterprise Messaging with Fuse & Red Hat Enterprise Linux. This technical article is the follow up work from that presentation.
JBoss A-MQ is built on ActiveMQ which is a robust messaging platform that supports STOMP, JMS, AMQP and modern principals in Message Oriented Middleware (MOM). It’s built from the ground up to be loosely coupled and asynchronous in nature. This provides ActiveMQ with native high availability capabilities. An administrator can easily configure an ActiveMQ master/slave architecture with a shared filesystem. In the future this will be augmented with Replicated LevelDB.
Red Hat Enterprise Linux is the popular, stable and scalable Linux distribution which has High Availability and Resilient Storage add-on support built on CMAN, RGManager, Corosync, and GFS2. High Availability and Resilient Storage expand upon the high availability capabilities built into ActiveMQ and provide a robust, and complete solution for enterprise deployments that require deeper clustering capabilities.
There are two main architectures commonly used to provide fault tolerance to a messaging server. The first is master/slave which is easy to configure, but as it scales, it requires 2X resources. The second is made up of active nodes and redundant nodes. The redundant nodes can take over for any one of the active nodes should they scale. The active/redundant architecture requires more software and more initial configuration, but uses N+1 or N+2 resources as it scales.
This article will explore the technical requirements and best practices for building and designing a N+1 architecture using JBoss A-MQ, Red Hat Enterprise Linux, the High Availability Add-On and the Resilient Storage Add-On.
Continue reading “Resilient Enterprise Messaging with JBoss A-MQ & Red Hat Enterprise Linux”
This is part 1 of a new three-part article about Continuous Integration Strategies. We hope you enjoy it!
Continuous Integration (CI) offers a method of avoiding the integration issues that typically occur when there are extended periods between developers checking in working copies of code. However, the technique also offers significant benefits where an application is designed to run on multiple versions of a platform and the application and platform are changing. In both cases, Continuous Integration facilitates the early detection and eradication of software defects: defects that may otherwise go undetected for days, weeks, or months after they were created. Detecting and resolving these problems early in the development process can translate into lower costs and shorter timelines.
This paper aims to simplify the adoption of Continuous Integration by software vendors targeting Red Hat® Enterprise Linux®. It does this by providing guidance on:
Recent Red Hat Developer Blog articles have explained what Software Collections are, what they’re good for, and how you can leverage them to easily enhance your development environment leveraging the latest and greatest versions of your favorite programming languages and relational database backends.
But the software collection packages available for each language comprise only a subset of what is available — usually the core and some popular additions. Until that day when repositories have sprung up with all the additional SCL builds of libraries, modules, extensions to your language collection, you’ll need to build those yourself.
Fortunately, it’s not very difficult.
Continue reading “Extending software collections with additional packages”
I’ve recently released a tool called vm-truck-loader to automate virtual machine creation with VMware vCenter. Using a simple CSV file, and leveraging the API exposed by vCenter, this Java based command line tool enables you to design a fully automated deployment process, and can be a key to implement a proper Standard Operating Environment around vCenter. In this regard, I thought I’d do a quick entry on this blog, to briefly describe what the tool can do.
Instrumenting virtual machine creation
As I mentioned a couple of weeks ago, many of you have read Slavek’s prior articles on software collections – now you can hear him talk!
Slavek, from Red Hat’s engineering team that brings us software collections, is an excellent presenter having spoken about collections numerous times at the Red Hat Summit. If you have questions about how to use collections, attend today’s webinar.
Title: Deep dive into Red Hat Software Collections
Continue reading “Webinar today: Bohuslav "Slavek" Kabrda on Software Collections”