Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Continuous Delivery Test

sourceless.org

Post reply on HN
Print view View original

61–70 of 72 posts

Re: The Continuous Delivery Test

#61

Post by KronisLV »

8n4vidtmkvmk wrote: post #31
ChrisMarshallNY wrote: post #16

Earlier quoted context omitted.

The whole idea of "Continuous Delivery" is not always one that meshes well with some shrink-wrap workflows. I worked for hardware manufacturers, for most of my career, and software was always just a "sidekick" to The Main Show. We just got the "Supporting Actor" nods. I'd say that 90% of HN seems to be Web/SaaS (and, these days, crypto), which is an excellent workflow; just not the one I do. Nowadays, I have some int…

i work on a very large team and solo for my side hustle. love working solo, no red tape to fight. no waiting 24 to 48 hours for a teammate to review my code per iteration and up to 24 more for it to deploy. just signed 2 contractors on for my solo project though and its really messing up my process. all the overhead is so high I'm not even sure it's worth it even if they were free.

> no waiting 24 to 48 hours for a teammate to review my code per iteration and up to 24 more for it to deploy

This probably depends on the team and practices that are used within it.

Most code changes in my current team are reviewed within an approximately an hour, deployments are a bit more tricky, especially if you have external clients with their own environments and deployment procedures.

Honestly, CI/CD cycles for the internal dev/test environments take anywhere from 5-20 minutes (with the heavier tests being run separately) and the technical aspects of delivering software (build, test, package, scan, generate docs, send) take around another 10-20 minutes.

It's usually when you have to deal with manual procedures and people that it all slows down.

So, it can be really good to automate as much as you can: code style and warning checks, code coverage checks, dependency date checks, dependency CVE checks, unit tests, integration tests, performance tests, packaging and storing build artifacts, redeployments to whatever environments are permissible (usually automated to dev/test, manual approval against prod).

Re: The Continuous Delivery Test

#62

Post by KronisLV »

maccard wrote: post #36
kqr wrote: post #12

Earlier quoted context omitted.

Really? I challenge you to find any items other than 7 and perhaps 8 that don't apply to the types of development you mention. Essentially the only thing that's different with the types of development you mention is that "final deployment to production" looks different, as it usually involves more or less physically transporting artifacts to your customer. But the rest is just the same. You should be doing trunk-base…

Using distributed version control isn't applicable to most people working in games. 9) is also debatable - requiring someone to clone the entire application to make an infra change to a testing environment. Adding tickets to commit messages isn't necessarily a requirement - some work (at least in my area) is prototypey and maybe ill defined (the task might be to define it). Being able to deploy from your own machine…

> Using distributed version control isn't applicable to most people working in games.

Are you sure about this? I mean, code absolutely should be versioned and if you can afford the storage, you should also version all of your assets, like models and audio.

Even Git has specialized functionality for storing binary assets: https://git-lfs.github.com/

Unity also seems to be pushing their Plastic SCM as well for this more specialized use case: https://www.plasticscm.com/

Either way, not using version control for any collaborative project is just asking for issues.

Not using distributed version control in particular might just make things more annoying, as anyone who has ever worked with SVN might attest to.

Re: The Continuous Delivery Test

#63

Post by 8n4vidtmkvmk »

KronisLV wrote: post #61
8n4vidtmkvmk wrote: post #31

Earlier quoted context omitted.

i work on a very large team and solo for my side hustle. love working solo, no red tape to fight. no waiting 24 to 48 hours for a teammate to review my code per iteration and up to 24 more for it to deploy. just signed 2 contractors on for my solo project though and its really messing up my process. all the overhead is so high I'm not even sure it's worth it even if they were free.

> no waiting 24 to 48 hours for a teammate to review my code per iteration and up to 24 more for it to deploy This probably depends on the team and practices that are used within it. Most code changes in my current team are reviewed within an approximately an hour, deployments are a bit more tricky, especially if you have external clients with their own environments and deployment procedures. Honestly, CI/CD cycles f…

Ya.. my company does all of that. It's just the people process that makes everything slow. Well, mostly the people process. Having millions of dependencies doesn't help with build and test times either. Usually up to 20 min to run something.

