Intro

Have you ever asked yourself what is the definition of DevOps and didn’t know the answer?
Before I worked in field, I was in this situation. When I searched for the definition, it all sound foggy and unclear.
When I asked people around me, they didn’t had a good answer. Some thought it writing CI/CD pipelines and other thought is maintaining infrastructure like k8s.
After working almost 3 years as DevOps engineer and later as DevOps lead, I crafted my own definition for DevOps based on my own experience and belief.

In this post I want to share with you my definition, so you can have better understanding and/or get a new perspective on DevOps.

This post has 3 goals:

• Introduce you to DevOps. (if you not familiar with it already)

• Showcase my definition and explain each part of it.

• Show you a few example which you can learn from and use in your DevOps ecosystem.

Definition

"DevOps is a practice which focuses on delivering a product quickly and frequently while maintaining the quality of the product."

This might sounds overwhelming, so let's break this statement into smaller parts for better understanding.

'a practice'

“DevOps is a practice which focuses on delivering a product quickly and frequently while maintaining the quality of the product."

To solve DevOps problems we have two main tools we can use: Tech tools and Organization culture.

Tech tools

Refer to all code which composes our DevOps workflows like CI/CD, IaC or any other script which helps us deliver our product.
Those tools let us automate workflows and make sure our product will delivered and behave as expected.

Organization culture

Some DevOps issues can't be resolved only via tech tools and we need the collaboration of the developers to solve the issue.
Semantic release is a great example which show us, that without cooperation with engineers, the tech tool which solves the issue is worthless.

A DevOps oriented organization culture isn't built in one day, is hard to keep over time and you always need to collaborate with your engineers and get feedback. Unlike a tech tool where you can implement it and it will stay forever. From my experience, tech tools like a CI job stayed untouched for a long time.

At the end of day the engineers are your clients!
Make sure the workflows you implement are serving their purpose and not making their lives miserable.
It’s important to talk with your engineers on a regular basis to be able to understand their struggles and find them a solution.

'quickly and frequently'

“DevOps is a practice which focuses on delivering a product quickly and frequently while maintaining the quality of the product."

With the power of automation, we're able to deliver a product much faster and with little to no mistakes.

This part is conducted from two sub-parts.

'quickly' is about "How can I optimize my workflows to run faster?" which includes things like caching our workflow or splitting the task into smaller tasks with parallel running.
The second part, 'frequently' is about "How can I make my workflow easy to do?", which may include simplifying the steps of a manual process like deployment.
The more simple and satisfying (if possible) the steps are, the more likely we'll repeat an action multiple times without hesitating.

When you master the 'quickly and frequently' part, you can release a new version without doubts.

How can I make sure my release workflow is quick?

Mapping time!

The best way to map is by releasing a new version by yourself and document the process.
You’ll see all the small steps you should do and you might find undocumented steps.
Next, write down what can be can be automated and document well what can’t be automated. Make sure to document well manual steps and document the actions which should be taken when something goes wrong.
The last thing you should do is to make sure all release steps relevant.(During my job I’ve seen irrelevant jobs like “test” in the release workflow)

Optimize

Now your mission is to find bottlenecks.

Check each step run time and ask yourself - Does it run for too long?
If the answer is no, check the next steps. If the answer is yes, you’ll have to investigate.(More on that in a later post)

Repeat

As the product evolves so the integration and release workflow evolves too.
Be aware to changes and update your workflow as needed.

'quality of the product'

“DevOps is a practice which focuses on delivering a product quickly and frequently while maintaining the quality of the product."

This part is also known the integration. In this part we make sure our code was written properly by linting, building and testing our code. Without this part, your product wouldn't be worth much even if you master the 'quickly and frequently' part.
Sure, bugs will come and go and even if you can roll out a fixed version of your product quickly, still you'll have credibility issues and your teammates will focus on fixing their old bug instead of writing new features.

Quality not only includes tests but also monitoring of the product after it's been released. Monitoring will let you know when there is an issue before a client will knock on your door and tell you - there is a problem.

Takeaways

DevOps is a big world which has unique problems and more important, unique tools to solve it.

The post covers multiple topics, but if I had to give you two advices which will benefit your DevOps team the most, it would be:

1. Organizational is key to success. The biggest problems I've faced were related to it. You must to collaborate with other developers in your team.

2. Invest more in 'quickly'. The quicker and easier you'll be able to deploy a new version of your product, the more features will see light and the less downtime will be when there're bugs.

Epilogue

If you've reached so far, I want to thank you for reading the post!
Join me for the next posts about DevOps where I'll share with you my experience and thoughts.
Let me know what do you think about the post and which things should be improved.
You more than welcome to contact me on LinkedIn and on X(Twitter).