Back to the channels

#java

14:24 Square2 We're a smallish shop with several (20ish) applications built on a common platform. The number of applications x 4 environments (dev, test, stage, prod) makes for a lot of extra work and we try to find ways to reduce that burden / cost.
14:27 Para Merge test and stage environment.
14:27 Para IaC wise the only difference between stage and prod should be in autoscalings being set to minimum.
14:27 Para and backups etc.
14:42 dreamreal Why would that lower the amount of work, though?
14:42 Para One less env and forcing less variations in configuration.
14:42 dreamreal Sounds to me like the plan should be to figure out what those deployment processes are and automate them, with triggers if possible... and I'd say stage and prod should be as close to the same as possible, personally
14:43 Para It does force engineering practices as well which allow for less surprises. It's not entirely a solution in the sens that it'd be a direct reduction in everything, but that's kinda the point - make decisions and settle to them.
15:55 Square I feel/suspect we're having too many manual steps in our deployment processees too.
15:55 Square Thanks for your feedback Para and dreamreal.
16:02 ernimril Square, if you have more than one step ("push the one and only button") then you have many cases to fuck up the deployment, and you are doing it wrong! (read that as: you have room to improve :-)
16:04 Square ernimril, we have that for dev environments. For the other environments I suspect it's more manual.
16:05 ernimril Square, odd to have it easier in dev, that is where you want to mess things up every now and then... But I guess you are like most others. Getting good deployment is hard
16:08 cheeser once code hits main here, it gets pushed to prod automatically with sleep gates between datacenters.
16:09 cheeser we manually trigger merges/deploys to staging branches but prod is always main branch
16:10 Para That's a strategy which works until first major production catastrophy requiring rollback :)
16:24 cheeser we can rollback to a prior deploy with the click of a button.
16:24 cheeser we're not fucking around here. ;)
16:25 cheeser hell, we can go 5 deploys back. or 17.
16:25 ernimril with one click?
16:25 Para How do you deal with temporal desync in integrations?
16:25 cheeser well, it's more like 3 because there are confirmations and shit. but it's painless.
16:26 cheeser depends on what you mean by "temporal desync in integrations"
16:26 Para Most systems are built with now==truth, and everything always following the lead.
16:26 Para So if one part rolls back, it affect everything which may mutate over time from database indices to order of events and whatever else; lots of exciting things can go all wonky.
16:27 cheeser the truth is whatever hash is defined as the truth.
16:27 Para It's not just "id x doesn't work anymore", but "x is now a cat toy instead of a dog"
16:34 cheeser ~make sense
16:34 javabot make: *** No rule to make target `sense'. Stop.
18:11 Tenchi sheesh sonatypes having a really rough time this week
18:13 Para a what now
18:57 Bombe Huh… I remember some time ago reading something about certbot being able/getting the ability to allow a specific certbot instance, identified in a DNS entry for a domain, to generate certificates for that domain, but I can’t find anything about it now. Did I hallucinate?
18:58 Para Maybe, but I also posted that link.
18:58 Para https://letsencrypt.org/2026/02/18/dns-persist-01.html
18:59 javabot Para's title: "DNS-PERSIST-01: A New Model for DNS-based Challenge Validation - Let's Encrypt"
18:59 nevet DNS-PERSIST-01: A New Model for DNS-based Challenge Validation
18:59 Para And subsequently multiple people pinged dreamreal about that as a few days earlier he had mentioned that he'd really like that feature.
19:00 Bombe Ah, thank you very much.