We have plenty of CI that launches and tests our shit. Before any prod deploy, I always take 5-15 min to click around before running the deploy job.
Like... how often are you deploying if you can't take the 5 min to do that? If you're a dev you probably already have the environment up and running.
I get it, I'm not saying this is something everyone does or should be doing, I think it's just one of many things that underscores how messed up US cops are.
Fair enough.. you guys have a pretty severe cop problem :/
I'm not very familiar with the US, but I've driven borrowed cars through several countries over here in Europe without any other documentation that "Trust me bro, I'm borrowing this car" on plenty of occasions. In that regard it seems pretty strange that you would need more documentation to bring a car across state lines in the US.
Also, it's pretty common here in Europe for people living near the border to shop on the other side (groceries or whatever). I can't imagine it's any less common in the US for people to have nearby shops in the next state.
"I'm going to head over to the store"
"One sec, let me just write you a note saying that I allowed you to borrow my car"
An interaction dreamed up by the utterly deranged.
Just to be clear, I'm not criticising your explanation here. I just think it's kind of absurd how US cops seem to act. Just the idea that you could be suspected of stealing a car if you don't own the car you're driving just seems crazy to me.
Wat? That makes no sense?
"This car is registered to someone else."
"Yes, I'm borrowing it"
"..."
"You must be a criminal?"
Pavement? Path? Footpath? Biking path?
In my language we use the literal translation of "road" also for paved surfaces not meant for cars. We use "walking-road" to emphasise the fact when it's in a place where it might be confused for a car-road. We also have "bike-roads" that are paved/marked like a road but dedicated for bikes only.
I think I just immediately associated "trail" with "hiking trail" or "bike trail" which I associate with more rugged terrain and not paved paths.
This appears to be a cultural/language thing (I’m not from the Anglosphere), I just didn’t have any concept of a “paved trail”, it immediately seemed like an oxymoron to me.
I've come across trails with priority markings, but in my country most trails don't really have any kind of marked "trail head" at all (apart from the ones very near major cities) like you commonly have in the US.
This appears to be a cultural/language thing (I'm not from the Anglosphere), I just didn't have any concept of a "paved trail", it immediately seemed like an oxymoron to me.
Pavement markings
WTH kind of "trails" do you have over there? I thought we were talking about like trails in the woods/mountains, maybe a gravel road at best..?
I'll only ever say "on your " if I'm moving significantly faster than a person (e.g. I'm biking or running), there's little space, and I have some reason to think they may not be aware that I'm coming up behind them and could move unexpectedly to the side.
100 % agree. The purpose of post-merge testing is to have an extra layer of security to prevent bugs from leaking out into prod, not that you should ever consciously merge something that is not deployable. In my experience, testing on a feature before merge tends to focus on what you expect could be broken/bugged. The post-merge/pre-deploy testing exists to catch cross-feature bugs and in general find the stuff you never expected to break in the first place. Basically: Test your feature thoroughly before merging, then test the whole app without focusing on any particular feature before deploying.
There's two sides to this: We have auto-deploy on merge to a staging environment, and a manual deploy to prod. That lets us keep a high rate of development, while we continuously test / use the staging environment internally. The manual prod deploy doesn't cost us any extra time, since it essentially consists of clicking the "deploy to prod" button. The advantage is that we typically get a couple days of delay from something hitting staging before it goes to prod, which has let us catch a couple embarrassing bugs before they hit customers. When that happens, we can improve our testing regime without the bug having ever hit prod in the first place.
So basically, before I click the "deploy to prod" button, I spend maybe 15 minutes clicking around in the staging environment to double-check that all is good, then I double-check that we don't have any known blocking bugs (we just use a dedicated issue-tag for "I found a deploy-blocker on staging, don't deploy to prod before it's fixed.")