Hacker Newsnew | past | comments | ask | show | jobs | submit | dunreith's commentslogin

While I'm glad that I can read what someone is talking about on X/Twitter without giving away my privacy, I'd much rather see a trend of moving off of the platform altogether (or at least posting to multiple platforms to make the transition off of X more mainstream palatable)


I'd rather be able to see the updates on X. Unless you count chat apps like LINE, it's the only social network I really use.


All of these layoff announcements, regardless of high profits or otherwise, are quickly eroding any sense of loyalty I have toward my company - and it should do the same for all of the tech workers out there.

You have to do what's best for you and those that you support. Do not accept anything less; your company certainly will not.

Until it becomes apparent that the constant turnover of tech workers hits the bottom line, these companies will do less than nothing to make things better for their employees.


At the very least, it would be nice to have an easy-to-consume standard high-level infographic. Take the "Nutritional Information" table that's been standardized on the side of most American foodstuffs. If we could get Terms of Service with a table at the top with the most important info standardized, it would go a long way.


This is coming for IoT "cybersecurity", e.g. routers.


the Secure Information Technology Hub™?


It's honestly not a bad idea, just a bad implementation. I use shadow.tech to achieve this and they do it well - instead of giving you game-specific VMs (or whatever Stadia is), they just give you a gaming VM with Windows and you install your own Steam / Epic / GOG / XBLive whatever on it.


I suppose there's an even larger scale that the law of large numbers applies and you can more reasonably filter out "the noise"


> incorrect thinking that the way to reduce bad outcomes from software is to change it less often

This. So much this. The way you turn a bug into a "bad outcome" is to make it slower to change. If you can deploy quickly and easily, you can fix any software issue before it becomes a big problem.


I'm currently at a Fortune 500 and we're doing CD for our eCommerce site. I count myself very lucky to have been involved in the process.


I led our team to a full CI/CD (Deployment) and while it felt really counterintuitive to move quickly and have the occasional bug show for our customers, the speed at which we could fix the bug has vastly offset it. Introduce a bug? Fix it same day. Introduce a breaking change? Rollback and fix it. No biggie.


Have you had data corruptions because of the bugs that could not be rolled back quickly?


This is something that I would be concerned with. If you have a multiplayer game like Runescape, and have CD on the servers, introducing a bug that causes corrupted data may be able to be patched quickly, but in that hour a lot of players could have been given items that they shouldn't have had. Then you have to distinguish which got the items properly and which didn't, and have processes set up to make those kinds of admin changes to the prod db


Goes without saying that you deploy to an identical test environment that duplicates the entire stack, with realistic test data. Automated testing protects from regressions, manual testing for the rest.

crickets

One (QA) can always dream!


Some stacks are quite complicated, involve various kinds of mobile devices with different app versions, custom hardware, offline functionality. It's just that not all systems are easy to replicate. But that's another problem.


Fortunately not, but we're deploying the frontend for an eCommerce site so we don't deal with (much) data can could be corrupted.


Depends on which CD you're talking about. Continuous Delivery: artifacts get delivered and are ready to deploy when someone is ready to do it. Continuous Deployment: built artifacts get deployed automatically.


The article talks about Continuous Deployment.

IMO Continuous Delivery is kind of a nothingburger vague process term that lots of people can (and do) talk themselves into saying/thinking they are doing. That's kind of the theme of this blog post BTW. Continuous Deployment is the actual indisputable thing (you either automatically deploy new commits in mainline or you don't) that gives you the real benefits but which lots of orgs aren't yet doing.


Can anyone besides web get away with continuous deployment? IOS already wants to update too often, I don't want CD to my phones or probably my desktop or server OS. Especially in enterprise. And in cases where hardware hasn't even been released it is impossible, much less undesirable. It makes sense to talk about continuous delevery amd how to squeeze out extrabenefits from that model. I suspect it is mainly about automating as much as possible between CDel and CDep but I have obly ever worked in CDel on hardware that doesn't even exist yet.


Things like classic Ubuntu get continuously updated with security fixes, and with livepatch, even kernel gets updated without a reboot.

Even their process is very much like true CI/CD but packages only get into "proposed" archive (still accessible to the public) without further human vetting (I mean, a code review is human vetting too).

I personally want my desktop/server apps to automatically update according to traditional LTS rules (no breaking changes, just bugfixes).


> As long as you have manual processes, it's not continuous.

Agreed. I'm all-in for Continuous Deployment. Continuous Delivery is a half-measure at best.


> when someone is ready to do it

That's not automated. CD (however you (re)define it) is about automation and removing people from the loop.

As long as you have manual processes, it's not continuous.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: