These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

DevOps

IBM Limited Edition

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

DevOps

IBM Limited Edition

by Sanjeev Sharma

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

DevOps For Dummies®, IBM Limited Edition

Published by

John Wiley & Sons, Inc.

111 River St.

Hoboken, NJ 07030-5774

www.wiley.com

Copyright © 2014 by John Wiley & Sons, Inc., Hoboken, New Jersey No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without the prior written permission of the Publisher. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ

07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.

Trademarks: Wiley, For Dummies, the Dummies Man logo, The Dummies Way, Dummies.com, Making Everything Easier, and related trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries, and may not be used without written permission. IBM and the IBM logo are registered trademarks of IBM. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc., is not associated with any product or vendor mentioned in this book.

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY: THE PUBLISHER AND THE AUTHOR MAKE

NO REPRESENTATIONS OR WARRANTIES WITH RESPECT TO THE ACCURACY OR

COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL

WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR

PROMOTIONAL MATERIALS. THE ADVICE AND STRATEGIES CONTAINED HEREIN MAY NOT BE

SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT

THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING, OR OTHER

PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR

THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN

ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR

THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY

PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE

THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED

BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ.

For general information on our other products and services, or how to create a custom For Dummies book for your business or organization, please contact our Business Development Department in

the U.S. at 877-409-4177, contact info@dummies.biz, or visit www.wiley.com/go/custompub.

For information about licensing the For Dummies brand for products or services, contact

BrandedRights&Licenses@Wiley.com.

ISBN 978-1-118-73378-3 (pbk); ISBN 978-1-118-73470-4 (ebk)

Manufactured in the United States of America

10 9 8 7 6 5 4 3 2 1

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Table of Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

About This Book ........................................................................ 1

Icons Used in This Book ............................................................ 2

Beyond the Book ........................................................................ 2

Chapter 1: What Is DevOps? . . . . . . . . . . . . . . . . . . . . . . . .3

Understanding the Business Need for DevOps ...................... 3

Recognizing the Business Value of DevOps ........................... 4

Enhanced customer experience .................................... 5

Increased capacity to innovate ...................................... 5

Faster time to value ......................................................... 6

Seeing How DevOps Works ....................................................... 6

Develop and test against production-like systems ..... 6

Deploy with repeatable, reliable processes ................. 7

Monitor and validate operational quality ..................... 8

Amplify feedback loops................................................... 8

Chapter 2: Looking at DevOps Capabilities . . . . . . . . . . .9

Paths to DevOps Adoption ....................................................... 9

Plan and Measure ..................................................................... 10

Develop and Test ..................................................................... 11

Collaborative development .......................................... 11

Continuous testing ........................................................ 12

Release and Deploy.................................................................. 12

Monitor and Optimize ............................................................. 13

Continuous monitoring ................................................. 13

Continuous customer feedback and optimization .... 13

Chapter 3: Adopting DevOps . . . . . . . . . . . . . . . . . . . . . . .15

People in DevOps ..................................................................... 15

DevOps culture .............................................................. 16

Identifying business objectives ......................... 16

Create an environment of sharing ..................... 17

DevOps team .................................................................. 18

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

DevOps For Dummies, IBM Limited Edition

vi

Process in DevOps ................................................................... 18

DevOps as a business process ..................................... 18

Change management process ...................................... 19

DevOps practices ........................................................... 20

Release planning .................................................. 20

Continuous integration ....................................... 21

Continuous delivery ............................................ 21

Continuous testing .............................................. 21

Continuous monitoring and feedback .............. 22

Continuous improvement ................................... 22

Technology in DevOps ............................................................ 23

Infrastructure as Code .................................................. 24

Delivery pipeline ............................................................ 24

Development environment ................................. 25

Build stage ............................................................ 25

Package repository .............................................. 26

Test environment ................................................ 26

Stage and production environments ................ 27

Deployment automation and release management ... 27

Deployment automation ..................................... 27

Release management .......................................... 28

Chapter 4: Solving New Problems with DevOps . . . . . .29

Cloud Technology .................................................................... 29

Mobile Applications ................................................................. 30

ALM Processes ......................................................................... 31

Multiple-Tier Applications ...................................................... 32

Supply Chains ........................................................................... 33

The Internet of Things ............................................................. 33

Chapter 5: Ten DevOps Myths . . . . . . . . . . . . . . . . . . . . . .35

DevOps Is Only for “Born on the Web” Shops ..................... 35

DevOps Is Operations Learning How to Code ...................... 35

DevOps Is Just for Development and Operations ................ 36

DevOps Isn’t for ITIL Shops .................................................... 36

DevOps Isn’t for Regulated Industries .................................. 36

DevOps Isn’t for Outsourced Development .......................... 37

No Cloud Means No DevOps................................................... 37

DevOps Isn’t for Large, Complex Systems ............................ 38

DevOps Is Only about Communication ................................. 38

DevOps Means Continuous Change Deployment ................ 38

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Publisher’s Acknowledgments

We’re proud of this book and of the people who worked on it. For details on how to

create a custom For Dummies book for your business or organization, contact info@

dummies.biz or visit www.wiley.com/go/custompub. For details on licensing the

For Dummies brand for products or services, contact BrandedRights&Licenses@

Wiley.com. 

Some of the people who helped bring this book to market include the following:

Acquisitions, Editorial, and

Composition Services

Vertical Websites

Senior Project Coordinator: Kristie Rees

Project Editor: Carrie A. Burchfield

Layout and Graphics: Carrie A. Cesavice

Editorial Manager: Rev Mengle

Proofreader: Melissa Cossell

Business Development Representative:

Special Help: Bernard Coyne

Sue Blessing

Custom Publishing Project Specialist:

Michael Sullivan

Publishing and Editorial for Technology Dummies

Richard Swadley, Vice President and Executive Group Publisher Andy Cummings, Vice President and Publisher

Mary Bednarek, Executive Director, Acquisitions

Mary C. Corder, Editorial Director

Publishing and Editorial for Consumer Dummies

Kathleen Nebenhaus, Vice President and Executive Publisher Composition Services

Debbie Stailey, Director of Composition Services

Business Development

Lisa Coleman, Director, New Market and Brand Development These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Introduction

DevOps (short for development and operations), like

most new approaches, is only a buzzword for many

people. Everyone talks about it, but not everyone knows what

it is. In broad terms, DevOps is an approach based on lean and agile principles in which business owners and the development, operations, and quality assurance departments collabo-

rate to deliver software in a continuous manner that enables

the business to more quickly seize market opportunities and

reduce the time to include customer feedback. Indeed, enter-

prise applications are so diverse and composed of multiple

technologies, databases, end-user devices, and so on, that

only a DevOps approach will be successful when dealing with

these complexities. Opinions differ on how to use it, however.

Some people say that DevOps is for practitioners only; others

say that it revolves around the cloud. IBM takes a broad and

holistic view and sees DevOps as a business-driven soft-

ware delivery approach -— an approach that takes a new or

enhanced business capability from an idea all the way to pro-

duction, providing business value to customers in an efficient manner and capturing feedback as customers engage with the

