How to Start a Deployment Automation Project
Upcoming SlideShare
Loading in...5
×
 

How to Start a Deployment Automation Project

on

  • 177 views

The insider's guide on everything you need to know about starting a deployment automation project in your organisation

The insider's guide on everything you need to know about starting a deployment automation project in your organisation

Statistics

Views

Total Views
177
Views on SlideShare
177
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

How to Start a Deployment Automation Project How to Start a Deployment Automation Project Document Transcript

  • How to start a deployment automation project
  • How to start a deployment automation project 1 First you’ve got to identify your problem – and a need. There doesn’t have to be a disaster that brings the problem. It can be a number of things. Facts certainly can be a catalyst; Why has this all failed? We don’t have control of our CM? It also can be things like the cost of your existing resource. As your project grows, say, to encompass more and more fixes, more and more features, more and more customers, the infrastructure grows and scales and the code base grows. You get so many more people, and it becomes unmanageable, so there becomes a point, a tipping point where you just can’t go on like it. You have to change. That’s when people start looking for tools that are going to make their life easy throughout the whole ALM piece. In terms of the people involved, is it technical architect led, or is this actually at a level higher, the CIO saying actually, there’s a problem we’ve got to address? It can come from different layers. It doesn’t typically come from grassroots, but I guess technical architects would be more likely doing it on their project or their program. Really, you need a CIO buy-in to say we need to automate everything. If you do it from a technical architect point of view; you might well end up automating one part of your organization. If it’s from a CIO point of view, then there’ll be lots of technical architects working together to automate the whole thing at once. Is it too big of a project to actually go through all the environments? I think it’s too big a project to say, “We are tomorrow going to move across our organization and automate everything.” I think for the CIO to say we’re going to identify where we’ve got the biggest problem, or maybe even a project that doesn’t have the biggest problem but is a new project, we’re going to implement these practices across that project, so there is no human interaction all the way through the deployment process. We have a smooth process from development to production, which is going to sit outside of our existing processes and procedures. We’re going to experiment properly and test with something entirely new, and let’s see how it goes. You’ve got to put the will in to make it work.
  • Survey Results: What’s Stopping Businesses Automating? 2 2 Who in your team would you choose to lead at that point? Interesting question. Who I would choose would firstly depend on what we are talking about – manage it or implement it? You’ve got to put together a team. If you’ve got a new project, you have to put together a team of people who embrace change. From the project management point of view I suppose that would have to be somebody who’s been proven in this area before, or maybe elsewhere, or who is willing to change. From the implementation team, I would say, and having been in this position myself, the person that’s the hero, fixes everything, the go to person, would either be your biggest asset or your biggest detractor. Because they’ll either protect their position and not let anybody do anything, in which case you’re kind of back to square one, or they’ll drive it forward and be absolutely key to implementing it. What they’re effectively going to do is implement all the stuff that they do themselves to keep the show on the road. If you can get them to automate themselves out of a job on that particular project, that’s the key person or people. That has to make sense? That might be difficult because they might be prima donnas and difficult people to work with, but they are the ones that you need to get on board. I guess what you can sell to them is if it works on this project, we’re going to implement this everywhere, so you’ve got a job for life, which would appeal to them I suspect. These people have been good for the organisation; they’ve solved problems, but also helped cause problems. In the recent DevOps survey one question "What was stopping you from doing deployment automation" was answered with ‘The problem is a cowboy hero culture.’ It’s taking the cowboy hero and actually channeling them. When will we see ROI? It’s a big investment in time and money to kick deployment automation off and sometimes the payback comes further down the line. However, you should see ROI on that first project, because that first project will deliver faster and be easier to manage, and all the lessons learned will able to be moved onto the other projects. Of course the other projects will be more retrofitting, because your pilot’s potentially a green field probably.
  • How to start a deployment automation project 3 Maybe you can’t do it on a green field project, it’s best if you pick a new project. If it’s a large enough company, there are plenty of those, but if not then it’ll be some project that’s failing and needs to be sorted out ASAP, and maybe do it on that. The trouble with that is you start having failures when you start doing your deployments and you get a bad name. Is there any such thing as a green field project anymore for an organization? Doesn’t everything integrate? Well it all integrates, but you have new projects that kick off all the time. I mean I remember at one bank, we worked on lots of upgrade projects from old projects, but also 20 totally brand new new projects a year. Can you give examples of what some of those projects might be in a bank? The biggest one that I ever worked on was the total rewrite of Internet banking, which was really going from C++ to Java. It was a brand new project. There are lots. I can think of others like SOX-compliant projects when SOX-compliance came in. There were new projects that kicked off. Where it hit the IT teams from the WebSphere point of view was we were implementing solutions for SOX. Solutions that enforce SOX compliance for example, or Basel II. Any of those types of things. How are these green field deployment automation projects? Well effectively, they are. You can do them in one of two ways. You can put them into your usual sausage factory and go right, that’s another project that goes in, gets assigned a project manager, it goes through this process, all the ITIL stuff, it does all of that. Or in the case that we’ve spoken about, you can say we’re going to take this completely outside that and start again. We’re going to have a team that consists of developers and operators, and pull people from dev and ops and put it on some new infrastructure or new kit and build it out in the cloud. I mean, how far do you want to go?
  • Survey Results: What’s Stopping Businesses Automating? 4 4 Why is the banking industry a natural customer for deployment automation and RapidDeploy? Because the banks have been going for a long time. They were the first people to implement because banks generally have implemented large, complex IT systems for many decades. They’re now creaking under the weight. Unfortunately for the banks, because they were the first to implement large IT systems, they’re now the ones that are falling behind the newcomers to the industry because their IT systems are so sclerotic. So if you started again, you would have a totally different architecture, wouldn’t you? That’s why the banks need to change. I think they’re recognizing it now. They can’t carry on with these archaic systems that nobody knows how they work. They need to migrate off them. Is automation a way of creating that? I mean, because they look at the likes of Facebook. Big banks, they’re not going to be a Facebook, but they look at those people and they think, ‘Well, if we could just do 25% of what they do, then we would be in a much better place.’ It’s like in the banks you can’t do anything at the moment. In a way they’re so frightened about deploying anything to production that they’ve put in huge amounts of process, and this is where ITIL is responsible to that extent. They’re terrified of deploying to production. They’ve put huge amounts of process in place to basically stop you from deploying to production because they’re terrified of it. What’s that do? That means they’re basically stopping you from deploying new changes that are potentially market differentiators or whatever.
  • How to start a deployment automation project 5