Today, more than ever before, DevOps seems to be everywhere. But is it really? And are you doing it right? It seems to be this thing that everybody knows about and likes to say they do, but in practise people often have the wrong end of the stick.
“So, then, what is it?”
DevOps is a cultural movement in software, not a single role or team. It consists of a huge range of not-always tangible things; philosophies, processes, tools, a learning attitude, resulting in a cohesive and able team. It constantly moves, not necessarily rapidly or even in a particular direction. It’s more like breathing. A living, breathing culture, moving not for the sake of movement, but because the team and technologies are evolving.
It attempts to pull project contributors together into a single culture with a wider world-view, as opposed to the traditional separate silos of specialism (in this case, typically “Dev” and “Ops”).
By doing this, we may focus on collaboratively doing whatever we can to make the process of software-improvement into a smooth, predictable, repeatable journey, optimised for speed of delivery. The speed of value to a customer.
The actual implementation and tools used to achieve this could be completely different to how another team at some other company achieves the same thing. But your mindsets will still share a common DevOps approach. By having a wide pool of people sharing knowledge, we can begin to ensure a consistent set of qualities to your software.
But to have this wide pool of people, you have to break down walls.
Sometimes, when people are first introduced to the idea of “DevOps”, they worry it adds a new barrier with a few individuals bridging the gap between “Dev” and “Ops”. When executed correctly, this is the opposite of what happens.
Instead, operations-minded folk become more familiar with engineering tasks, and vice versa until they begin to operate as a single unit.
By unifying the two processes, overall development can move faster.
“Not that I’m doing it wrong (obviously), but what would it look like if someone was?”
Have you recently referred to a single team or an individual as responsible for your company’s DevOps?
Once you have moved towards adopting DevOps it might feel as though you have some DevOps specialists that can fix it all for you. Despite this, it is essential to remember that a team or set of individuals is not responsible for DevOps in an organisation. You shouldn't stop just because your process has got better than it was. Improvement is good, don't get me wrong, but by consolidating and improving on the cultural aspect of DevOps, you can embed this mindset in your organisation and grow upon it.
“So, what do I stand to gain?”
However you set about it, DevOps best practice focuses on ensuring quality, stability and security by automating the provisioning of infrastructure and build of applications. This can then be extended to ensure the correctness of the software by providing feedback (via tests), and finally, when ready, deploy it to end-users.
The immeasurable value of, well, measuring things (footprint of applications, how resources are being consumed) and proper logging gives everyone a wider insight into how to move together in a single direction to fast, quality, deployed software. When these are shared values across a team, they can guide application development into taking a pro-active role in ensuring the reliability and availability of the application.
By adopting this mindset, we can all continuously look to improve the flow of software delivery and feedback loops in the software pipeline.
You’ll see the benefits of DevOps, from traceability and repeatability in an application’s infrastructure, elimination (or certainly reduction) of departmental silos, faster delivery from idea to feature and reduction in repetitive, error-prone development tasks.
“What does your DevOps look like?”
At Black Pepper, we're proud to believe we have a positive learning culture where everyone is free to innovate, try new things and grow in to well-rounded technologists. As a result, we're pleased to offer DevOps consultancy and upskilling.
Internally to Black Pepper, all technical staff are in control of their software's lifecycle, from development to deployment. A wide range of source control, orchestration, testing, and CI/CD tools are default, alongside the knowledge share and no-blame culture baked in to the company for the last two decades.
We're constantly evolving too, with everyone contributing new ideas and process improvements. Martin Blower, the head of technical strategy at Black Pepper, sums up why it is so essential below.
All that is left to ask, is do you have the DevOps mindset?