> Here's how an iteration looks like in the cloud today: I make a change to my code; then I need to compile it; deploy it to my test account; find my way around

> Here's how an iteration looks like in the cloud today: I make a change to my code; then I need to compile it; deploy it to my test account; find my way around the management console to actually trigger it; I’m not an Ops specialist, but once I got tired of doing that (which was the second time), I spent time figuring out how to automate it. Don’t get me wrong, I naively think that the “network” part of working with the cloud ought to be easier, but aside from networking, basically everything we do in azure is now automated. And the networking part is slowly getting there as I learn more and more about it. I do agree that it sort of makes no sense that everyone has to spend time setting the automation up. Like why doesn’t Azure come with CI/CD templates? I’m sure a lot of the automation we’ve written to make an accepted pull request deploy into different app deployment slots (and the first time spin up an app with TSL on a VNET with Private Endpoints on the correct subnets) looks almost exactly like yours does. So why did we both have to write it from scratch? But beyond that, I’m not so sure what the author is talking about. I recall when we used Windows servers instead, and maybe the author didn’t have to work with their settings or making sure they had the correct components in place, but as I recall the experience wasn’t too dissimilar to what working in Azure is, expect for the fact that we developers are also working into the networking part or it, which we weren’t when that was solely an Ops thing. The actual setup of our Networking is still very much an Ops thing, but I still have to “chose” the VNETs and Subnets my Opes people tell me to use, which wasn’t really part of the process when we were self-hosting. Anyway, I guess the only thing I really agree with is the speed. It can be very slow, depending on your setup, but isn’r that why we use local containers and temporary “dev” deployment slots? When I push code to a dev branch, it automatically gets build and deployed to a branch slot, it does take time, but I rarely have to actually wait for it. Partly because I can just up my own container and see the same thing, but also because the actual manual testing is typically done by the people who use the applications, and they’ll never see the “downtime” because it spins up automatically and replaces what they load when it’s ready and the old deployment dies. Notifying them can be as simple as having your CI pipeline send them an email with “app is updated, in relation to work item please go see if you’re satisfied” or whatever. It is difficult, but then it frankly always was, and I do think it’s maybe better in the hands of actual Ops people, but since those can be sort of hard to find, it’s not too uncommon to expect “you build it, you run it” to be part of the modern developer role.