Re: The Continuous Delivery Test

#64

Post by 8n4vidtmkvmk »

harrylu wrote: post #53
wahnfrieden wrote: post #41

Earlier quoted context omitted.

there are perhaps interesting options with bringing in partner-level labor instead of buying someone's time-in-seat and the relative personal investment involved in each the big point glossed over is that wage labor, where the value they produce is taken from them, isn't a great incentive for great work. that's imo a far bigger issue than fundamental challenges with collaborating, and why so many managers need to con…

I have been thinking about _how_ to build good (and stable) software a lot in last 10 years. Tried many approaches and verified them one by one. In my experience this is the ultimate fix. It may not work for big tech companies, but for most projects, it is much better to choose this approach. Collaborative efforts to maximize good results, and predictable gains for each participators.

What's the ultimate fix?

Re: The Continuous Delivery Test

#65

Post by maccard »

KronisLV wrote: post #62
maccard wrote: post #36

Earlier quoted context omitted.

Using distributed version control isn't applicable to most people working in games. 9) is also debatable - requiring someone to clone the entire application to make an infra change to a testing environment. Adding tickets to commit messages isn't necessarily a requirement - some work (at least in my area) is prototypey and maybe ill defined (the task might be to define it). Being able to deploy from your own machine…

> Using distributed version control isn't applicable to most people working in games. Are you sure about this? I mean, code absolutely should be versioned and if you can afford the storage, you should also version all of your assets, like models and audio. Even Git has specialized functionality for storing binary assets: https://git-lfs.github.com/ Unity also seems to be pushing their Plastic SCM as well for this mor…

> Are you sure about this? I mean, code absolutely should be versioned and if you can afford the storage, you should also version all of your assets, like models and audio.

Yes, and I never said you shouldn't use version control , simply that distributed version control isn't necessarily applicable (which is what the claim is).

> Even Git has specialized functionality for storing binary assets: https://git-lfs.github.com/

Let's be honest, LFS is duct tape on a pig. It doesn't support SSH, for one. Mirroring a repository is mired with landmines, and probably most importantly it breaks the decentralised model of git by centralising the storage of your binary data.

> Either way, not using version control for any collaborative project is just asking for issues.

Which is not what I said, at all. The article says _distributed_ version control.

> Not using distributed version control in particular might just make things more annoying, as anyone who has ever worked with SVN might attest to.

