I believe the principles that are fundamental to DevOps are:
- Plan for Success
- Build Great Software
- Continuously Integrate
- Continuously Deliver
- Monitor Constantly
- Collect Feedback
There's also a concept from Chaos Engineering called "Continuous Verification" (CV) which we'll cover in a future update of the book. It's worth checking out and understanding the term, however.
Visually this looks a bit like this:
graph LR a --> b b --> c c --> d d --> e e --> f f --> a a[Plan] b[Build] c[CI] d[CD] e[Monitor] f[Feedback]
Each of these principles plays an important part in the overall delivery of software, but another part of DevOps which is potentially the most important is one simple truth: it's about people.
It's about people¶
There is a great article by Todd DeLaughter called, "The psychology of DevOps: Understanding people is key to success" that simply claims:
I would argue that the discipline that teaches us most about DevOps isn’t computer science or engineering but psychology.
of course Todd is referring to human psychology and making it clear that understanding people and how they work (together) is what DevOps is really about.
Todd goes on to explain that tools, technologies, etc. are the implementation part of the DevOps practice. We hope to teach you the psychology and the "Why?" behind DevOps followed by the, "How?" and the technologies.
Give Todd's article a read and then continue on here.
Plan for Success¶
You shouldn't build a house without a great plan, so why build software without a great plan?
When it comes to planning what software to write, what changes to implement, and how, you cannot beat Agile. It's a system that some argue is separate to DevOps but I argue that the two are tightly coupled. After you've finished using Agile methodologies to plan and iterate on your software solutions, you follow up with DevOps methodologies to build, test, deploy and monitor it.
From the Atlassian article, "Agile vs. DevOps":
Ultimately the goals of agile and DevOps are the same: to improve the speed and quality of software development, and it makes very little sense to talk about one without the other.
This book won't go into detail about Agile because that's an entire job in its own right
Both Agile and DevOps work in conjunction to get software in front of users quickly.
Build Great Software¶
The process of writing the actual software doesn't fall to a DevOps engineer, but that doesn't mean we're not involved in some of the processes.
Software engineers have objectives to meet in the form of features and bug fixes. Our job as DevOps engineers is to help software engineers build software that's easier to test, deploy, monitor and maintain. This primarily involves talking about technology choices and how they're implemented. If there is a disconnect between the two engineering teams on even one of these points then the job of getting great software in front of users quickly breaks down.
A good example of this is when the software engineers do not collaborate with the DevOps engineers on the language and framework they're going to be writing the software solution with. If the software team decide to use C#.NET with MS SQL Server hosted on Windows Server, but the DevOps team (in isolation at this point) start building CI/CD systems on top of a Linux foundation, then there's going to be a lot of work to either stick to the current options or rework everything and introduce different technologies (be it change the language/framework or the CI/CD tools - the latter is the option to change in this scenario.)
The software engineers are trying to build great software and when us DevOps know how they're going to do that, we can make technology recommendations and choices that are going to be a near perfect fit from day one.
Remember: you're building a product¶
In "Products not Projects" by Chris Blackburn we get some excellent insights into how-to better treat the software products that we're creating by actually treating them as products. What I believe Chris is saying, at a high level, is that software products are pieces of continuous work that should be seen as a series of features that are ever evolving and growing with time. By thinking of the software we create as a product that we grow and nature over time, we'll build better software.
Strictly speaking Continuous Integration (CI) is about merging together multiple changes to a code base. You use CI to merge the changes into a single code base and then build an artefact from the results. However CI is also used to test the software changes that are being proposed before they're merged into the primary code base (which is often represented by the
main branch in a git repository) to ensure that they meet business expectations. This makes perfect sense because once a software engineer pushes their changes, ready for "inspection", that's the ideal time to run tests against those changes. Further more once the changes have all been merged, that's also the perfect time to rerun those changes to make sure everything is working as expected in conjunction with one another.
When put another way: with CI we test and validate, then merge, then build an artefact. We can visualise this process easily enough:
graph TD change1 --> branch1 change2 --> branch2 change3 --> branch3 branch1 --> test1 branch2 --> test2 branch3 --> test3 test1 --> branchmain test2 --> branchmain test3 --> rejected1 branchmain --> build change1[Change 1] change2[Change 2] change3[Change 3] branch1[feature/1] branch2[feature/2] branch3[patch/1] test1[CI: Pass] test2[CI: Pass] test3[CI: Failed] branchmain[Main] rejected1[Merge: Rejected] build[Artefact] classDef goodtimes fill:green,stroke:green,color:white classDef badtimes fill:red,stroke:red,color:white class test1,test2 goodtimes class test3,rejected1 badtimes
In this example we've continuously integrated software tests into our pipeline (a term you'll become familiar with later on) and those tests have accepted changes
2, but rejected change
3. As a result of this CI pipeline we have successfully prevented bad code from getting to the production environment and therefore the end user. That's a big win.
That's why we Continuously Integrate as DevOps engineers.
The software you've taken the time to plan, write, test and finally compile/build is pretty useless if you're not then deploying it to end users. That's obvious, but what isn't obvious is just how wrong a deployment can go when it's done manually. As DevOps engineers we're here to implement Continuous Delivery (CD) and remove the human from this process as much as possible.
Deploying software is where the "Ops" side of DevOps (truly) comes into the picture. It's also one of the most complex parts of process outside of the software itself (which doesn't really involve us as much as the operations side of things does.) This side of a DevOps engineer's job is also when all the tools come into the picture, and there is a lot of them.
Our part in Continuously Delivering a piece of software involves planning, building and implementing systems (known as "pipelines") that take software artefacts and get them in front of users as quickly as possibly without sacrificing stability, security, code reviews, testing, and more. Put another way: we're trying to do is remove the human from any and all systems that involve delivering software. Once a pipeline has been defined as a system of inputs, steps and eventually some output, the human is removed from the act of deploying software and the software development cycle gets real fast.
The use of the word "monitoring" here is more holistic versus the traditional use of the word in IT. In the latter use case "monitoring" refers to the act of watching a system for signs of failure before, during or after the fact. However in DevOps it means two things:
- Watching the systems you're building for failure, and...
- Watching your processes, systems, pipelines, etc., for opportunities to optimise things
Each of these tasks is critical to the operation of a software solution, especially a SaaS based solution. They both offer the ability for us, as DevOps engineers, to collect information we can use to improve our processes, optimise pipelines, discover new things we need to automate and, of course, ensure the solution stays online.
Monitoring is a big topic. We're going to be covering it in a future update to the book.
Collecting feedback brings us back around to communication and collaboration, but this time we're not just speaking with internal teams because we also need feedback from the most important person of all: the customer.
When in to comes to operating in a DevOps driven software project, especially one that combines and uses Agile development practices, the act of collecting feedback from your customers is paramount. It's the core tenant of Agile development because it's what enables us as an organisation to build the best solution possible in near real time with the customer's pain points.
But in DevOps we don't just take feedback from the customers and end users, we also take feedback from internal teams (who become our customers) on how we can improve our processes, systems and pipelines to better serve them.
Now let's look at communication and how it's an important part of DevOps best practices.