Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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.

Ivan Čuljak

January 19, 2019
Tweet

More Decks by Ivan Čuljak

Other Decks in Programming

Transcript

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

    View full-size slide

  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

    View full-size slide

  3. Disclaimer
    This talk is heavily opinionated and biased :)

    View full-size slide

  4. Sysadmin role evolution
    4 IT Operations
    4 DevOps
    4 No Ops

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

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

    View full-size slide

  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 :)

    View full-size slide

  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

    View full-size slide

  10. Demo time <3

    View full-size slide

  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"

    View full-size slide

  12. Demo time <3

    View full-size slide

  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

    View full-size slide

  14. Demo time <3

    View full-size slide

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

    View full-size slide

  16. Demo time <3

    View full-size slide

  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

    View full-size slide

  18. Demo time <3

    View full-size slide

  19. Scripts, scripts, and yet
    more scripts...

    View full-size slide

  20. Infrastructure as Code
    [IaC]

    View full-size slide

  21. Next step - Pulumi?

    View full-size slide

  22. Demo time <3

    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  25. Demo time <3

    View full-size slide

  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

    View full-size slide

  27. Demo time <3

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  32. Demo time <3

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  35. Demo time <3

    View full-size slide

  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

    View full-size slide

  37. Demo time <3

    View full-size slide

  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

    View full-size slide

  39. Demo time <3

    View full-size slide

  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

    View full-size slide

  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?

    View full-size slide

  42. Freestyle
    Demo time <3

    View full-size slide

  43. Thank you <3
    Any questions?
    [email protected] / @CuljakIvan

    View full-size slide