I have started recording a series of video’s explaining some of the principles and sayings I use when I talk about DevOps. There are teams that I meet that have no idea what DevOps is and why we are doing some of these things for it. I’ve found myself referencing something like ‘Shift Left’ and then having to explain it to the teams and their management that I am helping with something that for me, is related to something in the DevOps culture.
I also want share that information with the rest of the team members that weren’t there at that time. So for these cases, I thought it would be nice to have a set of small video’s available that I can share and explain those things to everyone.
Creating these video’s helps me getting a little more comfortable speaking to an audience, even if it is through a camera lens and with the ability to stop and do it again 😄. It also helps that I have some time to think through the message I’m trying to explain to the team. From there I am trying to get my intonation and articulation under control. This stuff is all new to me, so I am figuring this all out live on the job. I’m learning tons of stuff I didn’t really think about before. This will be explained below. Somehow I like to challenge myself and do this stuff out in the open 😁.
I have a different post explaining my setup and learning process on recording: link.
You can find the entire playlist here. I try to keep them as short as possible: bite-size!
Some of the topics explained are:
I couldn’t just start and not talk about the origination and basic idea’s behind DevOps. This is a starting point for the series so I took a little extra time to explain why I started creating these video’s. You can find this episode here or watch it below.
The first principle I explained is ‘Shift Left’, a common theme when we talk about DevOps. The basic goal here is to have a fast feedback cycle on anything in the development process. Watch this episode here.
In this episode I explained the reasoning behind ‘T-Shaped engineers’, because we move from traditional role based work like ‘developer’, ‘tester’, ‘systems engineer’ to a more generic ‘engineer’: someone with a broad skill sets in multiple aspects of the traditional roles and deep knowledge about one (or more) of them. Find the episode here.
On of the DevOps things that I say a lot: if it hurts, do it more often! If you only update production twice a year, it will be a scary activity to do: lot’s of things can go wrong! To make this activity a non-event, we need to do it as often as we can. We will learn how to do it and we can fix the things that go wrong and improve on them. Watch the video.
If you follow this principle, running the software in production becomes a team effort. Instead of throwing the software over a wall, you handle it as a team. This also means setting up monitoring and alerts and thinking about observability during the development process. Find this video in the link.
Making sure you work on the software and embed the knowledge about it in the team can be done by following the four eyes principle. This makes sure that no-one is working on things by themselves. This will help on other things as well, like the team spirit for example.
Automating everything is a bit large as a saying. It’s not about automating everything in an effort to just blindly automate everything: it’s about thinking of automating every step in the development process: could we benefit if we automate this step and is it worth the time we take to automate it? Watch the video.
Creating these video’s and sharing them online has been an interesting journey, I learn something new every time 😄.
If there are any topics that you feel have to be included, please let me know!