Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Continuous Delivery and DevOps ??? A Quickstart Guide

You're reading from   Continuous Delivery and DevOps ??? A Quickstart Guide Start your journey to successful adoption of CD and DevOps

Arrow left icon
Product type Paperback
Published in Oct 2018
Publisher
ISBN-13 9781788995474
Length 270 pages
Edition 3rd Edition
Arrow right icon
Author (1):
Arrow left icon
Paul Swartout Paul Swartout
Author Profile Icon Paul Swartout
Paul Swartout
Arrow right icon
View More author details
Toc

Table of Contents (13) Chapters Close

Preface The Evolution of Software Delivery Understanding Your Current Pain Points FREE CHAPTER Culture and Behaviors are the Cornerstones to Success Planning for Success Approaches, Tools, and Techniques Avoiding Hurdles Vital Measurements You Are Not Finished Just Yet Expanding Your Opportunity Horizon CD and DevOps Beyond Traditional Software Delivery Some Useful Information Other Books You May Enjoy

ACME systems – evolution phase 1.0

ACME started out with a couple of things in common with the many thousands of small software businesses scattered around the globe: it had some good ideas and a saw gap in the market that it could exploit to make its fortune. It had a relatively small amount of cash so it needed to move fast to be able to survive and it needed to quickly entice, enlist, and retain customers at all costs. It did this by delivering what the customer wants just before the customer needs it. Deliver too soon, and it may have wasted money on building solutions that the customer decides they no longer want. Deliver too late, and someone else may well have taken the company's market shareand the revenueaway. The keyword here is deliver.

As a small start-up, in the early days, the going is slow and the work is hard: lots of R&D, frantically-built pre-sales prototypes, quick and dirty deliveries, and unrealistic deadlines. After many long days, nights, weeks, months, and weekends, things actually start to come together. The customer base starts to grow and the ordersand revenuestart rolling in. After a while, the number of employees are in double figures and the founders have become directors.

So, 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 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 being to get software into the production environment a quickly as possible, thus delighting customers
  • Speed of delivery is crucial
  • If things break, everyone swarms around to help fix the problem—even out of hours
  • The software evolves quickly and features are added in incremental chunks
  • The ways of working are normally very agile
  • Communication and collaboration across the business is efficient and, for the most part, effective

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 business typically has to operate to stay alive:

  • Corners will be cut to hit deadlines, which compromises software design, quality, and elegance
  • Application security best practices are given short shrift or even ignored
  • Engineering best practices are compromised to hit deadlines
  • The concept of technical debt is pretty much ignored
  • Testing won't be in the forefront of the developer's mind (even if it were, there may not be enough time to work in a test-first way)
  • Source-and version-control systems are not used religiously
  • With unrestricted access to the production environment, ad hoc and uncontrolled tweaks and changes can be made to the infrastructure and environmental setup
  • 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 become production code without the opportunity for refactoring
  • Documentation is scant or non-existent—any that does exist is probably out of date
  • The work-life balance for an engineer working within a small software house is not sustainable and burn out does happen

Let's 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
This very simple process is something that many small software businesses and start-ups will recognize. From a CD and DevOps perspective, there are next to no barriers between those building and delivering the software and those supporting it (we'll cover this later in this chapter).

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.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at R$50/month. Cancel anytime