Continuous Delivery and DevOps FAQs

Exclusive offer: get 50% off this eBook here
Continuous Delivery and DevOps: A Quickstart guide

Continuous Delivery and DevOps: A Quickstart guide — Save 50%

Continuous delivery and DevOps explained with this book and ebook.

$14.99    $7.50
by Paul Swartout | January 2013 | Architecture & Analysis

For a while now, there has been a buzz around the IT industry about something called continuous delivery and DevOps—strictly speaking that should be "some things" as continuous delivery and DevOps are actually two separate things.

You may have heard about them but may not fully understand what they are, why they are valuable and, should you wish to implement them, where to start from.

In this article by Paul Swartout, author of Continuous Delivery and DevOps: A Quickstart guide, we have tried to capture some common questions and provide some answers—an FAQ of sorts.

(For more resources related to this topic, see here.)

What is continuous delivery and DevOps?

Let's start by looking at each separately:

Continuous delivery, more commonly referred to CD, is an agile way of working whereby quality products—normally software assets—can be developed, built, tested, and shipped in quick succession.

CD is a refinement on traditional agile techniques such as scrum and lean. The main refinements being the ability to decrease the time between deliveries and the ability to do this many many times—continuously in fact. Agile delivery techniques encourage you to time-box the activities/steps needed to deliver software: definition, analysis, development, testing, and sign-off but this doesn't necessarily mean that you deliver as frequently as you would like. Most agile techniques encourage you to have "potentially shippable code" at the end of your iteration/sprint. CD encourages you to ship the finished code, as frequently as possible.

To achieve this ability one must look at the process of writing software in a slightly different way. Instead of focusing on delivery of a feature or a project in one go, you need to look at how you can deliver it in smaller, incremental chunks. This can be easier said than done.

DevOps is another way of working whereby developers and system operators work in harmony with little or no organizational barriers between them towards a common goal. This may not sound too radical however when you consider how mainstream organizations function—especially those within government, corporate, or financial sectors—and take into account the many barriers that are in place between the development and the operational teams, this can be quite a radical shift.

A simple way to imagine this is to consider how a small start-up software house operates. They have a limited amount of resource and a minimum level of bureaucracy. Developing, shipping, and supporting software is normally seamless—sometimes being done be the same people. Now look at a corporate business with R&D and operations teams. These two parts of the organization are normally separated by rules, regulations, and red tape—in some cases they will also be separated by other part of the organization (QA teams, transition teams, and so on).

DevOps encourages one to break through these barriers and create an environment whereby those creating the software and those supporting the software work together in close synergy and the lines between them become blurred. DevOps is more to do with hearts and minds than anything else so can be quite tough to implement when long established bad habits are in place.

Do I have to use both?

You don't necessarily need to have implemented both CD and DevOps to speed up the delivery of quality software but it is true to say that both complement each other very well. If you want to continuously deliver quality software you need to have a pretty slick and streamlined process for getting the software into the production environment. This will need very close working relationships between the development teams and the operations teams. The more they work as one unit, the more seamless the process.

CD will give you the tools and best of breed practices to deliver quality software quickly. DevOps will help you establish the behaviors, culture, and ways of working to fully utilize CD.

If you have the opportunity to implement both, it would be foolish not to at least try.

Can CD and DevOps bring quantifiable business benefit?

As with any business the idea is that you make more money than you spend. The quicker you can ship and sell your service/software/widget, the quicker you generate income.

If you use this same model and apply it to a typical software project you may well notice that you are investing a vast amount of effort and cash simply getting your software complete and ready to ship—this is all cost. That's not the only thing that costs, releasing the software into the production environment are not free either. It can sometimes be more costly—especially if you need large QA teams, and release teams, and change management teams, and project coordination teams, and change control boards staffed by senior managers, and bug fixing teams and ... I think you got the idea.

In simple terms being able to develop, test, and ship small changes frequently (say many times per day or week) will drastically reduce the cost of delivery and allow the business to start earning money sooner. Implementing CD and/or DevOps will help you in realizing this goal.

Other business benefits include; reduction in risk of release failures, reduction in delivering redundant changes (those that are no longer needed but released anyway), increased productivity (people spend less time releasing product and more time creating products), increases competitiveness, and so on.

How does it fit with other product delivery methodologies?

CD and DevOps should be seen as a set of tools that can be utilized to best fit your business needs. This is nothing new, any mature agile methodology should be used in this way. As such you should be able to "bolt" elements of CD and DevOps into your existing process.

For example, if you currently use scrum as your product delivery methodology and have implemented CD, you could tweak your definition of done (DoD) to be "it is live" and incorporate checks against automated testing, continuous integration, and automated deployment within your acceptance criteria for each story. This therefore encourages the scrum team to work in such a way as to want to deliver their product to the live platform rather than have it sat potentially shippable waiting for someone to pick it up and release it—eventually.

There may be some complexity when it comes to more traditional waterfall product delivery methodologies such as PRINCE2 or similar however there is always room for improvement—for example, the requirements gathering stage could include developers and operational team members to flesh out and understand any issues around releasing and supporting the solution when it goes live. It may not seem much but these sort of behaviors encourage closer working and collaboration.

