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.
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
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
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 :)
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
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"
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
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
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
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
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
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
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
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
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
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
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
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
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?
culjakivan
masuda220
rinchsan
heronshoes
ancaghenade
sagawa23
ufoo68
little_rubyist
ayaka1230
munetoshi
fornewid
ojun9
konokenj
danielanewman
myddelton
shpigford
revolveconf
zakiwarfel
mongodb
tammielis
lara
keithpitt
brettharned
zenorocha