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. 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
  2. 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
  3. 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
  4. Why are there conflicts between Dev and Ops? 4 First

    of all, no one likes additional work 4 Devs blacklist 4 Ops whitelist
  5. 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 :)
  6. 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
  7. 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"
  8. 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
  9. Environments 4 How many is enough? 4 How many is

    too many? 4 What about their lifespan?
  10. 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
  11. Continuous Delivery vs Continuous Deployment 4 Deployment deploys 4 Delivery

    awaits for approval before deploying 4 Combine them
  12. "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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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?