capability. To do this, you need participation from stakehold-

ers beyond just the development and operations teams. A

true DevOps approach includes lines of business, practitio-

ners, executives, partners, suppliers, and so on.

About This Book

In this book, I take a business-centric approach to DevOps.

Today’s fast-moving world makes DevOps essential to all

enterprises that must be agile and lean enough to respond

rapidly to changes such as customer demands, market

conditions, competitive pressures, or regulatory requirements.

If you’re reading this book, I assume that you’ve heard about

DevOps but want to understand what it means and how your

company can gain business benefits from it. This book is

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

04_9781118733783-intro.indd 1

10/1/13 2:30 PM

DevOps For Dummies, IBM Limited Edition

2

geared to executives, decision makers, and practitioners who

are new to the field of DevOps, who seek more information

about the approach, and who want to cut through the

hype surrounding the concept to get to the meat of it.

Icons Used in This Book

You’ll find several icons in the margins of this book. Here’s

what they mean.

The Tip icon points out helpful information on various

aspects of DevOps.

Anything that has a Remember icon is something that you

want to keep in mind.

The Warning icon alerts you to critical information.

Technical Stuff material goes beyond the basics of DevOps. It

isn’t essential reading, however.

Beyond the Book

You can find additional information about DevOps (and about

IBM’s approach to it) by visiting the following web pages:

✓

IBM DevOps Solution: www.ibm.com/ibm/devops/us/en

✓

DevOps — the IBM approach (white paper): ibm.co/

1a54r3m

✓ The Software Edge (study): http://ibm.co/156KdoO

✓

IBM DevOps Products: jazz.net/products/devops

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

04_9781118733783-intro.indd 2

10/1/13 2:30 PM

Chapter 1

What Is DevOps?

In This Chapter

▶ Seeing a business need for DevOps

▶ Finding business value in DevOps

▶ Understanding DevOps principles

M aking any change in “business as usual” is always hard

and usually requires an investment. So whenever an

organization adopts any new technology, methodology, or

approach, that adoption has to be driven by a business need.

To develop a business case for adopting DevOps, you must

understand the business need for it, including the challenges

that it addresses. In this chapter, I give you the foundation

you need to start building your case.

Understanding the Business

Need for DevOps

Organizations want to create innovative applications or ser-

vices to solve business problems. They may want to address

internal business problems (such as creating a better customer relationship management system) or to help their customers or

end-users (such as by providing a new mobile app).

Many organizations aren’t successful with software projects,

however, and their failures are often related to challenges

in software development and delivery. Although most enter-

prises feel that software development and delivery are criti-

cal, a recent IBM survey of the industry found that only 25

percent believe that their teams are effective. This execution gap leads to missed business opportunities.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

4 DevOps For Dummies, IBM Limited Edition

This problem is further amplified by a major shift in the types of applications that businesses are required to deliver, from

systems of record to systems of engagement:

✓

Systems of record: Traditional software applications are large systems that function as systems of record, which

contain massive amounts of data and/or transactions and

are designed to be highly reliable and stable. Because these

applications don’t need to change often, organizations can

satisfy their customers and their own business needs by

delivering only one or two large new releases a year.

✓

Systems of engagement: With the advent of mobile com-

munications and the maturation of web applications,

systems of record are being supplemented by systems

of engagement, which customers can access directly and

use to interact with the business. Such applications must

be easy to use, high performing, and, systems require

rapid change to address customers’ changing needs and

evolving market forces.

Because systems of engagement are used directly by custom-

ers, they require intense focus on user experience, speed of

delivery, and agility — in other words, a DevOps approach.

Systems of engagement aren’t isolated islands and are often

tied to systems of record, so rapid changes to systems of

engagement result in changes to systems of record. Indeed

any kind of system that needs rapid delivery of innovation

requires DevOps. Such innovation is driven primarily by

emerging technology trends such as cloud computing, mobile

applications, Big Data, and social media, which may affect all types of systems. I discuss these emerging technologies in

light of DevOps in Chapter 4.

Recognizing the Business

Value of DevOps

DevOps applies agile and lean principles across the entire

software supply chain. It enables a business to maximize the

speed of its delivery of a product or service, from initial idea to production release to customer feedback to enhancements

based on that feedback.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Chapter 1: What Is DevOps?

5

Because DevOps improves the way that a business delivers

value to its customers, suppliers, and partners, it’s an essential business process, not just an IT capability.

DevOps provides significant return on investment in three

areas:

✓

Enhanced customer experience

✓

Increased capacity to innovate

✓

Faster time to value

I discuss all three areas in the following sections.

Enhanced customer experience

Delivering an enhanced (that is, differentiated and engaging)

customer experience builds customer loyalty and increases

market share. To deliver this experience, a business must

continuously obtain and respond to customer feedback, which

requires mechanisms to get fast feedback from all the stake-

holders in the software application that’s being delivered: customers, lines of business, users, suppliers, partners, and so on.

In today’s world of systems of engagement (see “Understanding

the Business Need for DevOps,” earlier in this chapter), this

ability to react and adapt in an agile manner leads to enhanced customer experience and loyalty.

Increased capacity to innovate

Modern organizations use lean thinking approaches to increase

their capacity to innovate. Their goals are to reduce waste and rework and to shift resources to higher-value activities.

An example of a common practice in lean thinking is A-B testing, in which organizations ask a small group of users to test and rate two or more sets of software that have different capabilities. Then the better-capability set is rolled out to all users, and the unsuccessful version is rolled back. Such A-B testing

is realistic only with efficient and automated mechanisms

such as those that DevOps facilitates.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

6 DevOps For Dummies, IBM Limited Edition

Faster time to value

Speeding time to value involves developing a culture, prac-

tices, and automation that allow for fast, efficient, and reliable software delivery through to production. DevOps, when

adopted as a business capability, provides the tools and cul-

ture required to facilitate efficient release planning, predict-ability, and success.

The definition of value varies from organization to organization and even from project to project, but the goal of DevOps

is to deliver this value faster and more efficiently.

Seeing How DevOps Works

The DevOps movement has produced several principles that

have evolved over time and are still evolving. Several solution providers, including IBM, have developed their own variants.

All these principles, however, take a holistic approach to

DevOps, and organizations of all sizes can adopt them. These

principles are

✓

Develop and test against production-like systems

✓

Deploy with repeatable, reliable processes

✓

Monitor and validate operational quality

✓

Amplify feedback loops

I describe the principles in more detail in the following

sections.

Develop and test against

production-like systems

This principle stems from the DevOps concept shift left, in which operations concerns move earlier in the software delivery life cycle, toward development (see Figure 1-1).

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Chapter 1: What Is DevOps?

7

Figure 1-1: The shift-left concept moves operations earlier in the development life cycle.

The goal is to allow development and quality assurance (QA)

teams to develop and test against systems that behave like the production system, so that they can see how the application

behaves and performs well before it’s ready for deployment.

The first exposure of the application to a productionlike system should be as early in the life cycle as possible to address two major potential challenges. First, it allows the application to be tested in an environment that’s close to the actual production environment the application will be delivered to; and second, it allows for the application delivery processes themselves to be tested and validated upfront.

