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

21–30 of 72 posts

Re: The Continuous Delivery Test

#21

Post by kqr »

wodenokoto wrote: post #20
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

There's a difference between "every story has a branch" and "you need to create a story for every commit" which is what's implied by TFA.

Re: The Continuous Delivery Test

#22

Post by kqr »

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.

When there is a ticket, yes, adding the number is trivial and probably worth it. Where the rule breaks down, in my opinion, is when you have to create a ticket and replicate the commit message in it any time you stumble over a code maintainability issue and fix it in stride.

Re: The Continuous Delivery Test

#23

Post by crdrost »

wodenokoto wrote: post #20
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

I like this, but it violates one of my norms, haha.

Stories can last for a while, but long-lived feature branches have to be kept in sync with the main branch, otherwise they develop nasty merge conflicts and you are not deploying continuously.

I think the better solution is for your versioning and your issue tracker to be integrated: we still expect every developer to merge to mainline one or twice a day[1], keeping merge conflicts shallow... But they should mention what issue they are working on in the commit, and the integration dumps that information into the tracker automatically.

[1] This is not hard to make safe, though it makes a lot of devs skittish at first. See Three-Flow for a non-CD version, https://www.nomachetejuggling.com/2017/04/09/a-different-bra... as a stepping stone. One key thing is that code review needs to become much lighter than it is at many organizations, “I don't care how you did it as long as it can be turned off with a feature toggle and does not break prod or introduce security vulnerabilities when I merge it: those key things are what I am looking for.”

Re: The Continuous Delivery Test

#24

Post by dallbee »

kqr wrote: post #22
whakim wrote: post #15

Earlier quoted context omitted.

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.

When there is a ticket, yes, adding the number is trivial and probably worth it. Where the rule breaks down, in my opinion, is when you have to create a ticket and replicate the commit message in it any time you stumble over a code maintainability issue and fix it in stride.

This is the practice we use - link to a ticket if it exists.

There's nothing wrong with fixing a bug you discover upon inspection. Forcing tickets for every change discourages code maintenance.

Re: The Continuous Delivery Test

#25

Post by kqr »

crdrost wrote: post #23
wodenokoto wrote: post #20

Earlier quoted context omitted.

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

I like this, but it violates one of my norms, haha. Stories can last for a while, but long-lived feature branches have to be kept in sync with the main branch, otherwise they develop nasty merge conflicts and you are not deploying continuously. I think the better solution is for your versioning and your issue tracker to be integrated: we still expect every developer to merge to mainline one or twice a day[1], keeping…

> I don't care how you did it as long as it can be turned off with a feature toggle and does not break prod or introduce security vulnerabilities when I merge it

Does this not lead to poorly-written features that drag down future development yet cannot be turned off because they have grown important for the business?

At least that's my experience with not regulating at least a basic level of code quality in the review. What are you doing differently to prevent that?

Re: The Continuous Delivery Test

#26

Post by crdrost »

dallbee wrote: post #24
kqr wrote: post #22

Earlier quoted context omitted.

When there is a ticket, yes, adding the number is trivial and probably worth it. Where the rule breaks down, in my opinion, is when you have to create a ticket and replicate the commit message in it any time you stumble over a code maintainability issue and fix it in stride.

This is the practice we use - link to a ticket if it exists. There's nothing wrong with fixing a bug you discover upon inspection. Forcing tickets for every change discourages code maintenance.

This is also where automated code quality checks can shine. You can say something like, if it's more than 5 or 10 lines we expect a ticket ID, otherwise we don't.

See DeGrandis’s “Making Work Visible,” the hazard of “link to a ticket if it exists” is that sometimes this causes us to treat tickets as an external process, but we absolutely want to surface tickets that track our cleanup of tech debt and any other procedural tasks that we are stuck doing.

If automated tooling sounds nice but you are at the sort of place where “there are three priority levels: hot, Red Hot, and DO IT NOW,” this can also be part of a pull request template. One extremely effective template we used at a previous job just had quick checklist and you'd check off for example “I tried this code on my dev cluster.” Caught a lot of “whoops I am moving too fast and need to slow down a bit” issues, hah!

Re: The Continuous Delivery Test

#27

Post by theptip »

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 think it can be useful to encourage (not require) this practice since auto-linking between Jira and GitHub/Gitlab is a nice feature. Jira can now show you what releases a given feature is deployed in, etc.

If you are in a regulated environment or selling to large enterprises you may find that having a SDLC policy of “no changes without ticket to track” is a more easily defensible control against unauthorized code changes (you’ll get asked about this in SOC2 and security questionnaires). The policy “anyone can make a change if they find a reviewer to approve” might not float.

Mandating ticket IDs can be really annoying though, for example if I want to make a few-line no-op refactor to clean up some code, I don’t want to have to create a ticket. So it’s definitely a tradeoff.

Re: The Continuous Delivery Test

#28

Post by KronisLV »

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…

> This is one of the things that sound 'good' on the surface and are totally worthless in practice (especially when practicing minimal commits).

I feel like I disagree here.

Turning on Git Annotations in any JetBrains IDE and seeing who made changes, when and which Jira issue necessitated these changes right there is pretty useful. All of the sudden, you can easily say: "This method had been changed in 5 different commits in the last 3 years, what I probably need to read before making my own changes are issues ABC-123, ABC-236, ABC-455, ABC-855 and ABC-1233, to understand the business context and historical limitations behind all of this."

> Just use the commit message and in pr review enforce commit message norms.

I fully agree with this, but unless you squash your commits or rebase, finding out which MR/PR a particular set of changes belongs to isn't always immediately doable, especially when looking at things locally instead of the GitLab/GitHub UI.

Furthermore, the barrier of entry is higher: I always describe my changes and add a bit of context in the merge request/pull request description, sometimes even with GIFs or MP4 video demonstrations of what happens as a consequence of them. And yet, the majority of other developers have no desire to do that - I've regularly seen people leave those empty, and even commit messages are sometimes like: "try fix" instead of "make Ansible ensure that file permissions are set to have the newly created directory be readable by the group that will run the app".

In contrast, everyone is capable of adding a simple identifier to the issue management system and there are very few arguments that they can make against adding a few characters to the beginning, as opposed to: "But adding descriptions would take a lot of time and slow down development, I don't think we really need those because you should be able to read the code and understand everything."

Sure, you can enforce it in a top down manner, but it can be like pulling teeth at times, so you might as well ensure that at least the lowest common denominator is in place, before trying to find better approaches.

Exceptions to this might be small changes that don't really correspond to an issue, then you have two choices:

  - create an issue yourself so the work doesn't become untraceable in the issue management/billing system you use
  - just leave a short text description without issue identifier

Re: The Continuous Delivery Test

#29

Post by lawl »

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

I have dealt with bugs that were thought to be fixed a long time ago, only for them to mysteriously pop up again later. Ticket is created and the old ticket is linked.

It's really helpful to see what was done 2 years ago, including the attempted fix that is now still live in the code base but apparently doesn't work properly.

That said, as always, it's not black or white. There are definitely cases where it doesn't make sense, but I don't think you should call it 'totally worthless'.

Re: The Continuous Delivery Test

#30

Post by davidmurdoch »

UweSchmidt wrote: post #8

> 9. Does your Infrastructure as Code live alongside the service it hosts? That means minor changes to some test infrastructure have to go through the strict review process, because the gitlab-ci.yaml is in the part of the main code. Last time this happened to me I found it annoying, and I don't think the code quality guardians care about some CI config anyway.

Changes to CI config for release automation are probably vetted and manually tested more than anything else in the projects I work on.
Post reply on HN