Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@Oktokolo I have seen this so often I can't even tell if this is a joke or not.
-
@sariel It isn't. It just needs some more initial setup but then you actually get less production-only bugs that way. No one likes doing the upfront work. But no one likes interrogating customers for actual issue information and debugging on production either. Fixing some of that sort of bugs before they reached production definitely made my life easier.
-
@Oktokolo the environments are imaged so they are the same environments from Dev to production.
At least in my setup, the differences between a production release and a pre-prod release is that pre-prot is going to QA for review or testing. Not everything that goes to QA will be going to production. There may be bug fixes, there may be feature enhancements that weren't met, etc.
That's why it's important for me to differentiate between a production and pre-prod release.
I just don't understand why Microsoft had to complicate things by adding two new options to what was already a perfectly functional feature. To add to that, you can't select both checkboxes. So they're functionally radio buttons, but they are check boxes with JavaScript code that makes them function as radio buttons. With added confusion that you can deselect them and not have anything selected. When would I ever make a release that was not either a pre-prod or prod release?
Never. I should never do that. -
@sariel So you want to know, why feature creep exists?
-
Mostly because pipelines are ever changing.
It's not about feature creep in this case though... (feature creep exists and is a problem in many other cases indeed)
It's kinda obvious, but MS adapts it's toolings primarily to their own needs and their own vision.
A pipeline with simple releases might be a nice choice for the small regular team, but for _large_ mission critical stuff most regular easy pipelines would spell disaster.
I'd guess (not an MS guy) that ephemeral release is basically the test run if the release pipeline works as intended - a dry run.
Doing a full release cycle is unnecessary and potentially harmful in this case (e.g. bumping versions and creating unnecessary spam in reporting), so you just want to to have a "release that doesn't exist" aka ephemeral.
The aCalendar app let's you choose vibration pattern, it's one of the better settings I've seen.
I think I just realized what my biggest gripe about our career paths that I hate the most.
This is something that has worsened over time, especially the last 2 to 3 years.
As developers, we have far too many options. Some of the most powerful apps are written with languages that have hard, and I mean HARD, guardrails in place. If the app is written in a language that does not meet this criteria usually a framework has been used to install those guardrails.
We just get our minds so wrapped around the possibilities and the opportunities in the software, that we just can't focus on the end result. We're like puppies that are excited about something and we just piss all over everything.
In my career I have met far too many developers that don't have the capacity and mental fortitude to take control of their actions. Because of this I think the only way for us to stop this corruption, that I feel we are nurturing, the solutions/services that we use need to push back on us and install those guardrails for us.
All this came from a change that Microsoft put in place that seems well intended, but introduces yet another choice and a multitude of opinions in how you release code.
It used to be a simple check box. If it was checked it was pre-release, if it was unchecked it was a production release. That's it. On or off. The simplest choice you ever needed to make on a release.
Now though, there are two check boxes. One for a pre-release and one for a latest release. You can also not check either for some "ephemeral" release? So now something as easy as on or off has been made into a difficult decision on how this works within my pipeline. Now every time I make a release I have to ask myself, "which one do I check?"
I shouldn't need to spend more than a second to identify a path forward on simple shit like this, but here we are with a third choice.
Can we just stop overcomplicating shit?
rant
options
choices