From an operations perspective, too, this principle has tre-

mendous value. It enables the operations team to see early in

the cycle how their environment will behave when it supports

the application, thereby allowing them to create a fine-tuned, application-aware environment.

Deploy with repeatable,

reliable processes

As the name suggests, this principle allows development and

operations to support an agile (or at least iterative) software development process all the way through to production.

Automation is essential to create processes that are itera-

tive, frequent, repeatable, and reliable, so the organization

must create a delivery pipeline that allows for continuous,

automated deployment and testing. I talk more about delivery

pipelines in Chapter 3.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

8 DevOps For Dummies, IBM Limited Edition

Frequent deployments also allow teams to test the deploy-

ment processes themselves, thereby lowering the risk of

deployment failures at release time.

Monitor and validate

operational quality

Organizations typically are good at monitoring applications

and systems in production because they have tools that

capture production systems’ metrics in real time. But they

monitor in a siloed and disconnected manner. This principle

moves monitoring earlier in the life cycle by requiring that

automated testing be done early and often in the life cycle to monitor functional and non-functional characteristics of the

application. Whenever an application is deployed and tested,

quality metrics should be captured and analyzed. Frequent

monitoring provides early warning about operational and

quality issues that may occur in production.

These metrics should be captured in a format that all

business stakeholders can understand and use.

Amplify feedback loops

One goal of DevOps is to enable organizations to react and

make changes more rapidly. In software delivery, this goal

requires an organization to get quick feedback and then learn

rapidly from every action it takes. This principle calls for

organizations to create communication channels that allow all

stakeholders to access and act on feedback.

✓

Development may act by adjusting its project plans or

priorities.

✓

Production may act by enhancing the production

environments.

✓

Business may act by modifying its release plans.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Chapter 2

Looking at DevOps

Capabilities

In This Chapter

▶ Understanding the reference architecture of DevOps

▶ Considering four paths to DevOps adoption

The capabilities that make up DevOps are a broad set that

span the software delivery life cycle. Where an organiza-

tion starts with DevOps depends on its business objectives

and goals — what challenges it’s trying to address and what

gaps in its software delivery capabilities need to be filled.

In this chapter, I look at a DevOps reference architecture and the various ways that it enables a business to use DevOps.

Paths to DevOps Adoption

A reference architecture provides a template of a proven solution by using a set of preferred methods and capabilities. The DevOps reference architectures discussed in this chapter

help practitioners access and use the guidelines, directives,

and other material that they need to architect or design a

DevOps platform that accommodates people, processes, and

technology (see Chapter 3).

A reference architecture provides capabilities through its

various components. These capabilities in turn may be pro-

vided by a single component or a group of components work-

ing together. Therefore, you can view the DevOps reference

architecture, shown in Figure 2-1, from the perspective of the These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

06_9781118733783-ch02.indd 9

10/1/13 2:03 PM

DevOps For Dummies, IBM Limited Edition

10

core capabilities that it’s intended to provide. As the abstract architecture evolves to concrete form, these capabilities are

provided by a set of effectively enabled people, defined prac-

tices, and automation tools.

Figure 2-1: DevOps reference architecture.

The DevOps reference architecture shown in Figure 2-1 pro-

poses the following four sets of adoption paths:

✓

Plan and measure

✓

Develop and test

✓

Release and deploy

✓

Monitor and optimize

In the following sections, I take a detailed look at these adoption paths.

Plan and Measure

This adoption path consists of one practice that focuses on

the lines of business and their planning processes: continuous business planning.

Businesses need to be agile and able to react quickly to

customer feedback. Consequently, many businesses today

employ lean thinking techniques. These techniques involve

starting small by identifying the outcomes and resources

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

06_9781118733783-ch02.indd 10

10/1/13 2:03 PM

Chapter 2: Looking at DevOps Capabilities

11

needed to test the business vision or value, and then continu-

ously adapting and adjusting based on customer feedback.

To achieve these goals, organizations measure progress, find

out what customers really want, and then shift direction by

updating their business plans accordingly, allowing them to

make continuous trade-off decisions in a resource constrained

environment.

Develop and Test

This adoption path involves two practices: collaborative

development and continuous testing. As such, it forms the

core of development and quality assurance (QA) capabilities.

Collaborative development

Software delivery efforts in an enterprise involve large num-

bers of cross-functional teams, including lines-of-business

owners, business analysts, enterprise and software architects, developers, QA practitioners, operations personnel, security

specialists, suppliers, and partners. Practitioners from these teams work on multiple platforms and may be spread across

multiple locations. Collaborative development enables these practitioners to work together by providing a common set of

practices and a common platform they can use to create and

deliver software.

One core capability included within collaborative development

is continuous integration (see Figure 2-2), a practice in which software developers continuously or frequently integrate their work with that of other members of the development team.

Figure 2-2: Collaboration via continuous integration.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

06_9781118733783-ch02.indd 11

10/1/13 2:03 PM

DevOps For Dummies, IBM Limited Edition

12

Continuous integration was made popular by the agile move-

ment. The idea is for developers to regularly integrate their

work with that of the rest of the developers on their team

and then test the integrated work. In the case of complex

systems made up of multiple systems or services, developers

also regularly integrate their work with other systems and

services. Regular integration of results leads to early discovery and exposure of integration risks. In complex systems, it

also exposes known and unknown risks — both technical and

schedule-related.

Continuous testing

Continuous integration (see the preceding section) has sev-

eral goals:

✓

Enable ongoing testing and verification of code

✓

Validate that the code produced and integrated with that

of other developers and other components of the appli-

cation functions and performs as designed

✓

Continuously test the application being developed

Continuous testing means testing earlier and continuously across the life cycle, which results in reduced costs and short-ened testing cycles and achieved continuous feedback on

quality. This occurs by adopting capabilities like automated

testing and service virtualization. Service virtualization is the new capability for simulation of production-like environments

and makes continuous testing feasible.

Release and Deploy

Release and deploy forms the adoption path where most of

the root capabilities of DevOps originated. Continuous release and deployment take the concept of continuous integration to the next step. The practice that enables release and

deploy also enables the creation of a delivery pipeline (see

Chapter 3). This pipeline facilitates continuous deployment

of software to QA and then to production in an efficient, automated manner. The goal of continuous release and deploy-

ment is to release new features to customers and users as

soon as possible.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

06_9781118733783-ch02.indd 12

10/1/13 2:03 PM

Chapter 2: Looking at DevOps Capabilities

13

Most of the tooling and processes that make up the core of

DevOps technology exist to facilitate continuous integration,

continuous release, and continuous deployment. I discuss

these topics in more detail in later chapters.

Monitor and Optimize

The monitor and optimize adoption path includes two practices that allow businesses to monitor how released applications are performing in production and to receive feedback from customers. This data allows the businesses to react in an agile manner and change their business plans as necessary.

Continuous monitoring

Continuous monitoring provides data and metrics to

Operations, QA, Development, lines-of-business personnel,

and other stakeholders about applications at different stages

of the delivery cycle.

These metrics aren’t limited to production. Such metrics

allow stakeholders to react by enhancing or changing the fea-

