lapser

> Setting up GHA is still a lot of "commit and hope for the best". I've resorted to having a sandbox repo just for experimentation/testing so that I don't overly pollute repos that I actually care about. It would be great to get more instrumentation to see what is going on.

There is act[0] which aims to let you run github actions locally via Docker. It isn't perfect but it does a decent job at it, and for the most part your pipeline can be run locally.

After MS bought GH, I had hopes that they would build a tool to run action locally, but nothing yet.

[0] https://github.com/nektos/act

I mentioned in my other comment that the direnv plugin aims to resolve this. Personally I didn't get it working but I haven't been determined enough. It has been working for others.

Seems the direnv plugin aims to resolve, but I struggled to get it working. 200ms for hasn't been a huge issue (yet), but not having the proper paths set up has been. Using shims isn't the greats experience (something direnv plugin also aims to address).

> asdf is not a replacement for pyenv, rbenv, goenv and nvm, it's yet another abstraction on top of them

No, asdf is a replacement for them. It's not an abstraction on top of them. It uses its own plugin system, and everything is written purely in bash. Everything gets installed in `~/.asdf/installs`

They've probably been eating up the Visa/MC cross border payment increases until now, and now they're starting to charge for that too.

Brexit keeps on giving.

Snark aside, this will likely just be pushed forward to customers sadly. Combined with the ever increasing prices in the UK, this is will only exacerbate the issues.

What's really interesting is how cheap it is being sold for. The current figure being given is "around" £1 billion, which seems like low ball offer for the third biggest broadcasting company in the UK.

To be fair, it's not up to the BBC to criticise. They should be reporting impartially and let the folks make up their mind.

A friend of mine working for a rival neobank was telling me about a tiny piece of the whole thing that used 5 microservices to achieve it. This was a security related piece, and when I pressed him why something as simple as what he was describing needed 5 services, he went somewhat into detail, and it sort of made sense.

I can imagine 2000 microservices being rather low for a bank.

Right. Hence why I said:

> That is honestly near impossible.

Point is, staging environment is there to increase the confidence that what you are deploying won't fail. Removing that is doable, but I wouldn't recommend it.

Disclaimer: I worked for a major feature flagging company, but these opinions are my own.

This article makes a lot of valid points regarding staging environments, but their reasoning to not use them is dubious. None of their reasons are good enough to take staging environments out of the equation.

I'd be willing to be that the likelihood of anyone merging code that isn't ready to go live is close to zero. You still need to validate the code. Their branching strategy is (in my opinion) the ideal branching strategy, but again, that isn't good enough to take staging away.

Using feature flags is probably the only reason they give that comes to close to being okay with getting rid of staging, but even then, you can't always be sure that the code you've built works as expected. So you still need a staging environment to validate some things.

Having hands-on deployments should always be happening anyway. It's not a reason to not have a staging environment.

If you truly want to get rid of your a staging environment the minimum that you need to feature flagging of _everything_, and I do mean everything. That is honestly near impossible. You also need live preview environments for each PR/branch. This somewhat eliminates the need for a staging because reviewers can test the changes on a live environment. These two things still aren't good enough reason to get rid of your staging environment. There is still many things that can go wrong.

The reason we have layered deployment systems (CI, staging etc) is to increase confidence that your deployment will be good. You can never be 100% sure. But I'll bet you, removing a staging environment lowers that confidence further.

Having said all of this, if it works for you, then great. But the reasons I've read on this post, don't feel good enough to me to get rid of any staging environments.