How can Ops make Dev happy by using Azure DevOps?

Slides from a talk I gave at IT Pro User Group Križevci, Croatia.
The idea of the talk was to bring sys admins up to speed with how can they automate their processes both on-premise and in the cloud.

Transcript

1. How can Ops make Dev happy by using Azure DevOps? Ivan Čuljak
2. 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
3. Disclaimer This talk is heavily opinionated and biased :)
4. Sysadmin role evolution 4 IT Operations 4 DevOps 4 No Ops
5. 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
6. 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
7. Why are there conflicts between Dev and Ops? 4 First of all, no one likes additional work 4 Devs blacklist 4 Ops whitelist
8. 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 :)
9. 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
10. Demo time <3
11. 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"
12. Demo time <3
13. 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
14. Demo time <3
15. Environments 4 How many is enough? 4 How many is too many? 4 What about their lifespan?
16. Demo time <3
17. 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
18. Demo time <3
19. Scripts, scripts, and yet more scripts...
20. Infrastructure as Code [IaC]
21. Next step - Pulumi?
22. Demo time <3
23. Continuous Delivery vs Continuous Deployment 4 Deployment deploys 4 Delivery awaits for approval before deploying 4 Combine them
24. "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
25. Demo time <3
26. 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
27. Demo time <3
28. 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
29. 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
30. 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
31. 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
32. Demo time <3
33. 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
34. 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
35. Demo time <3
36. 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
37. Demo time <3
38. 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
39. Demo time <3
40. 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
41. 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?
42. Freestyle Demo time <3
43. Thank you <3 Any questions? ivan@culjak.xyz / @CuljakIvan