tures being delivered and/or the business plans required to

deliver them.

Continuous customer feedback

and optimization

The two most important types of information that a software

delivery team can get are data about how customers use the

application and feedback that those customers provide upon

using the application. New technologies allow businesses to

capture customer behavior and customer pain points right

as they use the application. This feedback allows different

stakeholders to take appropriate actions to improve the appli-

cations and enhance customer experience. Lines of business

may adjust their business plans, development may adjust the

capabilities it delivers, and operations may enhance the envi-

ronment in which the application is deployed. This continuous

feedback loop is an essential component of DevOps, allowing

businesses to be more agile and responsive to customer needs.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

06_9781118733783-ch02.indd 13

10/1/13 2:03 PM

DevOps For Dummies, IBM Limited Edition

14

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

06_9781118733783-ch02.indd 14

10/1/13 2:03 PM

Chapter 3

Adopting DevOps

In This Chapter

▶ Making people more efficient

▶ Streamlining processes

▶ Choosing the right tools

Adopting any new capability typically requires a plan that

spans people, process, and technology. You can’t suc-

ceed in adopting new capabilities — especially in an enterprise that has multiple, potentially distributed stakeholders — without taking into consideration all three aspects of the capabilities being adopted.

In this chapter, I discuss the people, process, and technology aspects of DevOps.

Although the name DevOps suggests development- and

operations-based capabilities, DevOps is an enterprise capa-

bility that spans all stakeholders in an organization, including business owners, architecture, design, development, quality

assurance (QA), operations, security, partners, and suppliers.

Excluding any stakeholder — internal or external — leads to

an incomplete implementation of DevOps.

People in DevOps

This section addresses the people aspect of adopting DevOps,

including creating the necessary culture.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 15

10/1/13 2:05 PM

DevOps For Dummies, IBM Limited Edition

16

DevOps culture

At its root, DevOps is a cultural movement; it’s all about

people. An organization may adopt the most efficient pro-

cesses or automated tools possible, but they’re useless with-

out the people who eventually must execute those processes

and use those tools. Building a DevOps culture, therefore, is

at the core of DevOps adoption.

A DevOps culture is characterized by a high degree of col-

laboration across roles, focus on business instead of depart-

mental objectives, trust, and high value placed on learning

through experimentation.

Building a culture isn’t like adopting a process or a tool. It requires (for lack of a better term) social engineering of teams of people, each with unique predispositions, experiences, and

biases. This diversity can make culture-building challenging

and difficult.

Lean and agile transformation practices are at the core of

DevOps, and if your organization has already applied these,

they can be leveraged to help adopt a DevOps culture.

Identifying business objectives

The first task in creating a culture is getting everyone headed in the same direction and working toward the same goal,

which means identifying common business objectives for the

team and the organization as a whole. It’s important to incent the entire team based on business outcomes versus conflict-ing team incentives. When people know what common goal

they’re working toward and how their progress toward that

goal is going to be measured, there are fewer challenges from

teams or practitioners that have their own priorities.

DevOps isn’t the goal. It helps you reach your goals.

Chapter 4 highlights several new business challenges that

DevOps addresses. Your organization can use those chal-

lenges as a starting point to identify goals that it wants to

achieve; then it can develop a common set of milestones

toward those goals for different teams of stakeholders to use.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 16

10/1/13 2:05 PM

Chapter 3: Adopting DevOps

17

Measuring culture

Measuring culture is extremely diffi-

development team member reaches

cult. How do you accurately measure out to a member of an operations or improved collaboration or improved QA team to collaborate on resolving morale? You could take a direct mea-an issue without going through offi-

sure of attitudes and team morale by cial channels or multiple layers of taking surveys, but surveys can have management.

a high statistical error rate, as teams Collaboration and communication usually are small.

across stakeholders — that’s the

Conversely, you can take an indirect culture of DevOps.

measure by tracking how often a

Create an environment of sharing

After identifying common business objectives, the next step in building a DevOps culture requires the leaders of the organization to work with their teams to create an environment and

culture of collaboration and sharing.

Leaders must remove any self-imposed barriers to coopera-

tion. Typical measurements reward operations teams for

uptime and stability, and reward developers for new features

delivered, but they pit these groups against each other.

Operations knows that the best protection for production is

to accept no changes, for example, and Development has little

incentive to focus on quality. Replace these measurements

with shared responsibility for delivering new capabilities

quickly and safely.

The leaders of the organization should further encourage col-

laboration by improving visibility. Establishing a common set

of collaboration tools is essential, especially when teams are geographically distributed and can’t work together in person.

Giving all stakeholders visibility into a project’s goals and

status is crucial for building a DevOps culture based on trust and collaboration.

Sometimes, building a DevOps culture requires people to

change. Those who are unwilling to change — that is, to adopt

the DevOps culture — may need to be reassigned.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 17

10/1/13 2:05 PM

DevOps For Dummies, IBM Limited Edition

18

DevOps team

The arguments for and against having a separate DevOps team

are as old as the concept itself. Some organizations, such as

Netflix, don’t have separate development and operations teams; instead, a single “NoOps” team owns both sets of responsibilities. Other organizations have succeeded with DevOps liaison

teams, which resolve any conflicts and promote collaboration.

Such a team may be an existing tools group or process group, or it may be a new team staffed by representatives of all teams that have a stake in the application being delivered.

If you choose to have a DevOps team, your most important

goal is to ensure that it functions as a Center of Excellence

that facilitates collaboration without adding a new layer of

bureaucracy or becoming the team that owns addressing all

DevOps related problems — a development that would defeat

the purpose of adopting a DevOps culture.

Process in DevOps

In the preceding section, I discussed the role of people and

culture in adopting DevOps. Processes define what those

people do. Your organization can have a great culture of col-

laboration, but if people are doing the wrong things or doing

the right things in the wrong way, failure is still likely.

A vast number of processes are identified with DevOps — too

many to cover in this book. This section discusses some of the key processes in light of their adoption across an enterprise.

DevOps as a business process

DevOps as a capability affects a whole business. It makes the

business more agile and improves its delivery of capabilities

to customers. You can extend DevOps further by looking at

it as a business process: a collection of activities or tasks that produces a specific result (service or product) for customers.

In the reference architecture introduced in Chapter 2, the

DevOps business process involves taking capabilities from

the idea (typically identified with business owners) through

development and testing to production.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 18

10/1/13 2:05 PM

Chapter 3: Adopting DevOps

19

Although this business process isn’t mature enough to be cap-

tured in a set of simple process flows, you should capture the process flows that your organization already uses to deliver

capabilities. Then you can identify areas of improvement,

both by improving the processes themselves and by introduc-

ing automation (see the “Technology in DevOps” section, later

in this chapter).

Change management process

Change management is a set of activities designed to control, manage, and track change by identifying the work products

that are likely to change and the processes used to imple-

ment that change. The change management process that an

organization uses is an inherent part of the broader DevOps

process flow. Change management drives the way the DevOps

processes absorb and react to change requests and customer

feedback.

Organizations that have adopted application lifecycle manage-

ment (ALM) already have well-defined and (probably) auto-

