How can Ops make Dev happy by using Azure DevOps?

Slide 1

Slide 1 text

How can Ops make Dev happy by using Azure DevOps? Ivan Čuljak

Slide 2

Slide 2 text

Who am I? 4 Software engineer/architect/consultant 4 Loves greenfield projects 4 Makes a living by salvaging wrecks 4 Facebook troll, Twitter adjutant @CuljakIvan 4 Hopefully a prolific blogger (starting this month) @ www.culjak.xyz

Slide 3

Slide 3 text

Disclaimer This talk is heavily opinionated and biased :)

Slide 4

Slide 4 text

Sysadmin role evolution 4 IT Operations 4 DevOps 4 No Ops

Slide 5

Slide 5 text

DevOps 4 DevOps consultant is a thing 4 DevOps engineer ISN'T 4 DevOps is a philosophy, a project/company-wide culture, and not only CI + CD

Slide 6

Slide 6 text

NoOps 4 Servers were pets, and nowadays are cattle 4 NoOps is "a thing" 4 NoOps is misinterpreted 4 NoOps isn't an alternative to DevOps, it just means less stupid work for Ops, and hence more time for them to focus on real matters

Slide 7

Slide 7 text

Why are there conflicts between Dev and Ops? 4 First of all, no one likes additional work 4 Devs blacklist 4 Ops whitelist

Slide 8

Slide 8 text

Types of companies that develop software 4 Companies with software aiding their workflow 4 Companies producing software as their primary product 4 Software development agencies 4 Startups :)

Slide 9

Slide 9 text

git workflows 4 DO NOT intimidate Devs to push often 4 You can squash commits in a feature branch before merging into develop 4 You can let them fork the repo, and make PRs into the main one 4 You can do whatever, as long as the code is pushed often

Slide 10

Slide 10 text

Demo time <3

Slide 11

Slide 11 text

Build process 4 Devs should be able to setup build definitions for non-production environments 4 Ops can take those build definitions and set them up for production environments 4 Ops... This is not the last line of defense, so ease up 4 But... keep in mind that secure files and secrets are available here in "plain text"

Slide 12

Slide 12 text

Demo time <3

Slide 13

Slide 13 text

Keys, certificates, etc 4 The repo should contain everything needed to build a debug/develop version without any additional steps 4 Don't keep your secrets in Dropbox/Google Drive/ FTP Servers and fetch them with obscure scripts/ processes 4 Keep them in Azure DevOps, and they'll be safe

Slide 14

Slide 14 text

Demo time <3

Slide 15

Slide 15 text

Environments 4 How many is enough? 4 How many is too many? 4 What about their lifespan?

Slide 16

Slide 16 text

Demo time <3

Slide 17

Slide 17 text

Release process 4 Walking into Ops territory 4 They can be triggered 4 On a build completed 4 On a PR 4 On a whim 4 Manually 4 You can even add manual interventions to pause

Slide 18

Slide 18 text

Demo time <3

Slide 19

Slide 19 text

Scripts, scripts, and yet more scripts...

Slide 20

Slide 20 text

Infrastructure as Code [IaC]

Slide 21

Slide 21 text

Next step - Pulumi?

Slide 22

Slide 22 text

Demo time <3

Slide 23

Slide 23 text

Continuous Delivery vs Continuous Deployment 4 Deployment deploys 4 Delivery awaits for approval before deploying 4 Combine them

Slide 24

Slide 24 text

"Blame" the approver 4 People tend to be jerks when granted anonymity 4 When there's a detailed log of approvals everyone tends to be more careful

Slide 25

Slide 25 text

Demo time <3

Slide 26

Slide 26 text

Use multi-stage releases and gates 4 Gates allow you to perform a programmatic task before proceeding with the release 4 Multi-stage releases promote a single build through the release pipeline if that's what you want/need

Slide 27

Slide 27 text

Demo time <3

Slide 28

Slide 28 text

Who owns what? 4 Legacy says that Devs provide builds, and Ops deploy them 4 Nowadays it's almost the same, although you should talk about it and find a best fit for your situation

Slide 29

Slide 29 text

How much oppression should Ops pose on Dev? 4 Dev expenses increase with increased oppression 4 You can't allow WWW (wild wild west) 4 But you should decrease as much as possible Devs dependency on Ops time

Slide 30

Slide 30 text

Shadow IT 4 CIO's say it hurts the security 4 CTO's say it improves innovation and speeds up the development 4 In my opinion there's nothing wrong with it as long as you make other people aware of it, and hence remove the "shadow" label

Slide 31

Slide 31 text

Monitoring and useful data 4 To prevent "it works on my machine" situations start monitoring 4 When you start monitoring SHARE that data with ALL Devs 4 Make it easy to use, easy to filter, and a reliable source

Slide 32

Slide 32 text

Demo time <3

Slide 33

Slide 33 text

Allowing your Devs to access non- production infrastructure 4 This is a no-brainer 4 Just ALLOW your Dev team to access non- production infrastructure and do whatever they want/need 4 The Dev team will take care of granting access to individual Devs

Slide 34

Slide 34 text

Allowing your Devs to access production infrastructure 4 By default Devs shouldn't have access to production infrastructure 4 By default Devs should have a way of being allowed to access production infrastructure in less than 10 minutes

Slide 35

Slide 35 text

Demo time <3

Slide 36

Slide 36 text

Ease your life with Logic Apps 4 Sure... you can write a script or some code, or a bunch of HTTP(S) calls 4 Or you can just click through a few wizards and improve your process in no time

Slide 37

Slide 37 text

Demo time <3

Slide 38

Slide 38 text

Versioning and tagging 4 Versioning requires a broad discussion 4 Who is increasing the version number 4 What's the structure of the version number 4 Release process might decline the release of the same version of something 4 Tagging git commits is a splendid way of showing what was released

Slide 39

Slide 39 text

Demo time <3

Slide 40

Slide 40 text

Containers 4 Not everyone's cup of tea 4 But it makes life easier (and more difficult) 4 You can share resources and save money 4 Another step in the NoOps direction

Slide 41

Slide 41 text

Rollback vs roll forward 4 Rollback can mess up your system when you've changed something like a DB during deployment 4 Roll forward is a safer bet, but it takes more time 4 The main question is - why did you let this be a concern on a production environment?