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

31–40 of 72 posts

Re: The Continuous Delivery Test

#31

Post by 8n4vidtmkvmk »

ChrisMarshallNY wrote: post #16
alkonaut wrote: post #9

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

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.

Re: The Continuous Delivery Test

#32

Post by satyrnein »

I'd like to see a workflow that meets all the criteria. I was surprised to see the item about deploying directly from your own machine; that seems to contradict the other goals which point to automated pipelines that deploy on merge.

Re: The Continuous Delivery Test

#33

Post by maccard »

gregmac wrote: post #6
dijit wrote: post #4

Earlier quoted context omitted.

Yes. But I’m referring to the article: > 1. Do you use a distributed version control system? Edit: the parent originally said “distributed build system”

I'm not sure what you're getting at here. Mono-repo is entirely a different concept then centralized (eg: SVN) vs distributed (eg: git). I'd also seriously question an org not using git, specifically, despite claiming "cargo cult". Literally every developer knows it, it's got a huge choice of tooling, and every service/tool (CI/CD, issue tracker, etc) has an integration. IMHO, you better have a damn good reason to be…

> I'd also seriously question an org not using git

That's a very damning statement. Many places use perforce, for example.

Git doesn't handle binaries and frankly git struggles to scale. Try checking out a _large_ git repo and running some common operations on it.

Re: The Continuous Delivery Test

#34

Post by maccard »

chrisoverzero wrote: post #7
dijit wrote: post #4

Earlier quoted context omitted.

Yes. But I’m referring to the article: > 1. Do you use a distributed version control system? Edit: the parent originally said “distributed build system”

Read this as “Do you use git?” This is opposed to svn, cvs, something home-grown, or passing thumb drives back and forth among developers.

Hg, svn, perforce, plastic are all feasible alternatives to git.

Re: The Continuous Delivery Test

#35

Post by TheP1000 »

satyrnein wrote: post #32

I'd like to see a workflow that meets all the criteria. I was surprised to see the item about deploying directly from your own machine; that seems to contradict the other goals which point to automated pipelines that deploy on merge.

This is a very common pattern especially with the cdk. Having a locally deployed stack makes development in the cloud so much easier.

Re: The Continuous Delivery Test

#36

Post by maccard »

kqr wrote: post #12
alkonaut wrote: post #9

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

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 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.

Re: The Continuous Delivery Test

#37

Post by simongr3dal »

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.

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.

Re: The Continuous Delivery Test

#38

Post by marcosdumay »

kqr wrote: post #12
alkonaut wrote: post #9

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

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…

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.

Re: The Continuous Delivery Test

#39

Post by kqr »

marcosdumay wrote: post #38
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…

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.

#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.

Re: The Continuous Delivery Test

#40

Post by Merad »

bhawks wrote: post #10

> 11. Do you include ticket IDs in your commits or branches? This is one of the things that sound 'good' on the surface and are totally worthless in practice (especially when practicing minimal commits). In the wild this devolves into a meaningless umbrella issue (Deliver Feature Foo) or 1 liner issues that sometimes did not even match the pr contents. Just use the commit message and in pr review enforce commit messa…

I've yet to work at a company that has managed to figure out a strategy to get the majority of devs to write clear and descriptive commit messages the majority of the time. At least if they include the ticket number I can look at the ticket to understand what they intended to do. Of course whether they actually did it or not is another matter.
Post reply on HN