Dev-◯-Ops: The Trinity
Over my years working as a DevOps engineer, I have observed something between Dev and Ops called the “circle of work, ◯”.
For simplicity, we can call Dev-◯-Ops as DevOOps/ DevOops interchangeably, as it is easier to type O instead of an ASCII circle ◯.
What is the “◯” between Dev and Ops?
It can mean many things shared by the team
- A passion
- A thought process
- A practice
- A mindset
- A belief
- A mutual agreement
- A relationship
- or perhaps Anything
I have organised 15 of them based on my interpretation and definition.
We will start with one of them in this article, an idea that is pretty common to us, and I hope people can view it again with a perspective of mine.
1/15: The Trinity of Delivery, Test/Security, and Engineering
How it started
We were obsessed with “velocity” (aka “delivery speed”) when we started our agile journey many years ago. First, we argued if pair programming and tests were necessary as they slowed down velocity. Eventually, we concluded that they were essential.
For the reminder, I created the following diagram to show that “sometimes it is okay to be slow, with good reasons”.
Most of the readers are probably scratching their heads right now, trying to figure out the meaning of this diagram.
I will explain it after I share my objectives for this article and ◯.
The Objectives
- For people who are already test practitioners, perhaps this article/◯ will give them a laugh/relax moment when they are exhausted sharing the importance of tests with others.
- For non-believers in testing in software engineering, this article may not change their minds. But I hope it can plant a seed that one day they will appreciate the test practices (especially for engineers).
- To describe the various project/product delivery scenarios using the diagram, perhaps to ignite people’s thought process when dealing with the trinity.
Now we can continue to break down the diagram and explain the individual parts.
The square represents the product in general, it is something we want to deliver to our users, and it is a result of design and coding.
Followup with a right triangle represents a CI/CD pipeline, a framework, a tech stack or a deployment platform which is technically responsible for delivering our product.
Combining them into “square on top of the right triangle”, which represents “object on the slope” or “product getting ready to be delivered”.
A purpose provided by the organisation, suppose in the form of a gravitational force, pulls the square downwards. It will then cause a splitting force, “Delivery” with a “Velocity” (aka “The speed of something in a given direction”).
This “Delivery” will continue with the “Velocity” with the active pulling force, moving the square from the top to the bottom of the slope, completing a cycle of “Delivery”.
Time to slow down
However, without friction, the square may be “sliding” too fast, resulting in a hard landing and suffering potential damage.
Friction is thus applied to the surface between the square and the slope/triangle. The surface represents our “test/security”, including unit tests, integration tests, regression tests, security tests, or manual tests.
“Sometimes it is okay to be slow, with good reasons”. It reminds us that it is worth spending more time during the delivery in exchange for better sustainability and stability in the long run.
If we link all the pieces together to the trinity of “Delivery, Test/Security, Engineering”, we will get
Understanding the basic relationship of the trinity elements, we will now talk about their individual roles.
Solution (product) will be developed and delivered to the end users when a purpose is provided by the organisation/government/team to solve a problem.
Do we need a purpose?
Delivery goes into chaos without intuitive, pragmatic, and meaningful purpose. The team may not be motivated to care about product delivery, integrity and sustainability. The product scope goes through rapid unnecessary changes.
Eventually, the product will enter a free fall and likely to suffer human overboard or bad fall damage.
On the other hand, when the force is trying/pulling too hard, it may cause the opposite effect and collapse everything.
How can delivery be conducted?
Do we prefer to deliver everything in one go?
Do we prefer MVP (Minimal Viable Product) and continuously deliver?
Do we break down the product but still deliver everything in one go?
Do we change product scope multiple times during delivery?
Engineering is the skeletal structure of this model; our technological choices and practices that we embrace dramatically affect the overall system structure and its stability.
Is a famous tech stack always the best tech stack?
Maybe yes, or no. Ask ourselves the following questions
- what is the famous tech stack good at?
- Is what they good at happen to solve our problems?
For instance, a good and famous git repository doesn’t mean it does a great job in modern CI/CD where robust pipeline as code and DRY (Do-not-Repeat-Yourself principle) is generally demanded.
How do we decide our tech stack?
The fear of making the wrong decisions will always bother us from the day we start to make decisions. The solution is simple, don’t make the decision OR own the fear.
Sometimes it is okay to not make the decision because the opportunity cost of waiting is not high. Still, we almost always choose the latter solution.
Requirements change as time passes. We can’t predict the future regardless of how eager we want to. However, we can gather as much data to manoeuvre in the right direction when we have to, there is always a price to pay, and we hope it won’t be hefty.
Starting small is also an excellent way to reduce the cost of change.
Please have a read at Steven Koh’s posts regarding agile development
https://medium.com/singapore-gds/is-agile-architecture-oxymoronic-43511454df5e
How can we choose/design our tech stack?
Do we prefer one that can deliver fast by nature?
Do we prefer one that is relatively stable?
Do we prefer something that was promising at early phase but the author never maintained in the end?
Do we prefer to use thumb drive to transfer deployment packages between environments?
Test and security, if done right, ensure product integrity. It is a worthy trade-off of the present time in exchange for better product sustainability and stability in the long run.
How can tests be conducted?
Do we prefer automated tests along the delivery journey?
Do we prefer manual tests/security near the end of the delivery?
Do we like tests with bad coverage?
Do we prefer the end users to test for us?
Summary
I couldn’t go through all the models as I wished, and I may edit this blog post in the future to add more diagrams as I see fit.
Before wrapping up this ◯, I hope people are intrigued with the idea of having the tests in their delivery and pay more attention to the test/security and engineering in addition to delivery.
Vice versa, this ◯ also reminds us that delivery is equivalent important when we focus too much on test/security and engineering.
I will talk about engineering and security in other ◯.
Until we see each other again in other ◯, to be continued…
Credits
- All folks who gave advice to improve the readability of this article.
- Draw.io for diagram drawing