mated change management processes in place.

Change management should include processes that enable

the following capabilities:

✓

Work-item management

✓

Configurable work-item workflows

✓

Project configuration management

✓

Planning (agile and iterative)

✓

Role-based artifact access control

Traditional change management approaches tend to be limited

to change request or defect management, with limited capabil-

ity to trace the events between the change requests or defects and the associated code or requirements. These approaches

don’t provide integrated work-item management across the life

cycle or built-in capability to trace all types of assets. DevOps, however, requires all stakeholders to be able to view and collaborate on all changes across the software development life

cycle.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 19

10/1/13 2:05 PM

DevOps For Dummies, IBM Limited Edition

20

DevOps- or ALM-centric change management includes pro-

cesses that provide work-item management for all projects,

tasks, and associated assets — not just those affected by

change requests or defects. It also includes processes that

enable the enterprise to link work items to all artifacts, project assets, and other work items that are created, modified,

referenced, or deleted by any practitioner who works on

them. These processes give team members role-based access

to all change-related information and also support iterative

and agile project development efforts.

DevOps practices

Following are a few specific practices that you need to include when you adopt DevOps:

✓

Release planning

✓

Continuous integration

✓

Continuous delivery

✓

Continuous testing

✓

Continuous monitoring and feedback

The following sections examine these practices in detail.

Release planning

Release planning is a critical business function, driven by

business needs to offer capabilities to customers and the

timelines of these needs. Therefore, businesses require well-

defined release planning and management processes that

drive release roadmaps, project plans, and delivery sched-

ules, as well as end-to-end traceability across these processes.

Most companies today accomplish this task by using spread-

sheets and holding meetings (often, long ones) with all

stakeholders across the business to track all business needs

applications under development, their development status,

and release plans. Well-defined processes and automation,

however, eliminate the need for those spreadsheets and

meetings, and enable streamlined and — more importantly —

predictable releases. Leveraging lean and agile practices

also results in smaller, more frequent releases, permitting

enhanced focus on quality.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 20

10/1/13 2:05 PM

Chapter 3: Adopting DevOps

21

Continuous integration

Continuous integration (described in Chapter 2) adds tremen-

dous value in DevOps by allowing large teams of developers,

working on cross-technology components in multiple loca-

tions, to deliver software in an agile manner. It also ensures that each team’s work is continuously integrated with that of

other development teams and then validated. Continuous inte-

gration thereby reduces risk and identifies issues earlier in the software development life cycle.

Continuous delivery

Continuous integration naturally leads to the practice of con-

tinuous delivery: the process of automating the deployment

of the software to the testing, system testing, staging, and production environments. Although some organizations stop short

of production, those that adopt DevOps generally use the same

automated process in all environments to improve efficiency

and reduce the risk introduced by inconsistent processes.

In test environments, automating configuration, refreshing test data, and then deploying the software to the test environment

followed by the execution of automated tests, speeds feedback

cycles of test results back to development.

Adopting continuous delivery typically is the most critical

part of adopting DevOps. To many DevOps practitioners,

DevOps is limited to continuous delivery, so most tools pro-

moted as DevOps tools address only this process. As you

see throughout this book, however, DevOps is much broader

in scope. Continuous delivery is an essential component of

DevOps but not the only component.

Based on your organization’s business needs and pressing

challenges, you may choose to start adoption with another of

the processes or adoption paths described in Chapter 2.

Continuous testing

I introduced continuous testing in Chapter 2. From a process

perspective, you need to adopt processes in three areas to

enable continuous testing:

✓

Test environment provisioning and configuration

✓

Test data management

✓

Integration, functional, performance, and security testing

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 21

10/1/13 2:05 PM

DevOps For Dummies, IBM Limited Edition

22

In an organization, QA teams need to determine what pro-

cesses to adopt for each area. The processes that they adopt

may vary from project to project, based on individual testing

needs and on the requirements of service level agreements.

Customer-facing applications may need more security testing

than internal applications do, for example. Test environment

provisioning and test data management are more important

challenges for projects that use agile methodologies and prac-

tice continuous integration than they are for projects that use waterfall methodology and test only once every few months.

Likewise, function and performance test requirements for com-

plex applications with components that have different delivery cycles are different from those for simple, monolithic web apps.

Continuous monitoring and feedback

Customer feedback comes in different forms, such as tick-

ets opened by customers, formal change requests, informal

complaints, and ratings in app stores. Especially due to the

popularity of social media and app stores (see Chapter 4),

businesses need well-defined processes to absorb the feed-

back from myriad sources and incorporate them into software

delivery plans. These processes also need to be agile enough

to adapt to market and regulatory changes.

Feedback also comes from monitoring data. This data comes

from the servers running the application; from Development,

QA, and Production; or from metrics tools embedded in the

application that capture user actions.

Data overload is possible, so businesses need data-capture

and data-use processes that enhance their applications and

the environments they run in.

Continuous improvement

In true lean-thinking fashion, process adoption isn’t a one-time action, but an ongoing process. An organization should have

built-in processes that identify areas for improvement as the

organization matures and learns from the processes it has

adopted. Many businesses have process improvement teams

that work on improving processes based on observations

and lessons learned; others allow the teams that adopt the

processes to self-assess and determine their own process-

improvement paths. Regardless of the method used, the goal

is to enable continuous improvement.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 22

10/1/13 2:05 PM

Chapter 3: Adopting DevOps

23

Measuring process adoption

You can measure the success of pro-

You can use any of several well-

cess adoption by seeing whether a defined frameworks to measure pro-set of efficiency and quality metrics cess maturity. For DevOps-specific is improving over time. This type of processes, models such as the new measurement has two prerequisites:

IBM DevOps Maturity Model can

assess maturity. More information

✓ You must identify the right set about the IBM maturity model is of efficiency and quality met-

available at

rics. These metrics should really

ibm.biz/BdDYbv.

matter to the business.

✓ You need to establish a base-

line against which to measure

improvement.

Technology in DevOps

Technology enables people to focus on high-value creative

work while delegating routine tasks to automation. Technology

also allows teams of practitioners to leverage and scale their time and abilities.

If an organization is building or maintaining multiple applications, everything it does has to be repeatable, in a reliable

manner, to ensure quality across all applications. It can’t start from scratch with each new release or bug fix for every application. The organization has to reuse assets, code, and prac-

tices to be cost-effective and efficient.

Standardizing automation also makes people more effective

(see “People in DevOps,” earlier in this chapter). Organizations may experience turnover in employees, contractors, or

resource providers; people may move from project to project.

But a common set of tools allows practitioners to work any-

where, and new team members need to learn only one set of

tools — a process that’s efficient, cost-effective, repeatable, and scalable.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 23

10/1/13 2:05 PM

DevOps For Dummies, IBM Limited Edition

24

Infrastructure as Code

Infrastructure as code is a core capability of DevOps that allows organizations to manage the scale and the speed with

which environments need to be provisioned and configured to

enable continuous delivery.

Evolving around the notion of infrastructure as code is the

notion of software-defined environments. Whereas infrastructure as code deals with capturing node definitions and

configurations as code, software-defined environments use

