Be sure to follow this new addition to the Red Hat blogosphere at: rhelblog.redhat.com.
Continue reading New: RHEL Blog for SysAdmins
DevOps is all about culture, right? Yeah, it’s developers and operators working more closely, but it’s more than that. DevOps is a culture that exudes the principles of Agile, Lean, and Open Source, to deliver higher quality products and services faster, more continuously, and more predictably.
So, if we accept DevOps is a culture, and your CIO gives you a mandate to transform his or her organization to a DevOps organization, you’re now effectively responsible for an organizational culture change initiative. That’s the situation I found myself in recently, when Red Hat CIO Lee Congdon asked me to lead a DevOps enablement team in his IT organization. At a few weeks in with our new team, called Inception, I’d like to share our approach:
1. Build culture through practices. Culture is the sum of the habits and behaviors of a group. I don’t believe culture can be changed through mandates. But, Inception’s mission is to change the organization’s culture. So, how?
Continue reading “Red Hat IT Begins Its DevOps Journey”
Countless products uses XML files, whether it is for data persistence, serialization or mere configuration. This is even more true when it comes to the Red Hat middleware portfolio, the JBoss projects having always been keen on using this format for configuration files – on top of the ones specified by JEE such as the famous (or infamous ?) web.xml. While the XML format has some definitive qualities, it is not the easiest format to parse, and this often causes issues when integrating product inside an RPM or designing an automated installation procedure.
Continue reading “XML editing with Bash script”
Hi, I’m Steve, a member of the Inception team at Red Hat. The Inception team was pulled from different parts of IT to foster DevOps culture in Red Hat. Though we’ve only been a team for a little over a month, we’ve been trying to do some early projects to make everyone’s lives easier.l
We spent quite a bit of time in our early meetings identifying pain points in the current processes. We talked with a few developers, ops folks, noted historical issues and ran with general brain storming. We heard a lot about configuration management, lack of information, redundant and time consuming tasks, and many more of what one expects when asking tech people what pains them.
Of course, Tim (another Incepticon) and I were itching to write some code so once the team identified a common issue for both developers and ops engineers we jumped in head first.
The rest of this post describes our journey from initially trying to implement a simple solution to improve the day-to-day lives of developers, through the technical limitations we experienced along the way, and finally arrives at the empathy for our developers we’ve gained from that experience. We’ll wrap up with a note on how Red Hat Software Collections (announced as GA in September) would’ve simplified our development process.
Continue reading “Feeling Developer Pain”
The introduction of Eclipse Kepler (4.3.0) into the Developer Toolset 2.0 (DTS) not only brings the latest and greatest of this development environment, but many different features provided as plugins. For some, their purpose may not be immediately clear from their name, so let’s quickly go through the list of Eclipse plugins shipped in DTS 2.0.
JDT (Java Development Tools)
Possibly the most well-known plugin for the Eclipse IDE. Create, manage, develop, test and debug your Java projects. The various integrations make everything easy to do.
Continue reading “Eclipse Kepler Overview in DTS 2.0”
Whether you’re new to developing on RHEL or have been doing it a while, you may get some use from this RHEL Developer Getting Started guide.
Continue reading Red Hat Enterprise Linux Developer Getting Started Guide
Continue reading Red Hat Enterprise Linux 6.5 now Generally Available (adds Docker support)
In an earlier post we looked into using the Performance Co-Pilot toolkit to explore performance characteristics of complex systems. While surprisingly rewarding, and often unexpectedly insightful, this kind of analysis can be rightly criticized for being “hit and miss”. When a system has many thousands of metric values it is not feasible to manually explore the entire metric search space in a short amount of time. Or the problem may be less obvious than the example shown – perhaps we are looking at a slow degradation over time.
Continue reading “Performance Regression Analysis with Performance Co-Pilot “
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)”