The CIOs Guide to Automated Deployment
Upcoming SlideShare
Loading in...5
×
 

The CIOs Guide to Automated Deployment

on

  • 590 views

What is application release automation and what does it mean for your organisation?

What is application release automation and what does it mean for your organisation?

Statistics

Views

Total Views
590
Views on SlideShare
590
Embed Views
0

Actions

Likes
0
Downloads
10
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

The CIOs Guide to Automated Deployment The CIOs Guide to Automated Deployment Document Transcript

  • What is application release automation and what does it mean to your organisation? The CIO’s Guide to Automated Deployment
  • The CIO’s Guide to Automated Deployment 1 The CIO’s Guide to Automated Deployment When it comes to application build and deployment, organisations historically rely on a wide range of different processes to manage this. These processes are often manual or partially scripted, with different parts of the organisation using different processes. The nature of this approach often leads to errors, inconsistencies and mistakes in the target environments. For example, if someone forgets to do part of the process or mis-configures something, then what worked in a test environment can fail in the production environment. This does not have to be the case. By integrating the deployment processes into a single, automated solution, it offers organisations a number of benefits - including increased efficiency, reliability, audit, speed to market and compliance, DR and governance. Automation allows organisations to manage exactly what is released into the environment and be confident that it will work. What is Build Automation? When it comes to build automation, the objective is to provide a standard framework for different projects or departments within an organisation to standardise the creation of deployable software assets. For example, where the development team is using partially scripted builds or manual builds from an IDE, which may differ between different parts of the organisation, build automation aims to standardise and automate these ad-hoc processes. The automation process itself caters for the difference between each of the different types of assets being built (i.e. web, database, business service, etc.) - but the overall process itself is a common one What we’re trying to do is bring all of these processes together, into a single build automation process that everybody understands across every project. Really, it’s a single process, a one best way. In recent years build automation has matured significantly to a point where there are now a variety of established patterns and tools, for things like dependency management and continuous integration, with tools such as Maven and Jenkins establishing themselves are market leaders in this area.
  • The CIO’s Guide to Automated Deployment 2 2 What is deployment automation? Historically, deployment automation is an area that has been tackled less successfully than build automation. In short, it is how we automate the deployment of the build components out into the target environments. A secondary and less mature area of deployment automation is the deployment of the configuration changes that the application requires (such as connections to databases, web services or other configuration). As this area matures vendors in this area are looking at increasingly sophisticated ways to package application components (such as WAR or EAR files) with the runtime dependencies required by the application itself - to create a deployment package that encapsulates not just the developed code but also a self describing installation process for the code onto the servers themselves. The target environments, (or runtime environments) that we are concerned with should be all the servers being deployed to from development through to production. This route the deployments take is sometimes referred to as the "path to production". However more often than not, the majority of organisations are in the dark ages when it comes to deployment - with many (and something of the majority) of these tasks being carried out manually. Ask any human to carry out a task dozens, hundreds or even thousands of times and you will find there are inconsistencies / errors - which are further componended by the fact that in most large organisations there are different individuals and teams performing these tasks (most notable the Development and also the Operations teams). By automating that into a single process, we can be assured what we deployed is always going to work. We manage and control all of the items that are going to be deployed; that is the code but it also includes the configuration. An important benefit to note about deployment automation is that "you are not only testing the application code - but the release process itself". A key objective here is we are increasing our confidence in the release process - because we are testing the same process time and again, to provide a much greater assurance when deployed ultimately to production.
  • The CIO’s Guide to Automated Deployment 3 What should an automated build and deployment tool provide? First of all, if we’re looking to purchase an automated build and deployment tool or maybe look at an open source tool, what we’re really looking for is something that will provide good security. We need to be able to secure who can do builds and deployments into targeted environments, so it needs to be very fine-grained. A fine grained security model also allows you to define different capabilities to roles within your organisation - developer, release manager, operations, etc. will all likely need to perform different functionality - whether its define a new automation activity, release a version of and application or approval a deployment to a production environment. We also want it to be auditable, so we can see who has deployed what to where and when. We also need to have a tool that has a friendly graphical user interface at the front-end, ideally web-based. We also want a tool that will support most of my organisation’s technologies, out of the box. And, where it doesn’t support those technologies, perhaps where we have some legacy technologies, we want good integration points so that we can call existing scripts and existing deployments processes. We also want the ability to be able to extend the tool, so that we are able to automate those processes that are bespoke to an organisation or that are not handled out of the box. What does an automated build and deployment solution replace? Many organisations have a combination of manual or partially scripted processes for both build and deployment. Now, more recently, there are a number of tools that have come on the market for build automation and so that tends to be better done than deployment automation. When it comes to deployment automation, there are still a lot of manual processes. This will typically be a number of scripts, which will be written for a particular platform. These will be run manually, by individuals, which results in a number of totally manual processes. People may be typing something to come online or using a graphical user interface to make some manual changes.
  • The CIO’s Guide to Automated Deployment 4 4 These do not lend themselves at all well to controlled deployments. As a result, we’re often left with a situation where a deployment to a production environment will simply not work. You’ll hear the expression, “Well, it worked in my test environment. Why is it not now working in my production environment?” The reason is because somebody has forgotten to do something. They’ve mis-configured something. This leads to all kinds of problems and it leads to a lot of fear. A lot of managers fear deploying code to production because they don’t know if it is going to work. We want the ability for to be able to complete a build and the deployment without understanding the underlying infrastructure, without understanding the underlying code, without understanding the underlying scripts, if there are any. It should be completely seamless for that person. What we’re talking about here is the ability to completely automate our process. We don’t want any jumping out to run command-line scripts. We don’t want any manual intervention at all. It should integrate well into a configuration management tool, so that you can manage change over time, you can compare change over time and you can compare change between environments over time. For example, by taking a snapshot of an environment now and then compare it with that environment in three weeks time. Or I can take a snapshot of a test environment and compare it with the production environment. In this way, I increase my confidence that my deployable artifacts are always going to deploy successfully every time. Do I need to use the same tool for both build and deployment automation? There isn't a single tool that provides all the capabilities an organisation will requires and almost without exception there will be a requirement for a separation of the build and deployment capability However, what is important is that the tools and processes are tightly integrated. The build of software or deployable assets is start of the release process for operations teams. Conversely the release of these assets to production should be the end of the cycle for the development team - and as such the tools for the creation and release of assets need to be closely linked. The idea that a Just In Time delivery system could run efficiently if the warehouse and the store did not have integrated tools and processes is easy for anyone to understand - but this analogy is all too common for a lot of IT organizations where you will have silos between the development team and the infrastructure team.
  • The CIO’s Guide to Automated Deployment 5 Quite often, the development team will build the code using whatever build tool they’re using. Then they’ll throw that over the fence to the infrastructure team, who will then deploy it. There’s very little collaboration between the two, as they often don’t know what configuration changes they should make. They might be detailed in an e-mail. They might be detailed in a spreadsheet; it is very easy to make errors. If you’ve got large numbers of environments, it becomes very difficult to manage. It’s extremely important that the build and deployment are coupled together, as tightly as you can, so that you have a seamless deployment process from the development of a piece of code right through to that being deployed to the production environment. What are the key benefits to a development team of an automated solution? Often, developers are really keen on doing development, but they’re not really interested in managing code releases over time. They’re not really interested in how that works in production. On the other hand, infrastructure teams are very interested in this. For a development team, having a build tool that they don’t really need to think too much about is very good for them. They are just checking their code. The build tool builds it automatically, it creates a label, and it creates a deployable artifact that they’re able to then deploy. They don’t want to be wasting time building code, making sure it works properly when they could be going on with what they’re really interested in, which is doing development. What are the key benefits to my operations team of an automated solution? Efficiency and consistency are two key benefits operations team should notice immediately. It would not be unusual where a set of manual steps are followed for a release for this to take 30 to 40 minutes even for a relatively straight forward application. When this activity is repeated dozens or even hundreds of times - it is inevitable that mistakes will occur. Conversely, an automated deployment solution should not only reduce the elapsed time for a deployment to happen significantly - but it should also but near guarantee that it occurs consistently.
  • The CIO’s Guide to Automated Deployment 6 6 Really, the amount of time you spend is just clicking the button to do the deployment. It then happens seamlessly. The other thing is we don’t have to provide out of hours support because people can do a self-service deployment. What we’re trying to achieve here is a complete end-to-end solution that makes it very simple for them to do deployments. It means developers, testers, and managers, depending on their role, can do their own deployments in a controlled manner to target environments, without ever actually touching any of those environments themselves. It also means we have a complete audit of what we’re doing. For example, from a manager’s point of view, they can see reports over time about how many deployments have succeeded, how many have failed, how many deployments we’re doing. Really, it’s removing the need for administrators to do the mundane tasks of handling deployments, day in and day out, and freeing them up to do value creating activities, such as designing new infrastructure and building new environments. What are the key benefits to IT Management of an automated solution? You will hear often hear the question, “Why can’t I deploy this environment?” being asked. The answer will be: “Joe Blogs isn’t here today and he’s the only one that knows how to deploy this environment and it’s all in his head.” Now, if we automate the solution, nothing is stored in anybody’s head. Everything is stored in a configuration management tool, in files, in a database. The knowledge of the application build or the application deployment is there for everybody to see. Anybody can do a build and anybody can do a deployment. For a manager, this is fantastic because the last thing that they want is single point failure, as that creates all kinds of problems. For example, what happens when that person is on holiday? Or worse - hit by a bus!
  • The CIO’s Guide to Automated Deployment 7 Secondly, the manager really wants to know what’s happening in his deployment estate and he really doesn’t want to have to get down to the nuts and bolts of logging onto servers to try to find out. If we can have a comprehensive suite of management reporting that will show, for example, where a particular version of code has been deployed to over time. Or, for a particular environment, what versions of code have been deployed to that environment over time. A whole set of management information becomes available, enabling a better understanding of when things are going wrong. What business benefits does an automated solution give me? With an automated solution, the ultimate benefit is cost-saving, which will be visible in terms of time to market. It enables testing cycles to be done more quickly, allows for faster deployments, and provides greater confidence about deployments. Also, if I have a fully automated solution, I can manage my environments much more effectively. I can leave code on expensive infrastructure for shorter periods of time and I can reuse that infrastructure much more efficiently and, therefore, save an awful lot of money. Infrastructure costs can be so high for large organisations managing that infrastructure effectively is very, very important. Do I need to adopt different Automation approaches for different technologies? Ideally, it’s better not to use different approaches for different technologies. What we really want is a single deployment and a single build solution that can be extendable to multiple technologies. That will mean it will have many different integration points with those technologies. In any case, the graphical user interface, the management, the security, the auditing and the actual deployment onto the target servers should be the same. It is only when we get down to the integration point of the individual application that it will be slightly different.
  • The CIO’s Guide to Automated Deployment 8 8 What are the key steps in implementing an Automated solution? The first thing to do is to establish what the existing processes are in place. Is it entirely manual? Do they have some existing scripts? Do they have some existing deployment process? It’s possible that some of those scripts, if they exist, which they probably will, could be reused. We do need to consider if this is the right thing to do? Should we reuse those scripts or are they actually a problem in themselves and should we completely rewrite the solution or use the solution that comes out of the box with the tooling? That’s the first thing. Secondly, and very, very importantly, we need to get a key stakeholder buy-in to making a change to the process. It is often quite a radical change in process that’s required. We need the development teams to buy-in. We need the management teams to buy-in. The testing teams, the infrastructure teams also have all got to be onboard with this. Otherwise, it’s really going to go nowhere and you could end up throwing an awful lot of money at this problem to no great benefit. Once we’ve got those two things sorted out, we need to choose a tool that we’re going to use. You’ll need to prove that the tool can be extended for all your technology types; it should cover most of the key technologies that you use. As we spoke about before, it really needs to be able to encompass your entire technology stack, not just a small part. We then need to run a proof of concept, usually, find out if it does actually work and then stage implementation. Normally, that would take the form of implementing on one project, perhaps a key project that you’ve got. You can try the implementation on that, run it parallel with the existing methodologies and, once it’s proven, then you would role that out to the entire estate.
  • The CIO’s Guide to Automated Deployment 9 Are there any particular considerations if an organisation has already written some automation scripts? In this case, we need to consider whether those scripts are still fit for purpose, whether they can be integrated into the tool or whether we should look at those scripts and rewrite them based on the new deployment tool that we’re going to use. This will be the case in a lot of organisations. They will often spend a lot of money developing a suite of scripts and there will quite often be resistance to having those scripts removed because of the people’s investment in time and money in producing them. Really, we need to look at this in a dispassionate way and decide: Is it time now? It’s time to move away from using scripts and move towards using tools that have been designed and built entirely with automation in mind, so that we can remove those single points of failures, remove those cases where everybody has tried to reinvent the wheel in every different organisation and move to an industry best practice where we know that we’re going to have success from day one. How complex is it to automate build and deployment activities? This varies depending on which approach you’re going to take. If you decide to stick with the bespoke scripted solutions, then this is obviously very complicated. You need to get people that are skilled. You also need to consider platform support. Am I going to write scripts for Unix and then have a requirement to this capability on Windows? Am I going to need to run on AS400? You need to consider all of the technologies that you need to support and you need to write the bespoke scripts for all of those. You need to think about all the processes you’re going to implement. It is very, very complicated and very, very time-consuming.
  • The CIO’s Guide to Automated Deployment 10 10 Then, of course, you’ve got the option to move to an automated tool. Now, if you’re going to move to an automated tool, this should simplify the process considerably. It will depend on whether that tool is going to cover all of the technologies that you expect to have to deploy or whether it will just cover some of them. It’s key when choosing the tool, that it is easily extendable. You need some kind of orchestration process that enables you to carry out business processes over and over again, so they are repeatable and have easy extension points out to your various tools. This would include scripting, perhaps a Java API, any other kind of API that might need to be supported. Is deployment automation only applicable to large organisations? Arguably, deployment automation is applicable to every organisation, irrespective of its size. Clearly, in a large organisation, it is vital. In smaller organisations, you’ll often find that the build and deployment role is done by people who are not naturally suited to or employed for that role. For example, developers will be doing builds and then you might have a Unix administrator whose day job is to manage the Unix estate, who is also doing deployments. That is not their key job. They don’t really want to do it. They haven’t put a lot of effort into it. In those scenarios, taking on board a deployment tool or a build tool will free those people up to do the job that they’re supposed to do. Plus, it will mean the deployments and the builds are done in a consistent manner. Presently, this might not be the case because the person is doing it as overtime or not part of their day job; they’re just filling in every now and again. For example, you get the scenario where, somebody says, “I need to deploy this code,” and the Unix person who’s doing his Unix job says, “I’ve got these four jobs to do and then I’ll get around to you this evening at 5:00,” instead of that person simply being able to go deploy, clicking on a button, it’s all done.
  • The CIO’s Guide to Automated Deployment 11 Are specific technologies more suited to automated deployment? I believe almost all, if not all, technologies can be automated. Normally, most enterprise technologies will have a scripting interface or some other interface that allows them to be controlled in an automated fashion. Many other technologies via scripting can be automated in some way. I don’t believe I’ve really ever come across anything that couldn’t be automated in one way or another. Even if it comes down to copying files and performing search and replace on the target servers, usually something can be done. What are the different types of automation tools available? IBM Rational and Atlassian are two key significant vendors in the provision of commercial build tools. Hudson / Jenkins and Maven have are particularly dominant in this space - and for good reason! There are also numerous other opensource tools available. The key opensource projects / tools for deployment automation are Puppet and Chef. There are others but these two are market leaders - and focus on the automation of opensource targets such as Tomcat, MySql, etc. At this time they do not provide any significant capability for commercial middleware and database platforms (i.e. WebSphere, Oracle, etc.). Of the large providers IBM and BMC are more established in this space - although more recently HP and others are developing their capabilities. There are a number of niche vendors specialising in Deployment Automation - most notably UrbanCode, Noliosoft and MidVision. These vendors focus more on enterprise / corporate middleware platforms (WebSphere, WebLogic, etc.) and differ from the open source vendors in that they are easier tools to adopt - with a quicker / simplier adoption process focusing on the 80 / 20 rule of benefits / time invested.
  • The CIO’s Guide to Automated Deployment 12 12 What is the future for Automated Deployment? I think where we’re going with automated deployments is more around the entire environment lifecycle management. At the moment, people are concentrating on taking a piece of code and deploying it through environments to production. Where I think this is going to go is doing that is a part of much bigger process. This would involve somebody requesting an environment in the first place, that environment being approved, built on a target set of servers, and then going through an entire lifecycle of deploying versions of code over time. In this space, we start to talk about environment leasing. A project in a large organisation may lease an environment for a period of time. Once that environment lease has run out, they stop paying their lease cost, that environment is deleted. That really focuses the mind for a project manager. “Do I really need this environment? I have to pay for it. Do I need it? Can the infrastructure be reused?” It helps to make the environment more fluid. There are many more environments built over time. It also means that you’re making best use of your infrastructure, which is a high cost in most organisations. Who should be involved in a build and deploy automated deployment solution? The teams that need to be involved in doing the complete end-to-end automation are going to be the development team and the infrastructure teams and also the testing teams. Really it’s a whole organisational shift to move away from having a siloed approach to development and deployment, to a mindset to say, “We have a single solution that everybody uses.” The developers buy into it. The testers buy into it. The infrastructure teams buy into it and it’s a seamless end-to-end solution and that does require the whole organisation to think about the way they currently work and perhaps consider moving to a new way of working.
  • The CIO’s Guide to Automated Deployment 13 Have you got further questions about automated deployment? Do you still have unanswered questions about automated deployment and how it would work in your organisation? Please get in touch with MidVision and we’ll be more than happy to answer questions for you. www.midvision.com +44 20 7643 1621