 be sure to make it short so we can all get to the beers probably seen this graph when you came in it's obviously not entirely true not even really true actually this is a good point of departure for conversation so by time it's called you ship it you fix it and it's going to be a whirlwind of advice or experience that we've gathered over the last couple of years hopefully you'll be able to avoid some of the pitfalls that we we ran into so how many of you guys work in an organization that looks like this where operations is totally separate from development see if you guys yeah so you've probably run into this problem where the workers wrote some crude they give to us people it blows up it's actually pretty bad problem and the problem is sort of this developers write the code they give to the apps people if something breaks apps people get paged and they have to figure out if they can fix the code or they need to wake up a developer and it's kind of you know the problem is accountability here if you know that someone else is going to be paged when your code breaks you're just gonna write slightly worse code than you would if you were gonna get paged if the thing breaks this is true nature I guess so we've employed a policy of if you ship it then you fix it and a prerequisite for this to be useful is that if you build it and you ship it so you ship it sorry you build it you ship it you ship it you fix it so you're accountable for the whole process the whole way from building code to actually making sure it runs in production so is this develops those are just point what develops is everybody's kind of not in agreement about what it is so I Google it and this is there's a lot of different opinions on what developers these are some of the ones that kind of were mentioned the most I guess and that's pretty good I like them so empathy makes a lot of sense empathy across departments trust and respect and working towards common goals and breaking down silos in the organization that all makes a lot of sense so this could be what develops looks like in a modern organization you've outsourced most of the hard cooperation stuff to rack space Amazon the local etc and then you have developers you can't see but down there is a developers and there's perhaps also an office person and they're working together and they're doing development but also web operations so this is an example of what develops in modern and modern organizations could look like so let's say you already got this DevOps thing figured out you bought some deluxe for the team everything is good what can you do now to actually improve the situation you got all the key points to be found is that you need to increase transparency and that means you need to be able our developers need to be able to figure out what's going on and one important way to do that or good ways to do that is to make sure that the developers have the tools they need so good tooling is really really important making sure that developers have access to the best tools they can find and that all the workers have access to this to these tools and here's an example it's pretty pretty small up there on the screen but the idea is that an hour and I happened and you log into a system you can see a stack chance you can see who actually wrote the code you can see when it went into production so this is a snapshot of upbeat and it's a way to increase transparency so the part is you can see exactly who wrote the code and when it went into production another example of increasing transparency is this this is a screenshot from our slack link and what happened here is that Benny who's a great guy you accidentally broke the bill and then it tells him to start doing push-ups so he has to do 80 push-ups now because he broke the bill and baby doesn't like it so it's another way of increasing transparency and making everybody aware of what's currently going on here's a screenshot from the link which is also great tool and this shows performance for a revocation and making sure that everybody can go in and see how their code is performing right now it's extremely important to making sure the developers care about performance so a big part of this is making the information accessible to developers it's how to get to this information they will usually just don't go and get it lazy there's another example of a way to increase transparency make sure everybody knows when new stuff goes into production people will be aware of what's going on in production to actually get a ping that something is out in production another screenshot from our second one and that was a little bit about how you can increase transparency and how that affects accountability in the organization now I want to talk a little bit about releases and sizes of releases and frequency of releases so you can either do big releases this isn't even a big release by some standards but by our standards this is a huge release it took six weeks to prepare this release and it has 77 commits a bunch of changed lines there's only two people involved in this release so that's a good that's a pretty good metric this is a small release six minutes from the commit was was made to the production only one commit and only one one person in this release so the idea is that if you make small releases it's much easier to figure out who broke stuff because few people are usually involved and what happens is that if you have one one developer release and you find yourself in this scenario where there's a release that's suddenly causing us you can go in and and see immediately who knows how to fix this besides that there's a bunch of good reasons why you should be doing small releases for example developers love to put stuff in production it's a great feeling when you finally put things into production so you'll have happy developers if you do small releases but there's it's a huge topic and I encourage you to go on and investigate even more so you ship it you fixed it you build it you ship it whereas where I like to say from from Amazon you build it you run it which is sort of a relation of that and running it here could mean a lot of things we usually try to make sure we have to run as few things as possible ourselves so we like to buy services so other people will run it for us but still you know you get the you get the point you're responsible for the code you write okay now to something a little bit different do you know this person just let me know what I should build and I'll build it and a variation of that is we know how systems work if we're really good at our job we also know our users users think so this is an example again this is Benny he caught this quickly he's a great guy there's a nice nice spec here we're changing how timestamps look in our products and it's picked up pretty rigorously what it should what it should look like now there's this thing I've highlighted where it says if the time is more than a year ago it should include the year as well and that's two ways you can interpret this if it's more than a year ago from the time it should include the year or if it's the same year that should not include the year you know what I mean so it's either 365 days ago or just within the same year so you got this really extensive spec but he still went to ask the product guy what exactly do you mean by this and it turns out that the most obvious interpretation of this was not the one that the product guy meant so it's a way to what I'm getting at is that developers shouldn't just be these code monkeys who get specs throw at them then start to start to code right developers smart people we usually have a good idea about how things work so why should we just stop at dev and ops it's great that we're trying to break down the silos between the development department at the ops department but why not break down some more silos so also break down the silos between the developers and product development or the product team and break down the the silos between the development developers and the customer support team and you can probably imagine a way you can go if the developers have more insights into what's going on in the organization in general the kinds of protocols are coming in what are the thoughts from the product development team on how things are going to look in the future actually that's it so in summary devops new owner maybe there's a lot of good little good ideas if you can increase transparency in your development team you'll have better accountability and in the end you'll have better code and everybody will be able to sleep more which is great you can use to increase transparency and affect the culture in your team and you should try to break down silos not just between development and operations but between many of the departments in the organization that leads to better products and better solutions that's it some of this was slightly maybe controversial I'd love to discuss it with you guys girls I'll be right there so yeah come talk to me