Setting Dev Standards

[00:00:00]
>> So we've talked about defining DevOps. Cool, I appreciate you guys still being with me here. Let's talk about standards versus rules. How many here like rules? Anybody in programming, anybody like rules? Yeah, you like rules, okay. So more often than not I have discovered that when you tell a developer that they have a rule they immediately hate you.

[00:00:27]
And so again not even talking about programming now how do we get around that, right? How do I get around to the developer yelling, say, I was gonna be like this? And then you simply go, because it's a rule. Changing how you even conversate about things, again, related to culture can be massively important when trying to make impactful changes at companies.

[00:00:53]
And so what I wanna kind of talk about now is okay, we've defined DevOps, and we have a good idea of at least, some of the things we wanna do, how do we do it in a way where we're not just stepping over everybody? And I think that first step is going to be implementing standards instead of rules, right.

[00:01:15]
As I said, developers don't like rules, however, they will adhere to standards for the greater good of the product. Most of us I would hope will agree that being in an engineering conversation and somebody brings up, well that's great, but like this is for the greater good of the product, or this is something we've all agreed upon.

[00:01:34]
Normally that can be a way of saying, okay, let's keep our guiding star, let's keep our focus, and it will make it a little easier when you don't want developers to do things that they probably shouldn't do. Rules are normally, something that are pretty hot topics. And another thing I think about rules that are not good is they don't seem like they're bendable, they don't seem like you can change them, and that's not true.

[00:02:05]
If somebody was to come into DevOps and say, hey, we've got this standard, but it's terrible, it's wasting so much of our time, I couldn't argue that. I'd have to sit down and be, okay, cool, where are we failing, what can we do? Whereas somebody who hears that, well we do this as a rule may not even bring it up.

[00:02:27]
They may just say, well, this is how we've done things and we're gonna keep saying it that way. And so, again, I think it's really important to note here that developers don't like rules, but they will adhere to standards. So what are DevOps standards? What are they actually?

[00:02:45]
They're guidelines really or best practices that organizations can follow to implement standards successfully. These standards typically cover areas such as communication, collaboration and automation, and can help organizations improve their software development process and deliver better products to their customers. To give an example of this, at where I work, we have two different types of releases.

[00:03:10]
We have a two week release schedule where every two weeks the whole company comes together which some of us probably can relate to this. The whole company comes together and we get into Slack Channel and we work for three hours, four hours to getting our deployment out essentially.

[00:03:28]
That is the standard that we set. We said okay, well, every two weeks we're gonna sit down and we're gonna get this deployment out the door, keyway is not gonna do anything else, they're just gonna focus on this, and that is how we do deployments. About six months ago or so, we realized that that wasn't good.

[00:03:51]
Does anyone have any idea why bringing 300 people together at one time might not be a good idea? [LAUGH]. Yeah, it was something we started realizing is nights would go until 6 PM. If any of you guys have ever dealt with late night deployments, same been there. That's a problem, right?

[00:04:11]
That's a problem that DevOps can solve. And so what did we do? We decided to implement something called FBR or what we call our feature-based releases. And so the whole concept of this is essentially that, instead of having everyone come together every two weeks and basically hate each other, it was better for us to build a system that enabled the developers to deploy on their own, straight to production if they want it to.

[00:04:39]
Now if they you know break it, that's their fault but that's a standard that we've set, where we said, okay, well, as DevOps we will create a flow for you that you can rely on, depend on, if you need to rollback you have the mechanisms there to do it.

[00:04:55]
But at the end of the day, you can now use this standard of deployment if you want, or you can use this standard of deployment if you want. And we've made it so that technically people can go from, the two week deployment and then slowly move over to the FBR back and forth.

[00:05:12]
Again we had to make it so that people were excited about it. There's no reason to build anything if nobody at your company is going to use it, especially with our job. So it was very important to not just build a new flow so that people can easier deploy their software, but it was also really important to build a flow that people were excited about, right?

[00:05:30]
Getting hype around it and things like that, look how easy it is to just, in our case it's all powered by Jira, actually. And so you can literally just move a Jira and then it will simply deploy your your thing for you, again standards. So let's talk a little bit about each one of the steps.

[00:05:48]
I'm gonna give you guys examples on basically where I think you guys can start looking for standards within your company, and hopefully these will be helpful in ways that you can start potentially applying these at your company, maybe if you don't have them. The first one is definitely gonna be automation standards.

[00:06:07]
Automating the software deployment development and deployment process using tools such as CI/CD. The main point here is that, don't do anything twice, [LAUGH] there's no need, save yourself time. If there's a circumstance where you're spending more than five minutes on anything, try and automate it, try and build CLI tools.

[00:06:26]
Try and make it reproducible a lot easier. But the main point of having automation standards is really about making sure that the things you guys are doing a lot are no longer time consuming within the company. Planning standards, I know this sounds crazy but having good standards around how you plan things.

