DevOps, lies and jokes

Yesterday I was asked by my son about the difference between a lie and a joke ... one of the most interesting browsing results was "A joke is an acknowledgement of truth within the lie" (source) that unfortunately does not help the explanation to a 5y.o. child.

Finding a response to the lie vs. joke debating for a child is like finding a explanatory definition of what is DevOps for obsolete It managers.

Ok... the easiest and sometimes usefulness way to define DevOps is to list what is not DevOps like:

1. DevOps does not have a size that fit all
2. DevOps is not only tooling and automation
3. DevOps is not merging Developments and Operations
4. DevOps is not a framework
5. DevOps is not a lot of other things

so .... this does not provide any response to the root questions. What does it mean? Why do we have to adopt the DevOps? How we can do things? Is there a path for DevOps adoption? What are the benefits of the DevOps?

The DevOps is a practice or better

• DEVOPS IS A PRACTICE

mumble mumble ...

PRACTICE: the act of applying something to a particular use (source).

Synonimous: custom, use, way, system, rule, method, tradition, habit, routine, mode, usage, wont, praxis, usual procedure

I write it again "DevOps is a Practice = DevOps is the act (or better the art) of applying something to a particular case.". This can help.

The art

• A new way of working that is mainly focused on culture and people

of applying

• that has to become the standard way of managing things - processes

something

• IT automation procedures, test automation and measurements - using tools

to a particular case

• to YOUR company, using your set of tools and processes ... and within your organisation

So the DevOps pillars are now clear: People, Processes and Tools. All of them must be tailored to each company (and sometimes adapted for kind of projects).

There are no predefined rules; there are no defined paths; there is not a defined set of tools and processes. DevOps is something that has to be built from the basics in each company.

Looking and investigating at other companies can provide examples of DevOps practices, but it is not guaranteed that a successful DevOps model can always do acceptable results in different applications. Let me try to be more pragmatic about a DevOps in a graphical way mixing the pillars (People, Processes, Tools), please note that the following is only an example of what the DevOps cand do and Help.

In red the realistic injections of the DevOps to the more classical legacy development flow in brackets some desirable extensions

1. PLAN: Capture requirements, plan execution, define metrics, test strategy, monitoring points
2. CODE: Code writing, configurations, test definition, unit test, code validation, code versioning, and security checks
3. BUILD: Sw build and configuration for each env. pipelines for It automation (Configuration Management Database or asset catalogue)
4. TEST: Integration test, performance, system test, test automation
5. RELEASE: Release packaging release orchestration, release note, approval workflow, rollout management
6. DEPLOY: Automatic code deployment, automation on sanity checks
7. OPERATE: Running software on infrastructure legacy/ serverless, measure improvements
8. MONITOR: Measure, optimize, alarms, monitoring and automation on issue management

Now at the end, this article can be interpreted as a serious note about DevOps, a joke or a lie - your turn now!