By distributed version control you mean git here, right? The advantage of git isn't it's technical merit, or the advantages of DVCS (particularly if you're using something like LFS which turns it into a centralized VCS). The advantage of git is that it's well supported in many tools (ci, merge bits, code review, deployment, package managers). Frankly, my experience is the complexity brought on by git (which is quite a few years using it along side perforce and more recently plastic) often outweighs the benefits over something like perforce, particularly on large repos.

Re: The Continuous Delivery Test

#66

Post by KronisLV »

8n4vidtmkvmk wrote: post #63
KronisLV wrote: post #61

Earlier quoted context omitted.

> no waiting 24 to 48 hours for a teammate to review my code per iteration and up to 24 more for it to deploy This probably depends on the team and practices that are used within it. Most code changes in my current team are reviewed within an approximately an hour, deployments are a bit more tricky, especially if you have external clients with their own environments and deployment procedures. Honestly, CI/CD cycles f…

Ya.. my company does all of that. It's just the people process that makes everything slow. Well, mostly the people process. Having millions of dependencies doesn't help with build and test times either. Usually up to 20 min to run something.

> Having millions of dependencies doesn't help with build and test times either. Usually up to 20 min to run something.

I feel that pain! Honestly working with monoliths and older and larger projects is very demotivating. Now, I'm not saying that you need to go full on microservices either, but working with a few smaller services instead of a single huge one has been a game changer in my experience!

I'm not sure I ever want to go back to the loop of changing some code and then having to wait minutes for the app to launch locally just so I can test something and realize that it's still wrong.

Re: The Continuous Delivery Test

#67

Post by etamponi »

ryanklee wrote: post #50
etamponi wrote: post #46

7. 7! This is by far the one that resonates with me the most. But for some reasons SREs think the opposite is true: the longest it takes to get to prod, the better. What a pain.

I'm an SRE and currently on a mission to get code into prod as fast and safely as possible. Instead of painting such a broad, generic negative picture, maybe articulate an actual position to argue against.

You are right -- I was referring specifically to SREs in FAANG, which enforce a mandate of maximum 1 deploy to prod per day -- in some case even 1 per week, or less.

To be honest, I think there is a threshold, perhaps expressed in terms of risk of losing money, at which it is more beneficial to delay deploys.

But applying the same deployment rules to a multi-billion-dollar revenue machine and to a smaller project with perhaps a few thousand weekly users is ridiculous.

Re: The Continuous Delivery Test

#68

Post by ChrisMarshallNY »

AlotOfReading wrote: post #58
ChrisMarshallNY wrote: post #56

Earlier quoted context omitted.

Well, hardware is a different world from software. I’ll bet that Tesla doesn’t do “sight unseen” updates. They probably wouldn’t be allowed to. They likely have huge batteries of tests that the software needs to pass (CI), but the actual release build and “sign-off” involves a human. Who will get their ass chewed off, if the update borks. But everything before that point, is 1000% better and more agile than most hard…

As a fellow embedded dev, I think that any system where you run a regular, meaningful risk of bricking with updates is a badly designed system. Other than that, no disagreement. CI is a cheap, fast first step in validation. It's not the stopping point.

Well, I don't do embedded anymore. I enjoyed it, but it can be nerve-wracking.

I write end-user application code, for Apple devices, in Swift. I really enjoy that.

I also do some backend stuff (in PHP). It's not my forte, and I like to avoid it, if possible, but I'm highly skeptical of a lot of backend stuff, these days, and like to know who I'm letting in the back door.

I'd like to do some Bluetooth stuff. I've written a bunch of BLE stuff (even given a class in it[0]), but I haven't found a venue that gives me an excuse (the Meshtastic stuff looks like it might be a good bet, though).

[0] https://github.com/ChrisMarshallNY/ITCB-master

Re: The Continuous Delivery Test

#69

Post by wahnfrieden »

8n4vidtmkvmk wrote: post #64
harrylu wrote: post #53

Earlier quoted context omitted.

I have been thinking about _how_ to build good (and stable) software a lot in last 10 years. Tried many approaches and verified them one by one. In my experience this is the ultimate fix. It may not work for big tech companies, but for most projects, it is much better to choose this approach. Collaborative efforts to maximize good results, and predictable gains for each participators.

What's the ultimate fix?

tbh this is a big weakness of the left (in terms of its marketing at least) that I'm trying to understand better. one idea is that whatever solutions we conceive of now, are constrained within the understanding we've gained living under capitalism/state power etc., and that we need to dismantle the current system incl exploitation/keeping the majority of peoples time/energy locked up in wage labor/systemic lack of freedom to disobey an order or to freely relocate/etc, before we can explore a wider range of solutions. But I get how this is unsatisfying, sounds like it leaves a vacuum for bad/regressive solutions to come in, but this is something I'm only starting to learn about.

That's why I appreciated the new Graeber/Wengrow, it finds a wealth of prev overlooked ways that humans have lived, post discovery of agriculture, in large societies and with greater freedoms and prosperity defined in new ways besides within the terms of economics. This gives me optimism that capitalism/states aren't necessary or inevitable and that we might be stuck on this shitty plateau having convinced ourselves it's the only realistic one

Re: The Continuous Delivery Test

#70

Post by ryanklee »

etamponi wrote: post #67
ryanklee wrote: post #50

Earlier quoted context omitted.

I'm an SRE and currently on a mission to get code into prod as fast and safely as possible. Instead of painting such a broad, generic negative picture, maybe articulate an actual position to argue against.

You are right -- I was referring specifically to SREs in FAANG, which enforce a mandate of maximum 1 deploy to prod per day -- in some case even 1 per week, or less. To be honest, I think there is a threshold, perhaps expressed in terms of risk of losing money, at which it is more beneficial to delay deploys. But applying the same deployment rules to a multi-billion-dollar revenue machine and to a smaller project wit…

Thanks for the clarification, I can see how that might be frustrating.
Post reply on HN