technologies that define entire systems made up of multiple

nodes — not just their configurations, but also their defini-

tions, topologies, roles, relationships, workloads and work-

load policies, and behavior.

Two kinds of automation tools are available for managing

infrastructure as code:

✓

Application- or middleware-centric tools: These tools

usually are capable of managing as code both applica-

tion servers and the applications that run on them. Such

tools are specialized, bundled with libraries of typical

automation tasks for the technologies that they support.

They can’t perform low-level tasks such as configuring

an operating-system (OS) setting, but they can fully auto-

mate server and application-level tasks.

✓

Generic tools: These tools aren’t specialized for any

technology and can be scripted to perform several kinds

of tasks, all the way from configuring an OS on a virtual

or physical node to configuring firewall ports. They

require much more work up front than application- or

middleware-centric tools do, but they can handle a

greater range of tasks.

Delivery pipeline

A delivery pipeline consists of the stages an application goes through from development through to production. Figure 3-1

shows a typical set of stages. These stages may vary from one

organization to another, however, and may also vary from

one application to another based on the organization’s needs, These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 24

10/1/13 2:05 PM

Chapter 3: Adopting DevOps

25

software delivery process, and maturity. The level of automa-

tion may also vary. Some organizations fully automate their

delivery pipelines; others put their software through manual

checks and gates due to regulatory or company requirements.

You don’t have to address all stages at once. Start by focusing on the critical parts of organization — not everything all at once — and then gradually broaden to include all stages.

Figure 3-1: Stages of a typical DevOps delivery pipeline.

A typical delivery pipeline has the stages described in the following sections.

Development environment

An application’s development effort takes place in a development environment, which provides multiple tools that enable the developers to write and test code. Beyond the integrated

development environment (IDE) tools that developers use to

write code, this stage includes tools that enable collaborative development, such as tools for source control management,

work-item management, collaboration, unit testing, and proj-

ect planning. Tools in this stage typically are cross-platform and cross-technology, based on the type of development

being undertaken.

Build stage

The build stage is where the code is compiled to create and unit test the binaries to be deployed. Multiple build tools

may be used in this stage, based on cross-platform and cross-

technology needs. Development organizations typically use

build servers to facilitate the large number of builds required on an ongoing basis to enable continuous integration.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 25

10/1/13 2:05 PM

DevOps For Dummies, IBM Limited Edition

26

Package repository

A package repository (also referred to as an asset repository or artifact repository) is a common storage mechanism for the binaries created during the build stage. These repositories

also need to store the assets associated with the binaries to

facilitate their deployment, such as configuration files,

infrastructure-as-code files, and deployment scripts.

Test environment

A test environment is where the QA, user acceptance, and development/testing teams do the actual testing. Many flavors

of tools are used in this stage, based on QA needs. Here are a few examples:

✓

Test environment management: These tools facilitate

provisioning and configuring the test environments. They

include infrastructure-as-code technologies and (if the

environment is in the cloud) cloud provisioning and man-

agement tools.

✓

Test data management: For any organization that wants

to enable continuous testing, managing test data is an

essential function. The number of tests that can be run

and the frequency with which they’re run are limited by

the amount of data that’s available for testing and the

speed at which that data can be refreshed.

✓

Integration, functional, performance, and security test-

ing tools: Automated tools are available for each of these types of tests. These tools should be integrated with a

common test asset management tool or repository where

all test scenarios, test scripts, and associated results

can be stored and traceability established back to code,

requirements, and defects.

✓

Service virtualization: Modern applications aren’t

simple, monolithic applications. They’re complex

systems that are dependent on other applications,

application servers, databases, and even third-party

applications and data sources. Unfortunately, at test

time, these components may be unavailable or costly.

Service virtualization solutions simulate the behavior —

functionality and performance — of select components

within an application to enable end-to-end testing of

the application as a whole. These tools create stubs

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 26

10/1/13 2:05 PM

Chapter 3: Adopting DevOps

27

(virtual components) of the applications and services

that are required for the tests to run. The behavior and

performance of the application can be tested as it inter-

acts with these stubs. IBM’s Rational Test Virtualization

Server provides such Test Virtualization capabilities.

Stage and production environments

Applications are deployed in the staging and production envi-

ronments. Tools used in these stages include environment

management and provisioning tools. Tools for infrastructure

as code also play a critical role in these stages, due to the large scale at which the environment in these stages exist. With

the advent of virtualization and cloud technologies, stage and production environments can today be made up of hundreds

or even thousands of servers. Monitoring tools allow organiza-

tions to monitor the deployed applications in production.

Deployment automation and

release management

Managing the automation of application deployment from one

stage to the next requires specialized tools, some of which I

discuss in the following sections.

Deployment automation

Deployment automation tools are the core tools in the DevOps

space. Such tools perform orchestrated deployments and

track which version is deployed on which node at any stage of

the build and delivery pipeline. They can also manage the con-

figurations of the environments of all the stages to which the application components must be deployed.

Deployment automation tools manage the software compo-

nents that get deployed; the middleware components and

middleware configurations that need to be updated; the data-

base components that need to be changed; and the configura-

tion changes to the environments to which these components

are to be deployed. These tools also capture and automate

the processes to carry out these deployments and configura-

tion changes. IBM UrbanCode Deploy is such a deployment

automation tool.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 27

10/1/13 2:05 PM

DevOps For Dummies, IBM Limited Edition

28

Release management

Orchestrating the release plans and deployments associated

with each release requires coordination across the business,

development, QA, and operations teams. Release manage-

ment tools allow organizations to plan and execute releases,

provide a single collaboration portal for all stakeholders in

a release, and provide traceability for a release and its com-

ponents across all stages of the build and delivery pipeline.

IBM UrbanCode Release provides such release management

capabilities.

Measuring technology adoption

Measuring return on investment and reliability of tasks — some-tools and technology is fairly thing that isn’t always possible with straightforward. Typically, you can manual tools. Finally, using an inte-measure the efficiencies created by grated set of automated tools facili-automation. Also, automated tools tates collaboration, traceability, and allow you to enhance the scalability improved quality.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

07_9781118733783-ch03.indd 28

10/1/13 2:05 PM

Chapter 4

Solving New Problems

with DevOps

In This Chapter

▶ Coping with the cloud

▶ Enabling mobile applications

▶ Dealing with ALM processes

▶ Managing multiple-tier applications

▶ Working with supply chains

▶ Navigating the Internet of Things

D evOps originated in so-called born on the web companies (companies that originated on the Internet) such as Etsy,

Flickr, and Netflix. These companies, while solving complex

technology challenges at a very large scale, had fairly simple architectures — unlike large enterprises that grew around

legacy systems and/or through acquisitions and mergers, with

complex multi-technology systems that had to work together.

These challenges are further aggravated by the demands

being put on modern enterprises by new technologies like

cloud and mobile and application delivery models such as

software supply chains.

This chapter explores some of these challenges that enterprises face and that DevOps can help solve.

Cloud Technology

One of the most critical changes that has affected DevOps

(and actually helped it mature at the same time) is Cloud.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

30 DevOps For Dummies, IBM Limited Edition

