* CodeGeek!~codegeek@about/java/CodeGeek changed the topic to: Welcome! || Read Channel Rules at https://javachannel.org/ before participating. || Paste limit is two lines; ~pastebin lists options. || No applets, please. || Minecraft, Android, and Javascript all have their own channel. || You are being logged.
* dreamreal joined #java
* dob1_ joined #java
* Square2 joined #java
* hwpplayer1 joined #java
* magla joined #java
Square2We'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.
ParaMerge test and stage environment.
ParaIaC wise the only difference between stage and prod should be in autoscalings being set to minimum.
Paraand backups etc.
* phlox joined #java
* ztevoz joined #java
* phlox joined #java
dreamrealWhy would that lower the amount of work, though?
ParaOne less env and forcing less variations in configuration.
dreamrealSounds 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
ParaIt 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.
* Square joined #java
* xa0s joined #java
SquareI feel/suspect we're having too many manual steps in our deployment processees too.
SquareThanks for your feedback Para and dreamreal.
* kelt0m joined #java
ernimrilSquare, 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 :-)
* MonsterAbyss joined #java
Squareernimril, we have that for dev environments. For the other environments I suspect it's more manual.
ernimrilSquare, 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
cheeseronce code hits main here, it gets pushed to prod automatically with sleep gates between datacenters.
cheeserwe manually trigger merges/deploys to staging branches but prod is always main branch
ParaThat's a strategy which works until first major production catastrophy requiring rollback :)
* ferdna joined #java
cheeserwe can rollback to a prior deploy with the click of a button.
cheeserwe're not fucking around here. ;)
cheeserhell, we can go 5 deploys back. or 17.
ernimrilwith one click?
ParaHow do you deal with temporal desync in integrations?
cheeserwell, it's more like 3 because there are confirmations and shit. but it's painless.
cheeserdepends on what you mean by "temporal desync in integrations"
ParaMost systems are built with now==truth, and everything always following the lead.
ParaSo 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.
cheeserthe truth is whatever hash is defined as the truth.
ParaIt's not just "id x doesn't work anymore", but "x is now a cat toy instead of a dog"
cheeser~make sense
javabotmake: *** No rule to make target `sense'. Stop.
* mwnaylor joined #java
* hwpplayer1 joined #java
* travolta007 joined #java
* travolta1 joined #java
Tenchisheesh sonatypes having a really rough time this week
Paraa what now
BombeHuh… 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?