5 DevOps Best Practices
Вставка
- Опубліковано 3 сер 2024
- 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 would like to assess how good your CD capability is compared to these best practices, you can get a FREE "How To..." guide here here ➡️ www.subscribepage.com/cd-asse...
---------------------------------------------------------------------------------------
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses:
➡️ bit.ly/DFTraining
📚 BOOKS:
📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
Amazon ➡️ amzn.to/3DwdwT3
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
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 The original award-winning “Continuous Delivery" book by Dave Farley and Jez Humble
➡️ amzn.to/2WxRYmx
--------------------------------------------------------------------------------------
Continuous Delivery Ltd. ➡️ bit.ly/ContinuousDeliveryDF
Dave Farley's Blog ➡️ bit.ly/DaveFWebBlog
Dave Farley on Twitter ➡️ bit.ly/DaveFTwitter
Dave Farley on LinkedIn ➡️ bit.ly/DaveF-LI
----------------------------------------------------------------------------------------------------------------------
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
➡️ amzn.to/2YYf5Z8
"The Phoenix Project", by Gene Kim
➡️ amzn.to/3csuuop
"The DevOps Handbook", by Gene Kim, Jez Humble, Patrick Debois & John Willis
➡️ amzn.to/2LsoPmr - Наука та технологія
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?
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!
Thanks, there is some interesting stuff being written on applying these ideas to ML.
@@ContinuousDelivery any recommendations?
@@randomclimber This is a decent start I think martinfowler.com/articles/cd4ml.html I also like the work that I have seen from Emily Gorcenski ua-cam.com/video/bFW5mZmj0nQ/v-deo.html
@@ContinuousDelivery Thank you very much!
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.
Thanks for the suggestion
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.
oops, totally posted this on the wrong video :)
I think that your last point is a choice, but a good one. You can have good architecture, and relax the inbuilt protections if the team is very good and very disciplined. Risky, but certainly possible - A kind of "Running with scissors" model.
I think that the link between Bounded-Context/DDD and Microservice is often missed. When you get it right, the conversations between the services, though technically encoded, make sense at the level of the biz problem - which IMO is a VERY nice property to have.
YT doesn't let me move it either, No worries :)
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 ?
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.
I think it depends on what you need to know to qualify for release. The most definitive measurement is "everything works together because I tested it together". If the system is decomposed to the point where each component is "independently deployable" (Microservice) then fine, but I have to do work to defend that "independent deploy-ability". If I test my components independently, in their own pipeline, but also test them again in some "integration test" with other components, then this is just another monolith, except now I have constrained my optimisation choices. I could have parallelized the build in lots of different dimensions if it were a "single repo monolith" but if I separate each component, I no longer have those options.
So Service-based pipelines, followed by detailed integration testing, seems like:
1) a monolith and
2) a sub-optimal monolith
to me.
Are these your top 5 recommended practices? Or are there any others you recommend?
No there are more, but thanks for asking and stay tuned for a future episode when I will describe 6 more recommendations.
All of the recommended practices are based on the correlative model for software dev team performance that is at the heart of the Accelerate book:
"Accelerate, The science of Lean Software and DevOps", by Nicole Fosgren, Jez Humble & Gene Kim
➡️ amzn.to/2YYf5Z8