Book Image

Continuous Delivery and DevOps: A Quickstart guide

By : Paul Swartout
Book Image

Continuous Delivery and DevOps: A Quickstart guide

By: Paul Swartout

Overview of this book

<p>For a while now, there has been a buzz around the IT industry regarding continuous delivery and DevOps. This book will provide you with some background information into these two new kids on the block and how they can help you to optimize, streamline and improve the way you work and ultimately how you ship quality software. <br /><br />"Continuous Delivery and DevOps: A Quickstart guide" will provide you with a clear and concise insight into what continuous delivery and DevOps are all about, how to go about preparing for and implementing them and what quantifiable business value they bring. Included within are some tricks and trips based upon real world experiences which may help you reduce the time and effort needed if you were to go it alone.<br /><br />In this book, you will be taken through a journey of discovery starting with real world successes, how you should prepare, plan for and implement CD and DevOps and what the pitfalls are along the way<br /><br />We will start looking at the evolution of a typical software house from fledgling start-up through the growing pains that comes with global success to a best of both worlds. We’ll delve into the many aspects of what they did to complete this evolution covering topics such as how they realized there was a problem to solve, how they set about preparing for and implementing continuous delivery and DevOps and what tools, techniques and approaches they used along the way – some technical and some not so. If you work within an organization that delivers software, you will be able to plot where you are on the evolutionary scale, understand where you need to do to be more effective, cherry pick the tools, techniques and approaches that work for you and realize the best of both worlds.<br /><br />"Continuous Delivery and DevOps: A Quickstart guide" will provide you with the background and information you need to realize the benefits within your own business</p>
Table of Contents (15 chapters)
Continuous Delivery and DevOps: A Quickstart Guide
Credits
About the Author
Acknowledgement
About the Reviewers
www.PacktPub.com
Preface
Index

ACME systems Version 1.0


Some of you have most probably worked for (or currently work for) a small software business. There are many such businesses scattered around the globe and they all have one thing in common: they need to move fast to survive and they need to entice and retain customers at all costs. They do this by delivering what the customer wants just before the customer needs it. Deliver too soon and you may have wasted money on building solutions that the customer decides they no longer need, as their priorities or simply their minds have changed. Deliver too late and someone else may well have taken your customer—and more importantly your revenue—away from you. The important keyword here is deliver.

As previously mentioned, ACME systems started out in humble beginnings; the founders had the big vision and could see a gap in the market for a web-based solution. They had entrepreneurial spirit and managed to obtain backing from a few parties who injected the life blood of all small businesses—cash.

They then went about sourcing some local, keen, and talented engineers and set about building the web-based solution that bridged the gap, which they had seen before anyone else could.

At first, it was slow going and hard work; lots of pre-sales prototypes needed to be built in a hurry—most of which never saw the light of day—some went straight into production. After many long days, long nights, long weeks, long weekends, and long months, things started to come together. The customer base started to grow and the orders started rolling in; so did the revenue. Soon the number of employees were in double figures and the founders had become directors.

This is all well and good but what has this got to do with CD or DevOps? Well everything really. The culture, default behaviors, and engineering practices of a small software house are what would be classed as pretty good in terms of CD and DevOps. For example:

  • There are next to no barriers between developers and the Operations teams—in fact, they are generally one and the same

  • Developers normally have full access to the production environment and can closely monitor their software

  • All areas of the business are focused on the same thing, that is, getting software into the production environment as quickly as possible and delighting customers

  • Speed of delivery is of the essence

  • When things break, everyone swarms around to help fix the problem

  • The software evolves quickly and features are added in incremental chunks

  • The ways of working are normally very agile

There is a reason for stating that the culture, default behaviors, and engineering practices of a small software house would be classed as pretty good rather than ideal. This is because there are many flaws in the way a small software house has to operate to stay alive:

  • Corners will be cut to hit deadlines, which will compromise software design and elegance

  • Engineering best practices will be compromised to hit deadlines

  • Testing will not be in the forefront of the developer's mind and even if it were, there may not be enough time to work in a test-driven development way

  • Source and version control is not used religiously

  • With unrestricted access to the production environment, tweaks and changes can be made to the infrastructure

  • Software releasing will be mainly manual and most of the time an afterthought of the overall system design

  • At times a rough and ready prototype may well become production code without the opportunity for refactoring

To emphasize this, let's have a look at a selection of typical conversations between the Development and Operations teams and the management team of ACME systems.

Developer/Ops

Management

We would like to invest some time in implementing a source control system.

Is it free? We don't have time.

We would like to invest time in developing a fully automated test suite.

Is it free? We don't have time.

We would like to invest time in implementing automated server provisioning.

Is it free? We don't have time.

The production environment has crashed.

You're not going home until it's fixed. I'll get the pizza!

This prototype is rough and ready and needs to be rewritten before we hand it over to our customers.

Don't worry, you'll get time to rewrite it.

The prototype we are now using in production keeps crashing.

You're not going home until it's fixed. I'll get the pizza!

We want to work in a test-driven development mode.

That will only slow things down and we don't have the time.

I can manually hack the production server to improve performance and stability to overcome the issues we're having.

I fully trust your judgment on this, just get it done quickly.

The manual hack I did last week has caused the disks to fill up and the production server has crashed.

You're not going home until it's fixed. I'll get the pizza!

We'll now have a look at the software delivery process for ACME systems Version 1.0, which, to be honest, shouldn't take too long.

Software delivery process flow Version 1.0

The following diagram gives an overview of the simple process used by ACME systems to deliver software. It's simple, elegant (in a rough and ready kind of way), and easy to communicate and understand.

Overview of ACME Version 1.0 software delivery process

Let's move forward a few years and see how ACME systems is doing and gain some insight into the benefits and pitfalls of being the leader of the field.