Companies want it but are unsure of how to approach it.
And while its an interesting trend, it should be fitted to products, not the other way around.
But some people dont see it that way.
Such questions are meaningless without even knowing what the product is about.
All those fancy termscloud,Kubernetes, containers, configuration management, Infrastructure-as-Codepromise some improvement.
But they are toDevOpsjust as telescopes are to astronomy.
They may be useful, but they are not necessary.
There is an emphasis on short release cycles, iterative approach to design, and automation of repetitive steps.
What do you think is most important to bring those to reality?
If you said great communication, you are right.
The tools are all fine.
But they are only worth the money invested in them when they improve communication.
One aspect of communication is knowing whats necessary to get the job done.
And the job does not mean code is committed to the repository.
Think of it rather as the client saw the change in production and accepted it.
Well, Im a huge advocate of maintaining aREADME.md.
Automation, the next step after writing a README, is optional.
It is, though, a natural outgrowth of documenting the process.
And yes, automation is what often comes to mind when thinking about DevOps.
Wait a minute…automation is optional when it comes to DevOps?
Isnt DevOps the department of the person who does deployments?
So lets take a closer look at DevOps itself.
DevOps is akin to Agile development.
Would you hire an Agile developer as such?
Either you develop product in an Agile way or you dont.
How then can DevOps be described?
Perhaps even a spirit.
To a lesser extent, it also means that everyone uses the same tools.
These tools arent meant to help any single group of people.
They are meant to push the product forward.
Going with this concept requires a serious change of mindset, which is the main obstacle.
Developers suddenly need to learn how the cloud works and start to deploy their own code.
Operations people need to abandon manual setups and start coding.
Everybody needs to learn new concepts.
Everybody has new responsibilities.
This isnt easy, but with good communication and a common goal, it is quite achievable.
This communication involves establishing a culture, setting up lightweight processes, and maintaining proper documentation.
DevOps automation is documentation
You probably never thought of it that way.
These processes can then be run manually or be automated.
Whats important is that every stakeholder in a project is able to follow them.
Documenting your processes as code has one big advantage over usual instruction manuals.
Code can be verified and behaves predictively.
Given the same input, it produces the same output.
With written instructions, youll have as many interpretations as there are readers.
If you write ambiguous or vague documentation, the person that reads it will fill in the gaps.
Point is, you have no control what goes into the gaps.
Its much simpler with code.
Without concrete steps, the program will cease running.
These concrete steps are one key aspect of DevOps communication.
As nobody knows what is happening, everybody is fighting fires without much progress.
The book subtitle mentions that its a tale of DevOps.
I agree with that.
But whats interesting is that throughout the course of the book, not a single new tool is introduced.
Can you achieve a state of DevOps by improving communication alone?
The protagonists of the book did it, so theres hope for you too!
But the opposite is true.
DevOps team structure: Whos on a team?
Ideally, each product should only have one team: the product team.
I was once on a development team where a common goal with other teams was absent.
The development team wanted to push as many changes as possible.
The validation team was tasked with preventing the introduction of defects.
They had different managers and they were evaluated individually.
Development and Validation played ping-pong with defect reports.
But the lack of proper cooperation and silo mentality made it very hard to notice.
By waste, we mean everything that is not directly relevant to what the clients ordered.
Piled up work-in-progress is a waste.
Every step of a process that does not clearly lead to release is a waste.
But waste can only be seen from a high level.
In the scope of one team, some procedures may seem essential.
From the product perspective, though, they may well be useless.
You also need to think from a clients perspective.
Is this feature something the client wanted?
If not, you may as well skip it at this time.
Are your processes simple and lean?
Take a deeper look especially on those that cross team boundaries.
Do you want to double-check the development of a product is as efficient as it can be?
Invite an outsider to see how you work.
The three middle values are more technical, whereas the outer ones relate to soft skills.
Same goes with sharing.
Sharing something basic like food doesnt require communication.
The gesture itself, however, can also be seen as an act of communication.
I care for you, so I share with you.
We dont want to limit the scope only to verbal communication.
Sharing ideas and tools, however, requires communication.
How should we share them?
Where are we to put them?
Are they useful for every person on a team or just for a smaller group?
Whats so good in having an automated deployment script that nobody ever uses beside author?
If the script saves her some time then it might be justified.
But imagine how much time could be saved if everyone shared this script.
This says something about fighting waste!
DevOps brings business closer to development
Some say DevOps brings operations closer to development.
This is true, but its not the whole truth.
When done right, DevOps brings every unit closer.
It allows business and clients to see what development is doing, almost in real time.
This shorter feedback loop benefits all stakeholders.
With traditional deployment, you might wait several months before somebody notices bugs or missed requirements.
With continuous deployment, everyone can react to any problems as they arise.
DevOps tools first?
Think again
Of course, theres a need for all the tools to make it possible.
But no amount of tools can be a substitute for good communications and empathy within the company.
Problems with the build system were common.
Developers were unsure how to use it.
Everybody wanted to improve the situation, but there was no understanding between the two teams.
This meant that both sides introduced new tools without consulting with the other side.
This only widened the gap, instead of closing it.
If you want to start a DevOps transformation within your organization, start with improving the way you communicate.
Dont simply assume a solution: Brainstorm with an open mindfirst.
Then you might find that, for example, tooling support is insufficient for your needs.
The quickest way to establish DevOps?
Then engineers can figure out the development and deployment model.
Finally, you could determine which tools are needed.
Once all the requirements are documented, technology choices are much easier to make.
I am an advocate of all the great DevOps automation tools that make our work easier and more manageable.
But our daily job is working with people.
Lets invest some time to improve on this aspect of DevOps best practices rather than getting another technology certificate.