The pervasiveness of cloud technology, private, public, and

hybrid, has enabled organizations to provision environments

on demand. In traditional organizations that use physical servers, requesting a new server is a complex, time-consuming

process. It may take days or even weeks to requisition a new

physical server, install and set up the operating system (OS), and configure all the software required to deploy the application. Virtualization and Cloud solve that problem to a large

extent. This has led to tremendous growth in the scale by

which the environments to which applications are deployed

are used. This scale has necessitated automation on software

deployment tasks, which DevOps addresses.

At the same time the advent of cloud actually facilitates con-

tinuous deployment and provides easier access to production-

like environments during the development and testing stages

of the delivery pipeline. It has also led to developer self-service in enterprises typically known for siloed separation of responsibilities. With cloud technologies, a developer can not only

invoke an automated build, but also request the provisioning

and configuration of a productionlike environment in the cloud and then deploy the application being built to it — all without any direct involvement by the operations team. Both of these

capabilities provided by cloud facilitate DevOps adoption.

Mobile Applications

In an enterprise, mobile apps are typically not stand alone apps.

They have very little business logic on the mobile device itself and serve more as front-ends to a multiple enterprise applications already in use by the enterprise. These back-end enter-

prise applications may range from transaction processing

systems to employee portals to customer acquisition systems.

Mobile development and delivery is complex and requires a

set of dependent services to be delivered in a coordinated

fashion in a reliable and efficient manner.

For enterprise mobile apps, release cycles and new feature

releases need to be coordinated with those of the enterprise

applications and services that the mobile apps interact with.

Therefore, DevOps adoption should include mobile-app teams

as first-class citizens and participants along with the rest of the enterprise software development teams.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Chapter 4: Solving New Problems with DevOps 31

DevOps and app stores

One unique aspect of mobile apps step to the deployment process.

is the need for deployment to app Developers can no longer deploy stores. Most mobile apps can’t be updates to an app on demand. Even deployed directly to mobile devices; for critical bug fixes, new app versions they have to go through a vendor- have to go through an app store’s managed app store. Apple introduced submission and review processes.

this distribution format with its App Continuous delivery becomes Store (and locked its devices to submitting and waiting. Continuous prevent direct installation of apps by deployment to development and testing app developers or vendors).

remains available, however, with the

Device manufacturers such as test environment being simulators for Research In Motion and Microsoft, the devices on which the application which once allowed direct app will be deployed or banks of physical installation, now follow the Apple model. devices.

This situation adds an asynchronous

No specific DevOps concepts or principles apply solely to

mobile apps. Mobile apps, however, add to the need for

DevOps due to their inherent short development life cycles

and rapid change.

ALM Processes

Application lifecycle management (ALM) is a set of processes employed to manage the life of an application as it evolves

from an idea (a business need) to an application that’s deployed and eventually under maintenance. Hence, looking at DevOps

as an end-to-end business capability makes ALM part of the

DevOps process.

The five imperatives of ALM (jazz.net/library/article/637)

apply to a DevOps-centric view of application delivery. The

five imperatives are

✓

Real-time planning

✓

Life-cycle traceability

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

32 DevOps For Dummies, IBM Limited Edition

✓

In-context collaboration

✓

Development intelligence

✓

Continuous process improvement

Describing these imperatives in detail is beyond the scope of

this book. Real-time planning maps to the plan-and-measure

adoption path. The life cycle traceability and in-context col-

laboration imperatives map to develop-and-test, and develop-

ment intelligence and continuous process improvement map

to monitor and optimize. Check out Chapter 2 for more on

these paths.

Multiple-Tier Applications

In a typical large IT shop, it’s not uncommon to find multipletier applications that span many platforms, each with its own

unique development process, tools, and skill requirements.

These multi-tier systems often integrate applications on the

web, desktop, and mobile applications on the front-end and

back-end systems such as packaged applications, data ware-

house systems, applications running on mainframes, and

midrange systems. Managing and coordinating the releases of

the parts of multiple-tier systems, many of which may be on

different platforms, can be overwhelming even for the most

disciplined IT organization.

A sensible approach is to follow automated, consistent build,

configure, and deployment processes through all stages of

development. This approach ensures that you’re building

all the parts you need — and only the parts you need. It also

ensures that the application remains whole as changes come

in and the project moves through the cycle of testing, QA, and production. IBM UrbanCode Deploy has an application model

that helps automate the complex deployment of multiple-tier

applications.

Maintaining separate tools for different teams based on plat-

form is a reality in today’s multi-platform, multi-vendor world.

This is where open platforms such as IBM Jazz, can integrate

disparate tools to provide a unified solution. Consistent

deployment practices can help ensure that teams are using

reliable, repeatable deployment across platforms to provide

true business value.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Chapter 4: Solving New Problems with DevOps 33

Supply Chains

With the increasing use of outsourcing and strategic partner-

ships to supply skills and capabilities to an enterprise, software supply chains are becoming the norm. A supply chain

is a system of organizations, people, technology, activities,

information, and resources involved in moving a product or

service from supplier to customer. The various suppliers in

the chain may be internal or external to the enterprise.

In an organization that has adopted a supply-chain model

for delivering software, adopting DevOps can be a challenge,

because the relationships among suppliers are managed

more by contracts and service level agreements than by col-

laboration and communication. Such an organization can

still adopt DevOps, however. The core project teams retain

ownership of the planning and measurement capabilities, with

other capabilities being shared among the other suppliers. In

the delivery pipeline, different suppliers may own different

stages of the pipeline. Using common tool sets and a common

asset repository is therfore essential. A work-item manage-

ment tool, for example, provides reporting on all items being

worked on by all suppliers, as well as transfer of ownership

of work items across suppliers. Using a common asset reposi-

tory provides a mechanism for passing assets through the

pipeline, enabling continuous delivery.

The Internet of Things

The next big step for DevOps is its evolution into the systems or embedded-devices space. When the Internet started, most

of the data shared on it was human-generated. Today, innu-

merable Internet-connected devices (such as sensors and

actuators) generate much more data than humans do. This

network of inter-connected devices on the Internet is com-

monly referred to as the Internet of Things.

In this space, DevOps is potentially even more essential, due

to the co-dependence of the hardware and the embedded

software that runs on it. DevOps principles ensure that the

embedded software delivered to the devices is high-quality

software with the right engineering specifications.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

34 DevOps For Dummies, IBM Limited Edition

Operations, in this case, is replaced by hardware or systems

engineers who design and build custom hardware for the

devices. Collaboration between the development and testing

teams and the systems engineers is crucial to ensure that

hardware and software are developed and delivered in a coor-

dinated manner despite hardware and software development

needing to follow different delivery cycles. The development

and testing needs for continuous delivery and testing remain

the same. Simulators are used to test software and hardware

during development.

Anti-patterns

In the real world, there are always that whereas development teams limitations to adoption of DevOps may have adopted agile practices, principles. Some of these limitations the teams around them may still are functions of the industries and have manual, waterfall-style pro-environments in which a business cesses that don’t allow for continu-exists, such as regulatory compli- ous delivery. In several enterprises, ance, complex hardware systems, this situation results from the corpo-or immature software delivery capa- rate culture. A company that adopts bilities. In such cases, DevOps needs DevOps must embed manual pro-to be adopted in light of anti-patterns cesses in broader DevOps practices.

