How can Ops make Dev happy by using Azure DevOps?

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.

402476a4ba88f9ef948a17ee96d1f360?s=128

Ivan Čuljak

January 19, 2019
Tweet

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