4 ms·

Extremely web centric list. Any other development (mobile, desktop, games, embedded, …) will find a lot of these steps very weird.

kqr 4y ago
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-based development, practise something like code review, gate on integration tests, feature flag, spin up virtual production clones, etc. In other words, the fact that getting software to your end users is a clumsy process does not preclude you from doing every other step of the process with short feedback loops.
- maccard 4y ago
  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 is a double edged sword; the situation you need this is an absolute last resort. Enabling deployments from dev machines means credentials to environments, write access to infra, and likely skirting around normal processes.
  - KronisLV 4y ago
    > 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/ 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/ 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.
    - maccard 4y ago
      > 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/ 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.
- marcosdumay 4y ago
  What? #2 and #5 exist only to support #7. #4 usefulness is completely dependent on the context. #9 is a joke, right? It's an anti-pattern for most of the web based SaaS applications, and poisonous to anything that isn't SaaS. And #12... Try that in a large regulated company and people may quite as well end up in jail.
  - kqr 4y ago
    #2 is to improve quality, shorten feedback loops, and simplify merges. You get those benefits whether or not you're able to push things to your customer at will. Both #2 and #5 really just set a quality bar high enough to reduce long-term maintenance costs. I don't see why you wouldn't want that in a non-web scenario. #12 is not talking about deploying to production, and I don't see why you shouldn't be able to deploy to a dev environment from your machine. It's nice not to have to run everything locally. Even for non-EU companies. So aside from #9 which is of questionable utility for any type of development, no, I'm not convinced you've pointed valid examples.
hoskdoug 4y ago
Indeed. Does your deploy process self-heal? Err, no, I need to wait two days for App Store review.
ChrisMarshallNY 4y ago
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 integrated stuff, but it's mostly native iOS/TVOS/WatchOS/MacOS deliverables. CD is nice, but I feel that CI is better, for a team. Even that, is overkill for the way I work. I'm spoiled, I tend to work alone, or very loosely-coupled. That gives me a different workflow from what many experience. I had to spend a couple of years "un-learning" a lot of stuff from my Big Team days. The way I work results in astonishingly good stuff, very quickly, but the scope is much narrower than what a lot of folks here, do. As such, I find little utility in telling others that the way they do things is wrong, and that they should be doing it my way. I do talk about how I do things, but I'm not judgmental about it. I do feel that software quality, in general, is fairly problematic, but don't claim to have the silver bullet. I know what works for me, and I try to stay in my lane.
- 8n4vidtmkvmk 4y ago
  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.
  - simongr3dal 4y ago
    I like to imagine it as a sort of volume vs surface area problem. The amount of service you can deliver to costumers is your surface area, but the amount of work you put in only contributes to the volume. As the number of employees grow you will necessarily be less efficient, but there aren’t really any other great ways to gain the required surface area.
    - 4y ago
choeger 4y ago
Pretty much everyone with more than one production environment will. Imagine developing Firefox. How do you do a "self-healing deployment" automatically whenever trunk changes?
- zaat 4y ago
  You take the standard course of action, sending the PR team to state how Firefox is there as a beacon of hope and aspirations to privacy.

kqr 4y ago

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-based development, practise something like code review, gate on integration tests, feature flag, spin up virtual production clones, etc. In other words, the fact that getting software to your end users is a clumsy process does not preclude you from doing every other step of the process with short feedback loops.

maccard 4y ago
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 is a double edged sword; the situation you need this is an absolute last resort. Enabling deployments from dev machines means credentials to environments, write access to infra, and likely skirting around normal processes.
- KronisLV 4y ago
  > 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/ 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/ 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.
  - maccard 4y ago
    > 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/ 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.
marcosdumay 4y ago
What? #2 and #5 exist only to support #7. #4 usefulness is completely dependent on the context. #9 is a joke, right? It's an anti-pattern for most of the web based SaaS applications, and poisonous to anything that isn't SaaS. And #12... Try that in a large regulated company and people may quite as well end up in jail.
- kqr 4y ago
  #2 is to improve quality, shorten feedback loops, and simplify merges. You get those benefits whether or not you're able to push things to your customer at will. Both #2 and #5 really just set a quality bar high enough to reduce long-term maintenance costs. I don't see why you wouldn't want that in a non-web scenario. #12 is not talking about deploying to production, and I don't see why you shouldn't be able to deploy to a dev environment from your machine. It's nice not to have to run everything locally. Even for non-EU companies. So aside from #9 which is of questionable utility for any type of development, no, I'm not convinced you've pointed valid examples.

hoskdoug 4y ago

Indeed. Does your deploy process self-heal? Err, no, I need to wait two days for App Store review.

ChrisMarshallNY 4y ago

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 integrated stuff, but it's mostly native iOS/TVOS/WatchOS/MacOS deliverables. CD is nice, but I feel that CI is better, for a team. Even that, is overkill for the way I work. I'm spoiled, I tend to work alone, or very loosely-coupled. That gives me a different workflow from what many experience. I had to spend a couple of years "un-learning" a lot of stuff from my Big Team days. The way I work results in astonishingly good stuff, very quickly, but the scope is much narrower than what a lot of folks here, do. As such, I find little utility in telling others that the way they do things is wrong, and that they should be doing it my way. I do talk about how I do things, but I'm not judgmental about it. I do feel that software quality, in general, is fairly problematic, but don't claim to have the silver bullet. I know what works for me, and I try to stay in my lane.

8n4vidtmkvmk 4y ago
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.
- simongr3dal 4y ago
  I like to imagine it as a sort of volume vs surface area problem. The amount of service you can deliver to costumers is your surface area, but the amount of work you put in only contributes to the volume. As the number of employees grow you will necessarily be less efficient, but there aren’t really any other great ways to gain the required surface area.
  - 4y ago

choeger 4y ago

Pretty much everyone with more than one production environment will. Imagine developing Firefox. How do you do a "self-healing deployment" automatically whenever trunk changes?

zaat 4y ago
You take the standard course of action, sending the PR team to state how Firefox is there as a beacon of hope and aspirations to privacy.