[00:06:51]
I don't expect DevOps engineers or people who work in DevOps to be Scrum Masters, that's what PMs do, but our main focus is still to even work with them, to sit down and say, okay, are we on Scrum are we on Kanban? How does that work within our infrastructure, do we have any concerns about that?

[00:07:11]
We have a new massive change coming down the pipeline, plan for it. You know what I mean, let's prepare for this and so having good planning standards is very important. Quality Standards, my gosh, everybody please listen to this one. Please listen to this one. You have to have quality standards, you have to, bottom line.

[00:07:37]
If you don't, it's something you should really be talking about it your company. What does quality standards mean? Version Control, configuration management, making sure that you have good testing, good ways of auditing your software after it's gone out. This is hands down one of the biggest things that are lacked in software development in general, at least my personal opinion.

[00:08:04]
We do not set our quality standards as high as we probably should, which is what introduces a lot of problems later on. And so again doing things like versioning, version control, just curious for any of you guys here, and in chat, how many of you guys actually use Simva versioning with your releases?

[00:08:25]
Actually, 1.1, 1.2, 1.3, I knew it. Yeah, it's so uncommon, it really is. Unless you're working on a open source project or something like that, right? Which is what you normally think of. Most companies are just using latest, things like that.
>> Are there any books or blogs you recommend that inspired your philosophy on DevOps.

[00:08:52]
>> No, I wish there were, there's definitely again some white papers out there but a lot of it right now unfortunately is just marketing, a lot of it really is. So it is really gonna be important I think, for you to get your confidence, which is why I'm showing what I'm showing.

[00:09:13]
If you're not confident in what you're doing, then you're definitely not doing DevOps, because DevOps is definitely about having that confidence. And again, it may be unique to your experience at your job, it may be unique to somewhere else, but I think that confidence is more important than anything else.

[00:09:36]
And yeah, I hope to see more good information out there. The only other thing I can think of that is helpful is, does anyone here know Kelsey Hightower? He's a very big, very well known engineer, and he works at Google, but he's basically worked in DevOps for most of his career, from what I can tell.

[00:09:58]
He's a good source of information. I would say looking for people who are willing to have a honest opinion about it, he's probably gonna be your best bet with finding helpful resources and stuff like that right now. And again, [LAUGH] hopefully later it'll get better. And again just to getting back into the standards here, communication standards, we talked a bit about quality, right?

[00:10:26]
Well you can't really have quality without good communication. And this is something that I think is also really lacked as well, which is nobody really feels encouraged to talk about anything. DevOps being such a lock door with a lock key, what a lot of engineers might not realize is, I would love to hear your thoughts.

[00:10:52]
I would, because I think what a good DevOps mindset is, is to basically think that you know nothing, and you're basically just constantly learning. And I think that's good in engineering in general, but especially with DevOps, when you have so many different types of things that are coming across, what you have to deal with.

[00:11:14]
You may be dealing with a front end one day, you might be dealing with a back end the other day, and the worst thing you can do, is block that communication with either preconceived notions about things or, well, no, I thought it worked this way, no, it worked.

[00:11:27]
No, [LAUGH] let's just figure out the problem. And so communication is massively important. And that might even mean something as simple as saying, once a week we'll have our team sit down and work together. It might mean that you have other ways of handling that communication, but if you are at a company right now where you feel like communication is a problem to you, then that's probably something that really needs to be fixed.

[00:11:53]
Because it's gonna be hard to make any type of impactful or big changes, especially when that communication is lacking. And what's cool is is that you can even utilize standards to improve them. So things like metrics, right? How many here actually use metrics reliably at their companies for things?

[00:12:17]
Okay, if, okay, gotcha, gotcha, no worries. Yeah, that's another thing that is unfortunately very falling right now in the industry is metrics and data. There's a lot of great companies out there that will tell you, going back to your question of, how do I compare the solution to the problem?

[00:12:36]
Great one, there's tons of companies out there right now that'll say, we'll get your data into charts and it'll look great and you'll get alerts and then it's, well, what's my data? [LAUGH] Okay, that's cool that you've got this cool product, but you can't think about it from the tool.

[00:12:52]
You have to think about what kind of data do you care about. As an example, where I work, we use CICD for our systems, obviously, and one of the big things we were worried about was time spent just running things because we have some monoliths that take forever to do things.

[00:13:13]
And so one of the things that we decided to do was just put in our own trackers for all of our jobs in CI and then start marking those, so that we can simply say, okay, tests are running five minutes, builds a running 10 minutes. And they're our metrics, not somebody else's.

[00:13:28]
Why would we double those metrics? Because then we can do other things with those metrics. We can alert on those metrics, we could solve our problems with it, rather than saying, hey, I'm just gonna lean on what's already there.