(ineffective or counterproductive

patterns) that may not be accept- NoOps

able for an organization, based on its In a NoOps organization, Operations business needs.

is eliminated as a separate depart-

Water-SCRUM-fall

ment, and its responsibilities are

merged into those of Development.

Forrester (www.forrester.com), Netflix, an Internet television proa global research and advisory vider, is a proponent of this method.

company, coined the term Water- NoOps may work well for some SCRUM-fall to describe the current organizations, but some waiting is state of adoption of agile software involved to see if this organizational development methodologies. From model will have wider practical a DevOps perspective, this means appeal.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Chapter 5

Ten DevOps Myths

In This Chapter

▶ Understanding what DevOps is for

▶ Knowing what DevOps isn’t for

T he DevOps movement is young and still emerging, espe-

cially among enterprises. Like any new movement or

trend, it has attracted myths and fallacies. Some of these

myths may have originated in companies or projects that

tried and failed to adopt DevOps. What’s true in one situa-

tion, however, may not necessarily be true in others. Here are some common myths about DevOps — and the facts.

DevOps Is Only for “Born

on the Web” Shops

What is generally referred to as DevOps originated in “born

on the web” companies (companies that originated on the

Internet) such as Etsy, Netflix, and Flickr. Large enterprises have been using DevOps-aligned principles and practices to

deliver software for decades, however. Furthermore, current

DevOps principles, as described in this book, have a level of

maturity that makes them applicable to large enterprises that

have multiple-platform technologies and distributed teams.

DevOps Is Operations

Learning How to Code

Operations teams have always written scripts to manage

environments and repetitive tasks, but with the evolution

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

36 DevOps For Dummies, IBM Limited Edition

of infrastructure as code, operations teams saw a need to

manage these large amounts of code with software engineer-

ing practices such as versioning code, check-in, check-out,

branching, and merging. Today, a new version of an environ-

ment is created by an operations team member by creating

a new version of the code that defines it. This doesn’t mean,

however, that operations teams need to learn how to code in

Java or C#. Most infrastructure-as-code technologies use lan-

guages like Ruby, which are relatively easy to pick up, espe-

cially for people who have scripting experience.

DevOps Is Just for Development

and Operations

Although the name suggests a development-plus-operations

origin, DevOps is for the whole team. All stakeholders in the delivery of software — lines of business, practitioners, executives, partners, suppliers, and so on — also have a stake in DevOps.

DevOps Isn’t for ITIL Shops

Some people fear that DevOps capabilities such as continuous

delivery are incompatible with the checks and processes pre-

scribed by the Information Technology Infrastructure Library

(ITIL), a set of documented best practices for IT service man-

agement. In reality, ITIL’s life cycle model is compatible with DevOps. Most of the principles defined by ITIL align very well with DevOps principles. ITIL has, however, received a bad repu-tation in some organizations due to being implemented predom-

inately with slow, waterfall processes that didn’t allow for rapid changes and improvement. Aligning such practices between

development and operations is the essence of DevOps.

DevOps Isn’t for Regulated

Industries

Regulated industries have an overarching need for checks

and balances and for approvals from stakeholders who ensure

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Chapter 5: Ten DevOps Myths 37

compliance and auditability. Adopting DevOps actually

improves compliance, if it’s done properly. Automating pro-

cess flows and using tools that have built-in capability to capture audit trails can help.

Organizations in regulated industries will always have manual

checkpoints or gates, but these elements aren’t incompatible

with DevOps.

DevOps Isn’t for Outsourced

Development

Outsourced teams should be viewed as suppliers or capability

providers in the DevOps delivery pipeline. Organizations should ensure, however, that the practices and processes of the supplier teams are compatible with those of their internal project teams.

Using common release planning, work-item management, and

asset repository tools significantly improves communication

and collaboration between lines of business and supplier and

project teams, enabling DevOps practices. Using application

release management tools can greatly improve an organiza-

tion’s ability to define and coordinate the entire release process across all participants.

No Cloud Means No DevOps

When you think of DevOps, you often think of Cloud because

of its ability to dynamically provision infrastructure resources for developers and testers to rapidly obtain test environments without waiting days/weeks for a manual request to be fulfilled.

However, Cloud isn’t necessary to adopt DevOps practices as

long as an organization has efficient processes for obtaining

resources for deploying and testing application changes.

Virtualization itself is optional. Continuous delivery to physical servers is possible if the servers can be configured and deployed to at the necessary speed.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

38 DevOps For Dummies, IBM Limited Edition

DevOps Isn’t for Large,

Complex Systems

Complex systems require the discipline and collaboration that

DevOps provides. Such systems typically have multiple soft-

ware and/or hardware components, each of which has its own

delivery cycles and timelines. DevOps facilitates coordination of these delivery cycles and system-level release planning.

DevOps Is Only about

Communication

Some members of the DevOps community have coined humor-

ous terms such as ChatOps (teams carry out all communications through communication tools like Internet Relay Chat) and

HugOps (DevOps focuses only on collaboration and communication). These terms stem from the misconception that

communication and collaboration solve all problems.

DevOps depends on communication, but better communica-

tion coupled with wasteful processes doesn’t lead to better

deployments.

DevOps Means Continuous

Change Deployment

This misconception comes from organizations that deploy

only web applications. Some of these companies proudly state

on their websites that they deploy to production daily. Daily

deployment, however, is not only impractical in large orga-

nizations that deploy complex applications, but may also be

impossible due to regulatory or company restrictions. DevOps

isn’t just about deployment, and it’s certainly not just about deploying continuously to production. Adopting DevOps

allows organizations to release to production when they want

to and not based on a particular date marked on a calendar.

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Notes

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Notes

These materials are the copyright of John Wiley & Sons, Inc. and any dissemination, distribution, or unauthorized use is strictly prohibited.

Document Outline

Table of Contents

Introduction

About This Book

Icons Used in This Book

Beyond the Book

Chapter 1: What Is DevOps?

Understanding the Business Need for DevOps

Recognizing the Business Value of DevOps

Seeing How DevOps Works

Chapter 2: Looking at DevOps Capabilities

Paths to DevOps Adoption

Plan and Measure

Develop and Test

Release and Deploy

Monitor and Optimize

Chapter 3: Adopting DevOps

People in DevOps

Process in DevOps

Technology in DevOps

Chapter 4: Solving New Problems with DevOps

Cloud Technology

Mobile Applications

ALM Processes

Multiple-Tier Applications

Supply Chains

The Internet of Things

Chapter 5: Ten DevOps Myths

DevOps Is Only for “Born on the Web” Shops

DevOps Is Operations Learning How to Code

DevOps Is Just for Development and Operations

DevOps Isn’t for ITIL Shops

DevOps Isn’t for Regulated Industries

DevOps Isn’t for Outsourced Development

No Cloud Means No DevOps

DevOps Isn’t for Large, Complex Systems

DevOps Is Only about Communication

DevOps Means Continuous Change Deployment