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

11–20 of 72 posts

Re: The Continuous Delivery Test

#11

Post by kqr »

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…

My previous team used to have ticket IDs on every commit but just decided to drop that requirement for commits that are truly self-contained and documented properly in the commit message.

That approach makes a lot of sense to me. Link the commit to the ticket when it enhances future reading, but not out of blind application of principle.

Re: The Continuous Delivery Test

#12

Post by kqr »

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

Re: The Continuous Delivery Test

#14

Post by michaelt »

Morgawr wrote: post #5
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”

Just because it's a monorepo it doesn't mean it's centralized?

Yes. It’s the accompanying suggestion of using github or gitlab that means it’s centralised.

Re: The Continuous Delivery Test

#15

Post by whakim »

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…

It's incredibly easy to simply add the ticket number to branch names (or commits if you're rebasing your branches when you merge). Many times the ticket isn't helpful, but "just make the commit/branch self-explanatory" ignores the fact that non-developers - product folks, designers, etc. - are far more likely to leave useful context in the ticket itself.

Re: The Continuous Delivery Test

#16

Post by ChrisMarshallNY »

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

Re: The Continuous Delivery Test

#17

Post by fmajid »

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…

Even Microsoft manages Windows using Git today

Re: The Continuous Delivery Test

#18

Post by winter_squirrel »

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…

No post body was provided.

Re: The Continuous Delivery Test

#19

Post by lelandfe »

whakim wrote: post #15
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…

It's incredibly easy to simply add the ticket number to branch names (or commits if you're rebasing your branches when you merge). Many times the ticket isn't helpful, but "just make the commit/branch self-explanatory" ignores the fact that non-developers - product folks, designers, etc. - are far more likely to leave useful context in the ticket itself.

Yes, exactly. I treat my commit history like I'm preparing for a detective to investigate years down the line :)

Great commit messages are just one part of the timeline. Ensuring there's a link between the commits/PR and the ticket lets the future detective get more information (frequently, that's "why did we do this").

Re: The Continuous Delivery Test

#20

Post by wodenokoto »

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…

Have one branch for every story in Jira has been incredibly helpful in teams I’ve been in.

You can check in git if work has actually begun, and you can get from and old commit to Jira by virtue of the merge commit.

I don’t know how you’d do it in a non-mono repo setting

Post reply on HN