Tag Archives: DevOps

The DevOps Scam?

Posted on by
Reply

Ted Dziuba has a great blog entry: “DevOps is a Poorly Executed Scam. The post has been around a while, but I just noticed it and wanted to comment. ” The ” scam ” he points out is that unlike Agile, nobody has put out the book, performed and (as the author of that book or common speaker on the circuit) cashed in with massive consulting rates. I’m sure someone is hard at work in doing that. Ted highlights the folks behind XP and Scrum as executing the “Agile” scam well.

Setting aside the inflammatory nature of the word scam, there’s an important truth. With any of these movements / philosophies the enterprise is going to be hard pressed to take them on, unless someone writes up a practice. DevOps has no XP and certainly no Scrum. Scrum for all its warts, and horrible implementations at some companies, has done great things by making Agile palatable to the enterprise. The “cool kids” in the industry look at CSM as an obvious scam, but certification makes the enterprise comfortable. The executive thinks, “If I can’t get a certified Agile guy, then it must not be grown up enough for my company.” Continue reading →

Customer Success Story: A DevOps Team by Any Other Name

Posted on by
Reply

Provides Just as Much Value

I recently visited a customer and was surprised to learn just how sophisticated their IT operation is. They have a private cloud for Dev and Test and automated deployments (courtesy of AnthillPro) across all environments. The development and QA teams may request an environment for a specified period of time and then deploy their build to this environment for testing. This entire system, the environment provisioning and the application deployment is fully automated and turns what used to be a multi-week process into a one that literally takes minutes. BTW, these environments are non trivial as they are made up of multiple virtual machines along with network configuration, firewall rules, load balancing, edge caching, and more. Continue reading →

UrbanDeploy’s GA Release

Posted on by
Reply

UrbanDeploy has just reached its first GA release. We’d like to thank the early adopters who have been using the tool with great success prior to this milestone as well as all the AnthillPro users who helped teach us just what a pure deployment tool should look like.

UrbanDeploy is designed to handle complex application release automation (that’s the overly precise term for “deployments”). Lots of teams have continuous integration, but no release automation, or use an automation tool in just test environments or production. UrbanDeploy is designed to consistently deploy across environments regardless of what (if anything) you use on the build side.

UrbanDeploy is the first element of our fourth generation automation platform (the DevOps Platform) to reach the market. We’re looking forward to get more elements out this year and early next as well as migrating existing AnthillPro customers to the updated platform.

Is Having a “DevOps Team” a Problem?

Posted on by
Reply

In reviewing Patrick Debois’ great new slides on DevOps for DevOps down under, I noticed that he says that if you have a DevOps team you are doing it wrong. He later hedges with the idea that a team to help transition to DevOps is a good thing.

I find myself working with teams that support DevOps efforts in their enterprises pretty regularly, so this was thought provoking. How I take it, is that if your developers and operations do not actually talk together, cooperate and find joint solutions, you are missing out on some of the key cultural advantages of DevOps. As far as that goes, I definitely agree. Continue reading →

DevOps: The Rise of QA?

Posted on by
Reply

The DevOps movement which has been doing hard work to break down silos, improve deployment quality and even push towards continuous production deployments has focused on improved cooperation and communication between developers and the system admins (operations) who deploy releases out into production.

Recently, I’ve been wondering, “Where’s QA and test?” The DevOps community has put a lot of emphasis on automated testing, which is great, but I haven’t heard a whole lot about where manual QA fits in.

Listening to Timothy Fitz from IMVU champion continuous production deployment at the recent Leaders of Agile virtual conference was a little reassuring. Even though IMVU automatically deploys most code changes that pass tests to production – deploying many times a day – there’s still skilled, human testers involved. They test new functionality and features before those features are enabled and made visible to end users. So, QA and testers do have a place.

A aggressive view of the role of testers was presented by Bola Rotibi’s in her editorial in SD Times, “Rise of the machines: Power brokers in DevOps bonding! While Ms. Rotibi’s thesis was that communication and automation are key (and we love that), she explored QA’s role as a conduit and facilitator between development and operations:

The line of communication between Dev and Ops needs to be clarified. Neither is well-versed in communicating what either needs to carry out their respective responsibilities. QA and testing, a group within the software delivery team, could and should help smooth the relations between the two sides.

Today, testing is seen as an extension of development rather than a core part of the deployment team. But QA and testing teams need to have a broader scope and a more active role in shaping and strengthening the DevOps relationship. Many of the management and monitoring tools are raising the profile and capability of the testing function as a key conduit between DevOps.

This strikes me as a critical step in the evolution of a traditional, siloed IT shop into one with stronger development to operations coordination, trust and cooperation. Even today, QA teams have many of the needs of development teams as well as operations. They have infinite work and need to move quickly and test new builds frequently. Their pace is closer to development’s than operations. At the same time, if things aren’t being installed properly in QA, if control is lacking, their work can be wasted. QA should be primed to lead Dev and Ops as they move forward with Agility and Control. What remains to be seen is if QA and test has the courage to embrace automation and enough respect from their partners in the IT organization to be able to lead.

From Agile to Dev Ops

Posted on by
Reply

Steve Berczuk has a nice article up on CM Crossroads, “Agile Teams care about Dev Ops”

Key quote:

… The next logical step is to routinize deployments into production. For this to happen the project team needs to incorporate operation issues into the backlog early, and incorporate operations team roles into the core development team.

Some concrete steps that teams can take to move towards a dev ops perspective are:

  • Including the operations team in the project team. Some tasks might lend themselves to implementation by someone familiar with  the operations systems.
  • Extend your toolset to include tools that the operations team can easily use. Your may be developing a web application in Java, but some deployment and configuration tasks might be easier to execute in, say, Bash of Python.
  • Developing tools and process to do deployments into production early. These tools should be in a form that works well in an operation environment, and be as automated as possible.
  • Making realistic deployment environments available to the team so that production deployments can be exercised early, and automated.
  • Place system artifacts under the same change management paradigm that you use for code. The tools may be different, but the you should strive to deploy not only an identical version of the code, but an identical version of the code in an identical server configuration.

I really couldn’t agree with Steve more on these points or the rest of his article. You really want to push realistic practice deployments as far down towards development as possible, and have solid partnership between developers and operations teams. Throwing things over the wall just doesn’t cut it when you have Agile throwing things over the wall at a faster and faster pace and the cost of failed deployments is high.