5 DevOps Best Practices

In this “DevOps explained” episode Dave Farley describes five DevOps best practices that help you to steer towards a successful outcome. What is DevOps and how can we make it happen? What are the DevOps principles that predict success? What do successful DevOps engineers and teams that practice DevOps focus on to gain the benefits of being able to create Better Software Faster?

In its broadest interpretation, DevOps is - everything that it takes to be able to continuously and sustainably deliver useful changes to our users. We call that ‘Continuous Delivery’; some people call it ‘DevOps’. Either way, these Continuous Delivery best practices are significant predictors of successful software development, as found by the State of DevOps Report.

---------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------

If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses:

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 The original award-winning “Continuous Delivery" book by Dave Farley and Jez Humble
--------------------------------------------------------------------------------------



----------------------------------------------------------------------------------------------------------------------
Useful Books on this topic:
(Please note, if you buy a book from these links I get a small fee, without increasing the cost to you)

"Accelerate, The science of Lean Software and DevOps", by Nicole Fosgren, Jez Humble & Gene Kim

"The Phoenix Project", by Gene Kim

"The DevOps Handbook", by Gene Kim, Jez Humble, Patrick Debois & John Willis

[LiboYin]

Great summary as usual, Dave. As a software engineer at a bank, I found it challenging to convince tech companies that I am familiar with best practices such as these. What would you do to demonstrate these knowledge if you were in a similar situation?

[randomclimber]

I work as a data scientist and I've had the luck to work alongside a strong proponent of devOps. This changed my whole approach to building systems based on ML. Your channel materializes clearly the practices that solve many frustrations I've had on companies still living in 1980's. Thank you very much for this!

[davidpccode]

Amazing!! Like always.
Dave one question. In a monorepo, I'm working on a PR.. if a edit one project but for some reason I need to deploy another services as well, how to chose the docker image for thise or do i have to build thise images ?

[Oswee]

As a person with HUGE experience... you could make a series about the history of software development and it's "general" patterns.
How we came where we are now?
Like... how testing looked like 20-15 years ago, what problems there was at that time, what was top notch solutions at some key epoch's of the testing. What is the current "major" "edge" approaches in the industry at small/min/giga scales. And where are we heading in your opinion.
Same pattern could be applied to any other topic you like. And i am not talking about deep-dive as it is impossible to cover. But... some key aspects, which comes in your mind.
While learning software engineering i found really, really valuable to know the history. Why we do the things in the way we do it now.

[DavidAtTokyo]

Indeed, Domain-Driven Design is a fantastic book. For me, the alignment of microservices to Bounded Contexts is a prerequisite for that microservice being "independently" manageable.

The translation of concepts between microservices (specifically those belonging to different Bounded Contexts) is no small task, and either requires close coordination with those familiar with the microservice being integrated, or for the other microservices' API to have outstanding documentation. An organization pursuing microservices for the right reasons would presumably be happy to ensure such communication were adequately invested in.

One other potential benefit with microservices, which Eric Evans suggested 5 or so years back, is protecting model integrity with hard boundaries. With a monolithic system, there is little to stop a developer adding a new feature from reaching into another module's database and creating some new point of coupling between the modules. While in theory a monolithic system can be modular, as Evans noted, decades of experience suggests that that isn't how they tend to work out over time.

Here the key thing for me is that these software components (not necessarily "microservices" as defined in this video) have physical boundaries to help keep the module's conceptual integrity protected. At a minimum, protecting the module's database access credentials as if they were akin to ssh private keys would perhaps go a long way to achieving such aims.

[PerKarlsson]

Great stuff! Thanks, Dave. But one thing I'm wondering about is how an optimized deployment pipeline for a complete (monolithic) system could be equally good as multiple pipelines for a decomposed system. (9:15-11:27). Would be great if you could elaborate on this.

[katefarley]

Are these your top 5 recommended practices? Or are there any others you recommend?