All in all CD and DevOps should be seen as complementary to your ways of working rather than a direct replacement—at least to begin with.

Is it too radical for most businesses?

For some organizations being able to fully implement the CD and DevOps utopia may be very complex and complicated, especially where rules, regulations, and corporate governance are strongly embedded. That isn't to say that it can't be done. Even the most cumbersome and sloth like institutions can and do benefit from utilizing CD and DevOps—the UK government for example.

It does need more time and effort to prove the value of implementing all/some elements of CD and DevOps and those that are proposing such a shift really need to do their homework as there may well be high degrees of resistance to overcome. However, as more and more corporate, government organizations, and other large business embrace CD and DevOps, the body of proof to convince the doubters becomes easier to find.

Look at your business and examine the pain points in the process for delivering your goods/services/software. If you can find a specific problem (or problems) which can be solved by implementing CD or DevOps then you will have a much clearer and more convincing business case.

Where do I start?

As with any change, you should start small and build up—incrementally. If you see an opportunity, say a small project or some organizational change within your IT dept, you should look into introducing elements of CD and DevOps. For some this may be in the form of kicking off a project to examine/build tooling to allow for automated testing, continuous integration, or automated deployments. For some it may be to break down some of the barriers between development and operational teams during the development of a specific project/product.

You may be able to introduce CD and/or DevOps in one big bang but just consider how things go when you try and do that with a large software release—you don't want CD and DevOps to fail so maybe big bang is not the best way.

All in all it depends on your needs, the maturity of your organization, and what problems you need CD and DevOps to solve.

If you are convinced CD and DevOps will bring value and solve specific problems then the most important thing to do is start looking at ways to convince others.

Do I just need to implement some tooling to get the benefits?

This is a misconception which is normally held by those management types who have lost their connection to reality. They may have read something about CD and DevOps in some IT management periodical and decided that you just need to implement Jenkins and some automated tests.

CD and DevOps do utilize tools but only where they bring value or solve a specific problem. Tooling alone will not remove ingrained business issues. Being able to build and test software quickly is good but without open, honest, and collaborative ways of working to ensure the code can be shipped into production just as quickly you will end up with another problem—a backlog of software which needs to be released. Sometimes tweaking an existing process through face to face discussion is all the tooling that is needed—for example changes to the change process to allow for manual release of software as soon as it's ready.

Where can I find more information?

There are many forms of information available in relation to CD and DevOps one of which is a small book entitled "Continuous Delivery and DevOps: A Quickstart guide" which is written by your truly and available here (http://www.packtpub.com/devops-quickstart-guide/book )

Summary

In this article we saw some of the most frequently asked questions on Continuous Delivery and DevOps.

Resources for Article :


Further resources on this subject:


Continuous Delivery and DevOps: A Quickstart guide Continuous delivery and DevOps explained with this book and ebook.
Published: November 2012
eBook Price: $14.99
Book Price: $24.99
See more
Select your format and quantity:

About the Author :


Paul Swartout

Paul Swartout has spent over 20 years working in IT. Starting out as a Junior Developer within a small software house, Paul has filled a number of roles over the years including Software Engineer, System Administrator, Project Manager, Program Manager, Operations Manager, and Software Development Manager. He has worked across a number of different industries and sectors—from supply chain, through manufacturing, education, and retail to entertainment—and within organizations of various sizes from start-ups to multi-national corporates. Paul is passionate about software and how it is delivered. Since first encountering "agile" almost a decade ago he has been committed to the adoption and implementation of agile techniques and approaches to improve efficiency and output for software development teams. Until very recently Paul headed up the team responsible for delivering continuous delivery solutions into the Nokia Entertainment business. Paul and his team spent the best part of a year changing the default ways of working and driving the adoption of CD and DevOps as the de facto mode of delivery for Nokia Entertainment products. Paul lives in a seaside town in the southwest of the UK with his wife, daughters, and two small yapping things. Paul is a software development manager at Nokia and is based within the Nokia entertainment team in Bristol in the UK. The entertainment team is responsible for designing, building, and running the entertainment services and solutions for Nokia customers around the globe. These products include Nokia Music, Nokia Reading, and Nokia TV.

You can follow Paul Swartout on twitter at @pswartout and he also blog at http://www.swartout.co.uk/

Books From Packt


ASP.NET 3.5 Application Architecture and Design
ASP.NET 3.5 Application Architecture and Design

Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations
Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations

Mastering OpenLDAP: Configuring, Securing and Integrating Directory Services
Mastering OpenLDAP: Configuring, Securing and Integrating Directory Services

Enterprise Security: A Data-Centric Approach to Securing the Enterprise
Enterprise Security: A Data-Centric Approach to Securing the Enterprise

User Training for Busy Programmers
User Training for Busy Programmers

SAP Business ONE Implementation
SAP Business ONE Implementation

Backbase 4 RIA Development
Backbase 4 RIA Development

Software Testing using Visual Studio 2010
Software Testing using Visual Studio 2010


Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software