With the individual tracks coming to close on Day One at DevNation conference, I wanted to share the key takeaways, funny comments, and facepalm moments I experienced.
Agile architecture and design with Neal Ford
One of the most compelling presentations of the day, Neal validated a lot of the decisions that I have been involved in over the past 5 months in a DevOps enablement team; specifically around the most memorable quote of the talk:
“Defer design decisions until the last possible responsible moment. The longer the delay, the more relevant the data for design.” -Neal Ford
Continue reading “Day One at DevNation – through a DevOps Lens”
Today, we’ll share a small victory in our DevOps journey at Red Hat IT. This cross-team collaboration has saved our IT organization some headaches and wasted time. We open-sourced the code, hoping it can help you, too.
The Dev problem, from Sam Van Oort:
Old, pruned git branches are sometimes re-created by accident, making a mess for our developers.
Continue reading “Git Bonsai, or Keeping Your Branches Well Pruned”
Back in December, I shared with you how Red Hat IT was beginning its DevOps transformation. That early post discussed our strategy, team composition, the importance of Open Source, and incremental change. It’s been about three months and I’d like to share an update with some early lessons learned.
Overall impression so far? This is harder than we thought.
Continue reading “Red Hat IT’s DevOps Journey: harder than we thought”
In Part 1, we talked a bit about this DevOps thing and why people won’t stop talking about it. In Part 2, we’ll talk about the areas where you can change your IT focus today to help benefit from DevOps.
A classic mistake is to focus primarily on the tools associated with successful DevOps shops. It’s not as if you can bring up your own Deployinator and suddenly become as high-functioning an IT shop as Etsy. The tooling is important, but won’t succeed if used for its own sake. The most relevant tooling is used to support a culture that can consume it effectively.
Continue reading “DevOps in Straight English – Part 2 of 2”
As our industry continues to adopt lean methodologies in an effort to improve the workflow of product deliverables, it’s important that the products developed using these patterns are reliable. When speaking from an application infrastructure perspective, or the Ops side of DevOps, this means that we must continue to improve resiliency, predictability, and consistency, alongside streamlining our development workflows to allow for failing fast, and failing often.When faced with a critical incident, it’s dissatisfying to find that the root cause was an environment delta that only affected a subset of your infrastructure. You begin asking questions like, “Why aren’t all our nodes configured with the same parameters? Why aren’t we running the same package versions on all of our nodes? Why is the staging environment different from production?”
Continue reading “Convergence, Immutability, and Image-based Deployments”
If you’re like me, you may be suffering a bit of buzzword fatigue, especially relating to how this word is used (or misused) within the IT community. But for those of us who have been a part of the community for awhile, it holds deeper meaning than the oft repeated platitude of “Software Developers and Sysadmins working together, riding unicorns over rainbows“. Okay, while I may have gotten slightly carried away, you get the point.
What is DevOps to the broader community that embraces it, and is helping even now to define it? What does that even mean for Red Hat’s IT efforts? We’re going to dive deeper into both questions in this installment.
Continue reading “DevOps in Straight English – Part 1 of 2 – Enter the Buzzword”
Hey all, I’m Jen Krieger and I am Team Inception’s Product Owner and Scrum Master/Agile Coach. Hopefully, you have read Bill Montgomery’s blog post last week about Red Hat IT’s DevOps’ journey. He referred to Underpants Gnomes strategy and how to get from point A to point C if there is a big question mark in the middle. You could say my job on the team is to clarify that question mark. I’m going to share my method… but first, let’s break down what the first 6 weeks of team activities looked like from my perspective:
- Formed team in late October and immediately swarmed around a presentation to explain what we are doing, backlog, strategy & roadmap needed, limited time to talk to stakeholders, hey… maybe we should read some information on CI/CD and DevOps.
- Do all the most critically needed steps for agile best practices surrounding team formation. We selected Kanban as an initial focus for Agile practices.
- Continued to talk to stakeholders… held meetings.
- Presented “What is Inception” to Red Hat IT, included cookie monster and cookies as a defense mechanism to ward off attendees sleeping during presentation.
- Continuing to read Jez Humble & David Farley’s Continuous Delivery book and flip to the end of the book (spoiler alert!) to find the maturity model and how to use it … “OMG, why didn’t we read this in the reverse direction?” #readtheindexnexttimedummy
- Presentation. Then beer. Then sleep. Then beer.
Continue reading “Let’s clarify that DevOps question mark”
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”
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”
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”