Virtually every IT DevOps organization has its own way of implementing DevOps. I think there is a perception that IT de-organizes from two units (development and operations) into just one. At xMatters, we have implemented DevOps a little differently to ensure we are using agile processes. Instead of creating one uber-IT department, we are creating microservices — or micro-like services — to break large monolithic source-based development into modular service groups.
Let me go back and explain our pains, and then I’ll give more insight into the solutions.
Before DevOps: grumbling in the dark
We developers were all vaguely aware that there was a disconnect between us and operations, but we weren’t too concerned about it because we were still turning out top-quality product at a good clip. During development cycles, understanding how our software was going to be deployed would have been helpful so we could custom-develop for our deployment in our infrastructure.
Meanwhile, management and product management wanted faster deployments. In fact, they wanted to scale from monthly deployments to biweekly deployments, and then to weekly deployments.
As they wanted to push the envelope further, we started grumbling because it meant doing everything faster – from development, QA and to deployment.
Fortunately, our software architect saw an opportunity to make us more scalable. We had a ton of dedicated software pieces and only a few dozen users. We started sharing services instead, and then we really started making changes.
Major changes and recommendations
Here are some of the major changes we’ve implemented, along with associated best practices.
Actually, micro-like services. Before we moved to DevOps, each group could work on anything. So as you can imagine, we had to work hard to avoid duplicating work or letting work slip through the cracks. Now, we moving to model where each team owns a set of services.
This new arrangement helps drive accountability and helps improve code quality. Smaller groups produce faster, easier and more controlled deployments.
Meanwhile, we are going through the process of embedding a developer in each operations group and an operations person in each development group. So now when we’re planning sprints, it’s easier for developers to consider what operations would be thinking of, and of course vice versa.
Instead of lobbing ideas over the wall to ops, we can just talk to ex-teammates in embedded in ops teams. It’s kind of like having a mole, except on purpose. Communication is not only more frequent, but also more structured.
Automation Is king
Our goal is to do everything through our own xMatters API: web, mobile, and data sync. It provides a consistent communication layer and a single point of entry so we can test it extensively.
We’re steering toward true continuous deployment, and we’re getting close. However, the key to continuous deployment is automation and automated tests. In a continuous deployment environment, everything moves at hyper speed and the last thing that you want slowing down the entire process is a set of tests that needs to be performed by human(s).
So what does all this mean for our customers? We’re delivering both deployments and releases more frequently, and doing them better.
Join Moogsoft and xMatters for a Complimentary Webinar on Enterprise DevOps
IT teams can provide real value when they collaborate to move workflows forward effectively. What if you could make every notification intelligent and actionable? Tool chains maintain agility and drive critical processes forward. Join us for a free LIVE webinar and learn how a large customer uses Moogsoft and xMatters to produce automation, using the right tool at the right time to resolve issues quickly and easily. Transform Operational Effectiveness with Enterprise DevOps