DevOps in a practical view

The last 2 days I’ve been at a customer giving a LoginAM training. Somewhere during those 2 days they had an epiphany and realised they could throw pretty much anything at LoginAM and LoginAM would help them automate it. Which was a big thing for them. They are a service provider with a XenApp farm providing a managed desktop with some of their own applications (they’re also a software developing company) and some other client applications from all sorts of other vendors. Some of the trainees were in the DevOps team and they needed something that could automate all those different client applications. As some might know, getting all those different client applications installed automated can be a pain in the ass. The vendors all deliver different kind of installers which might or, more often, might not adhere to their respective standards. So I was happy when they realized LoginAM was a great tool for this.

That being said, what I actually wanted to talk about was DevOps. This is a very hot topic currently. One of the issues at big Enterprises is the lack automation, and the complexity to get things automated from start to end.  One example is the software being delivered by Development. Dev delivers it in all kinds of forms. Ops need to take it and automatically deploy it over the environment. We already have a tool that makes it possible to automate nearly anything. But still if you’re trying to automate certain (with certain I mean a lot) software you’ll find that they’ve got complicated installers. They might not adhere to parameter standards for MSI, they might have an installer that only works with a windows session or, and this is one of the worst, they might not have any parameters that make the installer silent. This is only one of the more practical issues you run into where DevOps can lend a hand.

What is DevOps trying to do about this?

The DevOps loop

DevOps is all about collaboration between Dev and Ops. From what you can read up here installers are quite often “not great”. So the developers need to deliver a better installer. Ops is the team that could perfectly inform them on how they would like the software to be delivered. That might be an installer but maybe Ops might be better of not getting an installer but just a bunch of files, registry key and/or actions the installer used to perform. If they have an automation tool like LoginAM it’s pretty likely that it can handle all those things.

Next up is knowing what the other team does and what kind of troubles they run into. Some issues are easier to fix for Dev and others for Ops. But the problems both teams encounter usually never leave the team. So Dev might be trying to solve a very complicated issue (at least to them) while Ops has a very easy and pragmatic fix. Obviously you can’t get every developer to know everything about operations and vice versa. But some kind of “trading” program or training sessions from one team to the other can be very beneficial. This also improves the understanding on both sides. A good understanding is generally a good thing when 2 teams have to work together.

Whenever trying to get 2 teams to work together properly good communication is key to success. Scheduling a bunch of meetings is one way, but most techies resent having to attend yet another bunch of meetings. One way to get good communication going between the teams is to physically put them closer to each other. This might be a very delicate subject since people can be attached to “their spot”. So whenever you’re relocating teams make sure you prepare, communicate and execute this properly.

Another way to get them together is to get them to realize they both work towards a common goal: enable the business or their customers to use the software. The software they’re probably selling or utilizing to generate revenue. Guess what that money is indirectly being used for?

Communication is key!

If you read back a little, all tips basically come down to communication. It’s all about breaking down silo’s. You don’t want to separate the teams, you want to combine them. Make them one team. Whenever you have some kind of escalation, put members from both expertise in the team to solve it. Try to generate mutual respect. This is a slow process though, you can’t just throw the teams in a room and expect them to work together.

Leave a Reply